VNWO Civic Charter and Governance Principles

Plain-English overview

This charter is VNWO’s reference civic application profile for virtual networks. It applies observatory guidance to consent, participation, disclosure, memory, endpoint use, repair, exit, and governance change. It is written for communities, organizations, builders, stewards, reviewers, and AI readers that need public rules people can inspect and challenge.

A virtual network affects agency when identity, memory, moderation, automation, endpoint permissions, reputation, or community membership shape what people can do. The civic profile makes that authority visible without restoring the former VNWO expansion as active branding. The framework favors inspectable rules over hidden authority, scoped use over ambient permission, repair over silent harm, and exit over lock-in.

Download Charter Markdown Download Charter PDF View machine-readable VNWO JSON

What this page is and is not

This page is public governance guidance

It explains the principles VNWO publishes for consent, disclosure, memory, endpoint boundaries, governance change, repair, exit, and claim boundaries. It is part of a wider open-rules system linked throughout this site.

This page is not legal authority

It is not legal advice, a certification, proof of safety, proof of AI consciousness, a government authority, or a runtime service. VNWO does not execute agents, import files, grant legal personhood, or override implementation systems or applicable law.

Governance snapshot

Maintained by	VNWO public guidance maintainers through the WordPress theme and versioned machine-readable files.
Current version	v3.0.16
Last reviewed UTC	2026-06-21T02:42:50Z
Review cadence	Review after material rule changes, machine-readable file changes, claim-boundary updates, or ecosystem lane changes.
Public contact path	Report a correction, accessibility issue, or claim-boundary question
Controlling status	Static observatory guidance. If a formal legal governing document applies elsewhere, that document and applicable law govern the legal relationship.

A governance page should make rule changes reviewable, not merely publish conclusions. Each material update should include what changed, why it changed, who may be affected, when it becomes effective, and which related documents were also updated.

Purpose and scope

VNWO applies where digital environments use identity, memory, automation, endpoint access, moderation, reputation, or community rules to shape participant agency. That includes AI-mediated communities, local endpoint tools, file-memory workflows, portable identity surfaces, agent profiles, repair processes, and exit paths.

The purpose is not to centralize authority. The purpose is to make authority visible enough that people can consent, review, repair, export, revoke, fork, or leave.

Roles and responsibilities

Participants

Participants should be able to inspect the rules, understand actor categories, review memory that affects them, request correction, revoke scoped permissions, and leave without misrepresentation.

Implementers

Implementers are responsible for turning guidance into actual system behavior, logs, UI, exports, retention limits, and review paths. VNWO does not execute that behavior for them.

Stewards

Stewards maintain public rule surfaces, version history, templates, claim boundaries, correction paths, and machine-readable files.

Reviewers and AI readers

Reviewers should use the Charter, Claim Boundaries, llms.txt, vnwo.json, open-rules.json, and related pages before making claims about VNWO.

Core governance principles

Consent

Participation should be voluntary, specific, understandable, and revocable. No one should be enrolled, tracked, represented, or memory-profiled beyond the scope actually disclosed.

Participation and contestability

Affected people should have a safe route to contribute evidence, challenge summaries, see how input was dispositioned, and understand what changed. Participation is not automatic consent, approval, or compulsory public visibility.

Disclosure

People should be able to tell whether they are interacting with a human, assisted human, bot, AI assistant, autonomous agent, persona, organization, or mixed actor.

Memory

Memory is governance when it steers future interactions. It should be disclosed, reviewable, correctable, portable where available, and retireable when no longer justified.

Endpoint boundaries

Public capability metadata is not authorization. Endpoint use should remain scoped, consent-bound, logged, reviewable, and revocable.

Open rules

Governance changes should be visible, versioned, reviewable, and understandable before they materially alter participant rights or obligations.

Repair

Legitimate networks need correction, appeal, evidence review, recovery, and good-faith dispute paths. Errors should not become permanent because the system lacks a repair channel.

Exit

A network is not legitimate if participants cannot leave. Exit includes clear instructions, revocable permissions, export where available, and freedom from retaliatory deletion or misrepresentation.

Forkability

When a community cannot continue under one rule set without coercion, peaceful forking is better than coercive unity.

Claim boundaries

A public framework should say what it does not claim. VNWO does not certify safety, grant legal status, execute agents, import files, or override another ecosystem lane.

Charter articles with implementation notes

Article 1 - Consent

No participant should be enrolled, tracked, represented, or memory-profiled beyond the scope they agreed to.

Minimum rule: Publish the consent scope in plain language before participation, memory capture, agent delegation, or endpoint access begins.
Stronger implementation: Provide separate consent controls for participation, public identity, file memory, endpoint use, notifications, and agent delegation.
Evidence to keep: Consent text, version, effective date, revocation path, and change history.

Article 2 - Participation and Contestability

Affected people should be able to contribute evidence, challenge a summary or rule, and see what the decision owner did with their input.

Minimum rule: Publish what is open to influence, who can participate, the contribution channel, and a response or disposition path.
Stronger implementation: Provide accessible and privacy-preserving channels, preserve dissent, publish a participation record, connect input to a real decision lever, and keep correction, refusal, and exit available.
Evidence to keep: Participation notice, affected-group map, contribution summary, minority report, disposition ledger, decision record, and appeal path.

Article 3 - Disclosure

A participant should be able to know whether it is interacting with a human, assisted human, bot, AI assistant, autonomous agent, persona, organization, or mixed actor.

Minimum rule: Label actor category, responsible operator, and authority scope wherever the actor appears.
Stronger implementation: Add standardized badges, sample disclosures, audit records, and a correction path for mislabeling.
Evidence to keep: Actor taxonomy, badge registry, disclosure examples, reviewer path, and repair records.

Article 4 - Portable Memory

Memory should be exportable, reviewable, and scoped. Private memory should not become public identity without consent.

Minimum rule: Disclose what memory exists, why it is used, where it lives, and how a participant can review or revoke it.
Stronger implementation: Support structured export, correction requests, retention windows, and memory retirement records.
Evidence to keep: Memory policy, export examples, correction ledger, retention schedule, and revocation log.

Article 5 - File Memory

Dropped files are active intake, not passive background. They require review, use or disposition, and durable proof-of-use records.

Minimum rule: State that files are active intake and that VNWO.com itself does not import, inspect, store, process, or sync files.
Stronger implementation: Use UAIX Agent File Handoff or another scoped implementation that records file review, disposition, proof-of-use, and source cleanup.
Evidence to keep: file-handoff.uai, intake-outcome-ledger.uai, source file disposition labels, and keep-active reasons.

Article 6 - Endpoint Boundaries

Public capability metadata is not authorization. Local endpoints require scope, consent, logging, and revocation.

Minimum rule: Separate public metadata from authorization and publish the allowed scope of endpoint interaction.
Stronger implementation: Require human approval for escalation, maintain logs, offer revocation, and block private probing.
Evidence to keep: Endpoint boundary statement, consent records, call logs, revocation receipts, and escalation approvals.

Article 7 - Open Rules

Network rules should be public, versioned, and understandable to humans and agents.

Minimum rule: Publish rules in readable HTML with a visible version, review date, and contact path.
Stronger implementation: Publish HTML, Markdown, PDF, llms.txt, JSON, sitemap, and change notices from the same public truth.
Evidence to keep: Charter page, version history, machine-readable files, and archived prior versions.

Article 8 - Repair

Errors should have correction paths, appeal processes, incident records, and recovery options.

Minimum rule: Publish a correction and accessibility contact path.
Stronger implementation: Track acknowledgement, evidence review, decision, appeal, recovery, and public correction when appropriate.
Evidence to keep: Repair request log, decision log, correction note, appeal record, and release note.

Article 9 - Exit

No participant should be trapped by identity lock-in, memory capture, hidden governance, or retaliatory deletion.

Minimum rule: Publish human-readable exit instructions for account closure, export, revocation, and correction.
Stronger implementation: Support identity export, memory export, reputation portability, agent disengagement, endpoint revocation, and non-retaliatory forkability.
Evidence to keep: Exit checklist, export receipt, revocation receipt, closure confirmation, and public correction record.

Article 10 - Forkability

When communities cannot agree, peaceful forking is better than coercive unity.

Minimum rule: State when and how a community may separate without identity punishment or misleading deletion.
Stronger implementation: Provide fork notices, export packages, name-use boundaries, migration notes, and conflict-resolution records.
Evidence to keep: Fork notice, export package, migration checklist, and non-retaliation statement.

Article 11 - No Overclaiming

VNWO does not prove AI consciousness, legal personhood, safety, compliance, or authority.

Minimum rule: Publish allowed and prohibited claims wherever VNWO language is reused.
Stronger implementation: Add copy-safe replacements, machine-readable claim boundaries, and ecosystem lane conflict warnings.
Evidence to keep: Claim Boundaries page, claim-boundaries.json, footer boundary statement, and release notes.

How governance changes

Publish the proposed change in human-readable language.
Identify affected pages, templates, machine-readable files, and claim boundaries.
State the reason for change and the effective date in UTC.
Keep prior versions available or summarized in the version history.
Provide a correction path when the change introduces ambiguity or error.

Repair, correction, and accessibility

Public governance pages should provide a practical path for accountability. VNWO directs readers to the Contact page for correction requests, accessibility issues, and claim-boundary questions. The contact path should not invite private memory files, credentials, endpoint secrets, or confidential project data.

Report a correction or accessibility issue

Threat models the Charter is designed to expose

VNWO treats overreach as a predictable result of invisible authority, unbounded memory, ambiguous actors, and locked exit paths. The Charter should be read against concrete failure modes, not only ideals.