Document networked evolution of the MNCS standard

[epi13]

What changed

• add a non-normative networked-standard-evolution architecture document;
• define the distinct roles of MNCS, MNCDS, MNCS Language, Forge, RAVEL, independent actors, and promotion governance;
• separate bounded implementation refinement from evolution of normative standard meaning;
• define artifact and authority boundaries between components;
• require independent identities and versions to prevent synchronized self-validation;
• document progression discipline, evidence inputs, promotion surfaces, and failure modes;
• link the document from the repository README, documentation home, MkDocs navigation, and changelog.

Why

The project family increasingly produces useful recursive, language, verifier, distributed-execution, and evidence artifacts. The repository needs an explicit model for how those artifacts can inform future MNCS and MNCDS changes without allowing a language, compiler, Forge workflow, RAVEL mechanism, evaluator, or recursive loop to become normative or promote itself by accident.

The document captures this division of responsibility:

• MNCS / MNCDS define standards, identities, invariants, deterministic representations, comparison rules, and development controls.
• MNCS Language exposes semantics, compiler transformations, diagnostics, evidence, and repair structures.
• Forge runs bounded micro-verifiers, localizes failures, tests candidates, and produces evidence.
• RAVEL coordinates experiments across agents, machines, implementations, environments, and trust boundaries.
• Independent actors provide reproduction, disagreement, custody, and implementation diversity.
• Promotion policy and governance decide whether a candidate or proposal becomes trusted, standardized, released, rejected, or remains UNKNOWN.

Impact

This is documentation-only and explicitly non-normative. It does not alter MNCS or MNCDS conformance semantics, schemas, validators, release-candidate identifiers, frozen evidence, RAVEL gates, Forge authority, or governance requirements.

Validation

• reviewed the branch comparison against main;
• confirmed the branch is based on the current main head and contains only documentation/navigation changes;
• added the new document to strict MkDocs navigation;
• no executable behavior or schema changed.

Repository CI should perform the authoritative documentation and full-project checks.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.