{
  "schema": "moriverse-community-charter/1",
  "revision": 1,
  "date": "2026-10-19",
  "title": "Your world. Our commons. Evidence before change.",
  "purpose": "MORIverse is being built as its own website with a browser-owned personal workspace. People choose what leaves their device. Community worlds grow through proposals, comparative evidence and recorded MORI review.",
  "status": "Design contract and roadmap. Shared accounts, synchronization, public Social posting and authoritative community finalization are not connected in this release.",
  "promises": [
    "Personal work stays private by default. Sharing is a separate, deliberate action with an exact preview and a named audience.",
    "Community changes begin as branches. MORI finalizes a shared revision only after its published evidence and permission gates pass.",
    "No demonstrated benefit means no promotion into a shared release. An untested idea remains an experiment that people may explore.",
    "The same conduct rules apply across viewpoints. Disagreement, investigation, art and personal experience have a place; abuse and manipulation do not earn distribution."
  ],
  "inventory": [
    {
      "area": "Personal rooms and tools",
      "state": "Implemented, with limits",
      "detail": "Main and personal-world drafts, local learning records, save points and conflict-preserving workspace imports already run in the browser. They are not automatically community posts."
    },
    {
      "area": "Music and recordings",
      "state": "Implemented, with limits",
      "detail": "Private music and DJ take stores are scoped by world. Music World now exports original-audio ZIPs with exact drafts and a checked atomic restore. Workspace/catalogue-only backups still exclude audio; DJ takes have separate downloads. Actual-device and general-media recovery remain open."
    },
    {
      "area": "MORI review",
      "state": "Local and bounded",
      "detail": "The recursive-learning core records evidence, failed attempts, evaluation and retraction. A local validator is not an authenticated shared-world approval or a universal truth judgment."
    },
    {
      "area": "Social World",
      "state": "Local kit",
      "detail": "Posts, replies, poll choices and templates are local. Shared identities, live conversations, community totals, moderation and appeals are not simulated."
    },
    {
      "area": "Hosted services",
      "state": "Connected selectively",
      "detail": "The public website, supplied public music, public-data adapters and privately submitted beta reports use network services. Browser-owned work does not make every activity offline or every request anonymous."
    },
    {
      "area": "Independent operation",
      "state": "Planned qualification",
      "detail": "A fully offline app shell, independent hosting package, custom-domain migration, complete media backup, optional encrypted sync and disaster recovery still need implementation and acceptance."
    }
  ],
  "spaces": [
    {
      "name": "Personal workspace",
      "owner": "The individual",
      "data": "Drafts, history, notes, music, experiments and local preferences.",
      "rule": "No background upload to a community, moderator, model or training service. Local branches need no community permission."
    },
    {
      "name": "Invited collaboration",
      "owner": "Named members under explicit roles",
      "data": "Only selected artifacts and edits in an invitation-bound project.",
      "rule": "Joining, contributing, leaving and changing roles require verified membership. Working drafts can merge; a shared release still needs MORI review."
    },
    {
      "name": "Published commons",
      "owner": "A governed community",
      "data": "The selected release, permitted assets, sources and a privacy-reviewed decision record.",
      "rule": "A publication is a new shared copy. Publishing never grants access to the author’s whole private world or later private changes."
    }
  ],
  "sections": [
    {
      "id": "ownership",
      "title": "Privacy is a data boundary",
      "intro": "The browser is the primary work area. The server receives the smallest artifact the person deliberately chooses to share.",
      "points": [
        "Every share operation must show the exact content, attachments, audience, attribution, permissions and destination before sending. A changed payload or audience requires a new confirmation.",
        "Separate private recovery backups from shareable releases. Shared schemas use explicit allowed fields and exclude private world identifiers, revision history, activity logs, reports, location trails, credentials, hidden metadata and unrelated drafts by default.",
        "Providers, live cameras, external pictures, maps and other remote services can learn about a request. Show the destination and purpose before sending private input; external Social pictures require a deliberate load action.",
        "No behavioral advertising, political profiling, sale of personal data or automatic training on visitor work is part of this design. Optional paid services must describe their price and data destination before use.",
        "Browser storage can be denied, exhausted, evicted or cleared. A storage dashboard, persistence requests, portable backups and tested restoration are required work; local storage alone is not encryption or a backup.",
        "Unsharing stops future access through MORIverse where enforceable. It cannot recall somebody else’s download, screenshot or independent copy. Explain that before publication.",
        "Protect the delivered app as well as the database: strict content boundaries, inert imports, minimal third-party code, dependency review and least-privilege access. Browser data is still vulnerable to malicious same-origin scripts, compromised devices and hostile software updates."
      ]
    },
    {
      "id": "improvement",
      "title": "Improvement must be demonstrated",
      "intro": "A proposal may explain a possibility. A shared release must demonstrate a benefit within its stated context.",
      "points": [
        "Define the problem, intended beneficiaries, unchanged baseline, candidate, success measure and unacceptable regressions before the comparison. Likes, contributor seniority, repetition and MORI’s confidence do not substitute for evidence.",
        "Engineering changes need reproducible comparisons, recorded conditions, source/test versions and results. Qualitative changes can use a documented task, accessibility review, creative brief or consenting user assessment; one score does not define quality for everybody.",
        "Record uncertainty, sample size and conflicting results. A tiny or noisy difference is inconclusive. Failed, disputed, expired or retracted evidence blocks promotion until resolved or retested.",
        "Bind evidence to the exact baseline and candidate hashes, shared-world revision and policy version. Any material change invalidates the old approval and starts the relevant checks again.",
        "A demonstrated benefit must pass privacy, security, accessibility, consent, compatibility and recovery checks as well. An improvement in speed cannot silently trade away people’s work or rights.",
        "MORI issues a reasoned, reproducible review with cited evidence and remaining limits. Finalization requires authorized approvals under the published rules; a browser-supplied “passed” flag cannot authorize a shared write.",
        "Retain rejected alternatives and failed experiments within their permitted audience. New evidence can reopen a proposal. Creative work and personal beliefs do not need a scientific proof merely to exist in someone’s private space."
      ]
    },
    {
      "id": "collaboration",
      "title": "Community changes are reviewed releases",
      "intro": "People contribute to a working branch; they do not overwrite the community’s accepted world.",
      "points": [
        "Use the sequence: fork the accepted revision → propose a scoped change → test the comparison → MORI review → authorized finalization → monitored release. Keep the baseline and a usable rollback throughout.",
        "Contributor, reviewer, world steward and moderator are separate permissions. Material shared changes need an independent reviewer. A contributor does not approve their own promotion; maintainers and MORI follow the same evidence requirements.",
        "Automatic merging is suitable for compatible working edits. CRDT convergence is not evidence of improvement, valid consent or permission to publish. Membership revocation and canonical releases require an authoritative boundary.",
        "The future server must validate identity, membership, current revision, artifact hashes, policy version, approvals and one-time release requests on every write. Use atomic revision checks and reject stale or replayed finalizations.",
        "Record who approved, which evidence was accepted, what changed and how to reverse it. Public summaries must be redacted independently of private review material. Preserve a prior release when the candidate fails.",
        "Contributed assets and executable code use different paths. Worlds may accept validated data and licensed media; untrusted scripts and plug-ins need isolated execution and a separate code/security review.",
        "Urgent containment can temporarily disable an unsafe shared feature with a logged reason and prompt review. It does not grant a hidden route for ordinary untested feature promotion.",
        "Rules themselves are versioned proposals with published rationale, review and notice. Community authority does not silently expand into members’ private worlds."
      ]
    },
    {
      "id": "social",
      "title": "Social is for participation without factional capture",
      "intro": "Design the incentives and enforce observable conduct. A claim about somebody’s hidden agenda is not sufficient grounds for punishment.",
      "points": [
        "The public Social commons is for making, learning, sharing work and useful community coordination. Party/candidate campaigning, factional recruitment and antagonistic persuasion drives are outside that purpose across all sides. This limits shared distribution; it does not authorize inspection of private beliefs.",
        "People may question policies, criticize institutions, compare sources, describe experiences and disagree. Controversial topics and political identities are not automatic violations. Critique ideas and actions with the same standards across viewpoints.",
        "Do not distribute threats, incitement, targeted harassment, doxxing, identity-based dehumanization or organized intimidation. Reports must identify the actual conduct, context and rule; disagreement alone is insufficient.",
        "Constrain coordinated flooding, brigading, fake identities used to manipulate reach, undisclosed automated persuasion, impersonation and forged evidence. A large number of reports is a signal to examine, not a vote that determines truth.",
        "No paid political promotion or behavioral ad targeting is planned. Disclose relevant sponsorship and automated authorship in public submissions. Do not infer somebody’s politics or sensitive traits from their private activity.",
        "Following and chronological views are the default discovery plan. Let people choose topics and communities, mute or block, and control notifications. Do not optimize distribution for anger, argument length, compulsive engagement or recruitment.",
        "Use purpose-bound discussion rooms. A constructive contentious post can state its question, distinguish observation from interpretation, link checkable claims, acknowledge uncertainty and explain what response would help.",
        "Opinions, jokes, art and personal accounts do not all require academic citations. Label their nature. Evidence links do not excuse harassment, and repetition does not turn a disputed claim into an established fact.",
        "For example, comparing evidence about a water policy fits a structured discussion; party recruitment, demands to flood other rooms or attacks on people for their affiliation do not fit the commons. Apply the purpose rule to the submitted behavior, with notice and appeal.",
        "Context matters for quotations, satire and documentation of abuse. Keyword matches and topic labels alone must not decide sanctions. High-impact speech decisions need qualified human review and an appeal path.",
        "MORI assists with context, sources and policy checks. Moderation must be explainable and challengeable; MORI is not an unaccountable arbiter of acceptable belief. Aim to prevent abuse and amplification, while measuring failures instead of promising zero misuse."
      ]
    },
    {
      "id": "appeals",
      "title": "Moderation needs reasons and correction",
      "intro": "A trustworthy commons must be able to correct both abusive content and its own mistaken decisions.",
      "points": [
        "Give affected people a durable notice: the content/action, specific rule and version, relevant excerpt, scope, duration, decision maker, automation involved and an accessible appeal route.",
        "Use proportionate actions: request context or revision, apply a clearly explained contextual label, limit a specific distribution path, or remove the violating material. Avoid hidden suppression or collective punishment.",
        "Permit appeal to a reviewer who did not make the disputed decision. Preserve the person’s response and original material within restricted access, and restore content/reach where a mistaken action is reversed.",
        "Keep reports, reporter identity and private evidence restricted. Publish privacy-reviewed aggregate outcomes, error rates, appeal reversals and rule changes; do not expose private complaint queues or political profiles.",
        "Test the same conduct with viewpoints and group labels exchanged. Review cultural/language context, false positives, missed abuse and coordinated-report attacks. No fairness guarantee follows merely from an automated test passing.",
        "Authoritative moderation, sanctions and appeals need authenticated services and accountable human operations. These are launch gates for public Social participation, not functioning services in the current local kit."
      ]
    },
    {
      "id": "independence",
      "title": "Self-sufficiency must be tested",
      "intro": "Owning a website means being able to preserve, operate and move it, with dependencies clearly disclosed.",
      "points": [
        "Keep personal creation, editing, export and local MORI evaluation usable without a paid generation provider. Optional models, live feeds and public services must fail clearly without replacing or losing private work.",
        "Build and verify an offline app shell with versioned cache updates and recovery. Do not claim a fresh browser can open the entire site without a network until offline installation and cold-start behavior are tested.",
        "Prepare a documented deployment package with portable source, asset provenance, schema migrations, environment names, secret setup, backup and restoration instructions. Do not package secrets or visitor records into the release.",
        "The current public Site remains hosted on its existing domain. A separately owned domain and independent hosting are a planned migration, not purchases or deployments performed by this charter.",
        "Browser storage belongs to an origin. Moving domains needs an explicit, tested export/import bridge for workspaces and separate audio/reading stores; a DNS change does not transfer people’s local data.",
        "Use minimal shared services for membership, invitations, selected artifacts, release manifests and moderation. Keep private work local; optional encrypted collaboration must state its key recovery and moderation limits.",
        "Encrypted invite-only projects and public moderated content have different trust boundaries. A server cannot inspect encrypted plaintext it never receives. Do not claim both invisible private content and complete server-side moderation.",
        "Before claiming independence, test clean installation, offline editing, rejected network requests, export/restore, host migration, shared-service failure, stale clients, rollback and mobile memory/storage limits."
      ]
    }
  ],
  "phases": [
    {
      "id": "P0",
      "name": "Charter and current boundaries",
      "state": "This release",
      "gate": "Publish the design and honest capability inventory. Stop automatic Social picture requests and preserve existing private drafts."
    },
    {
      "id": "P1",
      "name": "Private ownership and recovery",
      "state": "Required next foundation",
      "gate": "A storage/network dashboard; persistence status; complete workspace/media backups; explicit egress permissions; tested restore; offline shell and safe updates."
    },
    {
      "id": "P2",
      "name": "Invited collaboration",
      "state": "Not connected",
      "gate": "Verified membership and scoped permissions, explicit share previews, authenticated writes, contribution histories, revocation, conflict recovery and hostile-client authorization tests."
    },
    {
      "id": "P3",
      "name": "MORI release finalization",
      "state": "Not connected",
      "gate": "Comparative evidence bound to exact artifacts; independent approvals; authenticated MORI review; atomic release revisions; rollback and replay/stale-approval rejection."
    },
    {
      "id": "P4",
      "name": "Public Social participation",
      "state": "Gated",
      "gate": "Conduct rules, report abuse resistance, staffed review, reasoned notices, independent appeals, privacy controls, rate limits and measured moderation/distribution acceptance."
    },
    {
      "id": "P5",
      "name": "Independent operation",
      "state": "Not qualified",
      "gate": "Portable deployment, an approved domain/hosting choice, private-data migration, complete restoration drills and clear operating costs. This does not activate queued worlds or lift the circuit gate."
    }
  ],
  "sources": [
    {
      "id": "C01",
      "title": "Local-First Software — authors’ paper",
      "url": "https://martin.kleppmann.com/papers/local-first.pdf",
      "finding": "Local ownership and collaboration can coexist; this is a design direction, not a guarantee supplied by a storage library."
    },
    {
      "id": "C02",
      "title": "MDN — Storage quotas and eviction",
      "url": "https://developer.mozilla.org/en-US/docs/Web/API/Storage_API/Storage_quotas_and_eviction_criteria",
      "finding": "Default browser storage is best effort; persistence and separate backups must be treated deliberately."
    },
    {
      "id": "C03",
      "title": "OWASP — HTML5 Security",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html",
      "finding": "Client-side storage is not a safe place to assume secrecy against injected same-origin script."
    },
    {
      "id": "C04",
      "title": "OWASP — Authorization",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html",
      "finding": "Apply least privilege and server-side authorization on every relevant request; client checks do not authorize shared writes."
    },
    {
      "id": "C05",
      "title": "Santa Clara Principles",
      "url": "https://santaclaraprinciples.org/",
      "finding": "Clear rules, notice, accountable automation and meaningful appeal inform the proposed moderation process."
    },
    {
      "id": "C06",
      "title": "Automerge official repository",
      "url": "https://github.com/automerge/automerge",
      "finding": "A candidate for merging collaborative working documents. It is not installed here and is separate from authorization and release approval."
    }
  ]
}
