From 0253a26f3830b1ab7c7a183d3314b59dc8104d76 Mon Sep 17 00:00:00 2001 From: epi13 Date: Fri, 14 Aug 2026 12:18:37 -0800 Subject: [PATCH 01/19] docs: establish independent MNCDS project identity --- README.md | 56 +++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 54 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 6770b0a..3bdab00 100644 --- a/README.md +++ b/README.md @@ -1,2 +1,54 @@ -# machine-native-complexity-development-specification -Open experimental specification for governing the development, evaluation, selection, release, monitoring, regeneration, replacement, and retirement of machine-native implementations. +# Machine-Native Complexity Development Specification + +**MNCDS** is an open experimental specification for evidence-governed development of machine-native implementations. + +MNCDS governs how machine-native implementations are created, evaluated, selected, released, monitored, regenerated, replaced, and retired. It is a companion to the [Machine-Native Complexity Standard (MNCS)](https://github.com/epi13/machine-native-complexity-standard), but it is **independently versioned, governed, and released**. + +> **Repository bootstrap in progress.** The normative MNCDS 0.1 release-candidate material currently lives in the MNCS repository and will be migrated here under an explicit provenance-preserving plan. Until that migration is completed and validated, this repository does not supersede the existing MNCDS source material. + +## Core boundary + +**MNCS asks:** What evidence supports acceptance of an implementation? + +**MNCDS asks:** What development process produced, evaluated, selected, released, monitored, regenerated, replaced, or retired that implementation? + +Those responsibilities interact through explicit, versioned bindings. Neither project silently owns or rewrites the other's normative meaning. + +## Design principles + +1. **Independent normative authority.** MNCDS changes are reviewed and released here. +2. **Explicit interoperability.** Dependencies on MNCS use versioned contracts and identities rather than source duplication. +3. **Process evidence is first-class.** Candidate lineage, partitions, authority, selection, reproducibility, release, and lifecycle state remain inspectable artifacts. +4. **Unknown stays unknown.** Missing, inaccessible, unsupported, crashed, or timed-out evidence does not become `PASS`. +5. **History is immutable.** Corrections create new records and preserve superseded identities. +6. **Tool neutrality.** Models, generators, analyzers, compilers, providers, benchmarks, languages, Forge, RAVEL, and case studies are implementations or research mechanisms, not normative authorities. +7. **No self-promotion.** Generators, evaluators, orchestration systems, and recursive agents cannot silently broaden authority or promote their own results. + +## Repository map + +- `spec/` — normative and release-candidate MNCDS specification text. +- `schemas/` — versioned machine-readable MNCDS schemas. +- `conformance/` — valid/invalid vectors and release-candidate conformance corpora. +- `rfcs/` — proposals that change normative meaning, governance, or interoperability. +- `docs/` — architecture, rationale, migration, and non-normative guidance. +- `migration/` — provenance and transfer planning for material currently housed in the MNCS repository. +- `scripts/` — repository and conformance support tooling; tools are non-normative unless a specification explicitly says otherwise. + +## Status + +- Project: **Machine-Native Complexity Development Specification** +- Acronym: **MNCDS** +- Current specification line: **0.1** +- Current source release candidate: **0.1-rc.1**, pending migration from the MNCS repository +- Maturity: **experimental / pre-1.0** +- License: **Apache-2.0** + +The current migration source is [`epi13/machine-native-complexity-standard`](https://github.com/epi13/machine-native-complexity-standard). See [`MIGRATION.md`](MIGRATION.md) for the transfer boundary and [`INTEROPERABILITY.md`](INTEROPERABILITY.md) for the long-term MNCS ↔ MNCDS relationship. + +## Contributing + +Read [`CONTRIBUTING.md`](CONTRIBUTING.md), [`GOVERNANCE.md`](GOVERNANCE.md), and [`AGENTS.md`](AGENTS.md) before changing normative material. Normative changes require explicit review and must not be smuggled in as migration cleanup. + +## Non-claims + +MNCDS is experimental. It is not accredited certification, a security warranty, organizational independence, protected custody, or proof that a development process is safe or correct. A validator can check declared records and invariants; it cannot manufacture missing real-world evidence or authority. From 081fc807152d59e45ae152d2e6c18ad29a379c84 Mon Sep 17 00:00:00 2001 From: epi13 Date: Fri, 14 Aug 2026 12:18:49 -0800 Subject: [PATCH 02/19] docs: add MNCDS agent authority guidance --- AGENTS.md | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 AGENTS.md diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 0000000..dd700fb --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,50 @@ +# MNCDS repository agent guidance + +## Repository authority + +This repository is the development home and normative authority for the Machine-Native Complexity Development Specification (MNCDS). The sibling `machine-native-complexity-standard` repository is the authority for MNCS implementation-evidence semantics. + +Agents MUST keep those authorities separate. A change to MNCDS MUST NOT silently redefine MNCS, and an MNCS implementation detail MUST NOT become normative MNCDS behavior merely because it is convenient to reuse. + +## Migration discipline + +During migration from the historical combined MNCS repository: + +- preserve source provenance, version identities, release-candidate labels, and historical attribution; +- distinguish exact transfer from editorial cleanup and from normative change; +- do not rewrite historical records merely to fit the new repository layout; +- move MNCDS-owned schemas, conformance fixtures, validator surfaces, RFC material, and documentation here when ownership is clear; +- leave MNCS-owned implementation-evidence semantics in the MNCS repository; +- convert genuinely shared semantics into explicit, versioned interoperability boundaries rather than duplicated normative text; +- flag ambiguous ownership in the migration manifest instead of guessing; +- never describe a migrated artifact as independently reviewed merely because it crossed repositories. + +Migration-only pull requests SHOULD avoid changing normative meaning. If a semantic change is necessary, separate it into an RFC or clearly identified follow-up. + +## Evidence and status rules + +- Preserve `PASS`, `FAIL`, and `UNKNOWN`; `FAIL` dominates `UNKNOWN`, which dominates `PASS` when aggregation rules require an ordering. +- Missing, inaccessible, unsupported, crashed, or timed-out evidence does not become `PASS`. +- Keep candidate generation, evaluation, selection, release, governance, and independent-review authorities explicit. +- Do not let a generator, evaluator, Forge workflow, RAVEL loop, model, or agent promote its own output by implication. +- Do not use final/protected evaluation as repair feedback for the same candidate epoch. +- Local execution cannot create organizational independence, protected custody, or an independent witness. + +## Tool neutrality + +Models, generators, analyzers, compilers, providers, benchmarks, programming languages, MNCS Forge, RAVEL, Fabric, and case studies may implement or exercise MNCDS, but they are not normative authorities. + +Forge may be used as an optional development/evidence-control interface when configured, but Forge results remain development evidence within their declared authority. Source inspection is review, not a substitute for unavailable independent evidence. + +## Change discipline + +Before changing normative text or schemas: + +1. identify the affected MNCDS version and artifact identity; +2. identify compatibility impact on existing development records; +3. identify any affected MNCS binding explicitly; +4. add or update valid/invalid conformance vectors; +5. preserve prior released schemas and historical records; +6. use an RFC for changes to normative meaning, governance, result aggregation, authority, release semantics, or interoperability contracts. + +A cleaner implementation is not by itself permission to change the standard. From 7d4622c701ec320d8495be40e8fb59777d28f98b Mon Sep 17 00:00:00 2001 From: epi13 Date: Fri, 14 Aug 2026 12:19:01 -0800 Subject: [PATCH 03/19] docs: add contribution policy --- CONTRIBUTING.md | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..c98596a --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,46 @@ +# Contributing to MNCDS + +MNCDS welcomes specification, schema, conformance, tooling, research, documentation, and governance contributions. + +## Before contributing + +Read: + +- `README.md` for the repository boundary; +- `AGENTS.md` for authority and migration rules; +- `GOVERNANCE.md` for normative decision-making; +- `INTEROPERABILITY.md` before changing any MNCS binding; +- `MIGRATION.md` while the historical MNCDS material is still being transferred. + +## Pull requests + +A pull request should: + +1. explain the problem and intended outcome; +2. identify whether the change is migration-only, editorial, implementation-only, experimental, or normative; +3. identify compatibility effects on existing MNCDS records and versions; +4. include tests and valid/invalid fixtures where machine behavior changes; +5. update specification and user documentation together when semantics change; +6. identify affected MNCS bindings without redefining MNCS locally; +7. preserve historical schemas, records, provenance, and released identities; and +8. pass repository CI. + +Changes to normative meaning, schemas used as normative interoperability surfaces, result aggregation, authority rules, release/lifecycle semantics, governance, or MNCS interoperability require an RFC unless an already accepted RFC explicitly authorizes the change. + +## Migration contributions + +Migration is not permission to redesign the standard. A migration PR SHOULD keep exact transfer, editorial cleanup, and semantic change visibly separate. + +When historical ownership is ambiguous, add the item to the migration inventory with an explicit disposition such as `MOVE`, `KEEP_IN_MNCS`, `SHARED_INTERFACE`, `SPLIT`, or `REVIEW_REQUIRED`. Do not duplicate normative source merely to avoid deciding the boundary. + +## Development tooling + +Tooling in this repository is non-normative unless the specification explicitly defines an artifact format or algorithm as normative. A reference validator is an implementation of the specification, not the specification itself. + +Use reproducible local environments and keep generated artifacts out of version control unless they are intentional conformance fixtures or release artifacts. + +## Licensing and sensitive material + +By intentionally submitting a contribution, you agree that it is licensed under Apache-2.0 as described in `LICENSE`. + +Do not submit secrets, private datasets, proprietary transcripts, protected evaluation material, or evidence you do not have permission to redistribute. From 0d178f27c88b5067784e65ce3997a2f580d4ade1 Mon Sep 17 00:00:00 2001 From: epi13 Date: Fri, 14 Aug 2026 12:19:15 -0800 Subject: [PATCH 04/19] docs: establish independent MNCDS governance --- GOVERNANCE.md | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 GOVERNANCE.md diff --git a/GOVERNANCE.md b/GOVERNANCE.md new file mode 100644 index 0000000..c745e10 --- /dev/null +++ b/GOVERNANCE.md @@ -0,0 +1,68 @@ +# MNCDS Governance + +MNCDS is a lightweight, open, community-developed experimental specification with independent normative authority from MNCS. + +## Roles + +- **Maintainers** administer the repository and releases. +- **Editors** integrate approved normative text, schemas, and conformance material. +- **Contributors** submit proposals, code, evidence, documentation, and research. +- **RFC authors** own proposed normative changes through review. +- **Reviewers** provide technical, security, compatibility, process, and interoperability review. + +The repository owner acts as bootstrap maintainer until a public roster is adopted. Commit access alone does not imply normative authority. + +Current bootstrap assignments: + +- active maintainer roster: **OPEN**; +- active editor roster: **OPEN**; +- independent reviewer pool: **OPEN**; +- release authority: **OPEN**; +- signing authority and custody procedure: **OPEN**. + +These OPEN fields block claims that require those authorities, but they do not block research, migration, implementation, or release-candidate preparation. + +## Normative decisions + +Work is public and consensus-seeking. Changes to normative meaning, record semantics, schemas, result aggregation, authority rules, lifecycle requirements, governance, or the MNCS interoperability contract require an RFC and explicit review. + +Migration from the historical combined repository does **not** itself authorize semantic change. A migration commit may relocate or editorially normalize material while preserving meaning; semantic changes should be isolated and reviewed as such. + +A single maintainer MUST NOT both author and finally approve a contested normative change. Reviewers disclose conflicts material to the decision and recuse where impartiality is reasonably in doubt. + +## Relationship to MNCS governance + +MNCS and MNCDS are sibling specifications. Neither repository's maintainers acquire decision authority over the other merely through technical dependency. + +Cross-project changes should be handled as coordinated proposals with explicit version compatibility. An MNCDS RFC may propose a required MNCS interface version, but it cannot redefine MNCS. An MNCS change may require an MNCDS compatibility update, but it cannot silently rewrite MNCDS semantics. + +## Releases and versions + +MNCDS standard versions identify normative development-process semantics. Validator/tool packages use their own semantic versions. + +- compatible additive changes increment the standard minor version; +- breaking normative meaning increments the major version; +- patch-level implementation fixes do not silently alter schema meaning; +- experimental extensions remain non-normative until adopted through governance. + +Released schemas and historical record formats remain addressable. Release notes should identify accepted RFCs, compatibility, known limitations, conformance status, migration impact, and artifact hashes where applicable. + +## Independence and authority claims + +Repository governance cannot manufacture independent evaluation, protected custody, organizational independence, or an independent witness. Those claims require evidence from the relevant external actors and remain `UNKNOWN` when absent. + +Reference validators, agents, Forge workflows, RAVEL mechanisms, models, and orchestration systems are non-normative implementations or development mechanisms unless a specific normative artifact explicitly defines an interface they must satisfy. + +## Bootstrap completion + +Bootstrap governance is complete only after the project publicly records: + +- an active maintainer/editor roster; +- succession, inactivity, removal, and emergency-access rules; +- release and signing authorities; +- an independent reviewer pool or a disclosed inability to form one; +- conflict and material tool-ownership disclosure rules; +- a durable RFC process for changing development-process semantics; and +- a stable cross-project compatibility process with MNCS. + +Until then, the project should describe itself as experimental and avoid stronger governance or independence claims. From 33df0be21e27dd3ad1f63edba9328c093d4c16df Mon Sep 17 00:00:00 2001 From: epi13 Date: Fri, 14 Aug 2026 12:19:32 -0800 Subject: [PATCH 05/19] docs: define MNCS-MNCDS interoperability boundary --- INTEROPERABILITY.md | 61 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 INTEROPERABILITY.md diff --git a/INTEROPERABILITY.md b/INTEROPERABILITY.md new file mode 100644 index 0000000..4b3e299 --- /dev/null +++ b/INTEROPERABILITY.md @@ -0,0 +1,61 @@ +# MNCS ↔ MNCDS Interoperability + +MNCS and MNCDS are sibling specifications with separate normative authority, versioning, governance, conformance, and release histories. + +## Responsibility boundary + +### MNCS owns + +MNCS defines implementation-evidence semantics: the evidence and assurance structures used to support claims about an implementation. + +### MNCDS owns + +MNCDS defines development-process semantics: how implementations are generated, evaluated, selected, released, monitored, regenerated, replaced, and retired, including process authority, candidate lineage, partitions, reproducibility, selection, release, and lifecycle records. + +## Binding rule + +MNCDS MAY reference an MNCS result or artifact through an explicit versioned binding. Such a binding should identify, at minimum, the relevant: + +- MNCS specification/profile version; +- subject/candidate identity; +- contract identity; +- environment identity or declared compatibility envelope; +- result identity or canonical artifact digest; and +- compatibility status. + +MNCDS MUST NOT copy MNCS normative semantics into this repository merely to validate a binding. It may define what information an MNCDS record requires from MNCS and how mismatches affect MNCDS, while the meaning of the MNCS artifact remains controlled by MNCS. + +MNCS likewise should not embed MNCDS development-process semantics merely to consume an MNCDS record. + +## Compatibility outcomes + +Cross-project compatibility should be explicit and conservative: + +- an exact supported binding may be accepted according to the applicable MNCDS rule; +- an identity or required semantic mismatch is `FAIL` where the specification requires agreement; +- a missing, inaccessible, unsupported, or unrecognized binding is `UNKNOWN` unless a stronger normative rule requires failure; +- compatibility shims are non-normative unless standardized through the appropriate project governance. + +## Version evolution + +A release of either project MUST NOT silently change the meaning of a released version of the other. + +When one project evolves: + +1. publish the new version under its own governance; +2. identify interoperability effects; +3. update compatibility tables or adapters in the consuming project; +4. add cross-version conformance fixtures where useful; and +5. preserve prior released bindings and historical records. + +No synchronized release cadence is required. MNCDS 0.x may support multiple MNCS versions, and MNCS may exist independently of MNCDS. + +## Shared code + +Shared implementation code is permitted, but shared code does not create shared normative authority. If both validators need a canonicalization, identity, archive, or transport implementation, prefer a clearly versioned library or duplicated non-normative implementation over ambiguous ownership of specification text. + +A future common interoperability repository or package may be introduced if genuinely shared protocol surface becomes large enough to justify it. Until then, keep the boundary explicit and small. + +## Family-level documentation + +The MNCS Atlas may explain how MNCS and MNCDS fit together for contributors and agents, but it is descriptive rather than normative. Normative meaning remains in the owning repository. From a8b11fbd95758e07e2c15cbdf927ab544599762d Mon Sep 17 00:00:00 2001 From: epi13 Date: Fri, 14 Aug 2026 12:20:09 -0800 Subject: [PATCH 06/19] docs: define provenance-preserving extraction plan --- MIGRATION.md | 97 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 MIGRATION.md diff --git a/MIGRATION.md b/MIGRATION.md new file mode 100644 index 0000000..7ba79c9 --- /dev/null +++ b/MIGRATION.md @@ -0,0 +1,97 @@ +# MNCDS Extraction from the Historical MNCS Repository + +This repository is being established before the normative MNCDS material is extracted from `epi13/machine-native-complexity-standard`. + +The goal is **not** to fork MNCS. The goal is to make the existing conceptual separation between MNCS and MNCDS real at the repository, release, governance, validator, and conformance layers. + +## Migration invariants + +The transfer MUST preserve: + +1. normative meaning unless a separate reviewed change says otherwise; +2. version and release-candidate identities; +3. schema identifiers and compatibility behavior; +4. valid/invalid conformance behavior; +5. record identities and historical evidence; +6. commit/file provenance sufficient to trace migrated material back to its source; +7. Apache-2.0 licensing and attribution; and +8. explicit `UNKNOWN` states and authority limitations. + +A cleaner repository layout is not evidence that a semantic change is safe. + +## Recommended migration sequence + +### 1. Freeze a source point + +At migration time, record the exact MNCS source commit used for extraction. The bootstrap inspection observed source commit `f0088c4d46dec84f289d9b4417eec32b0ac028e6`, but the transfer agent MUST refresh this and use the actual current source commit rather than assuming that observation remains current. + +### 2. Build a complete inventory + +Start with `migration/inventory.json`, then expand it from the frozen source tree. Every MNCDS-related artifact should receive one disposition: + +- `MOVE` — normative or implementation material owned by MNCDS; +- `KEEP_IN_MNCS` — owned by MNCS; +- `SHARED_INTERFACE` — keep normative ownership in one project and consume through a versioned interface; +- `SPLIT` — a mixed file/module must be separated without changing behavior; +- `REVIEW_REQUIRED` — ownership or semantics are ambiguous. + +### 3. Transfer normative source first + +Move the MNCDS specification, records-and-decisions material, MNCDS-owned schemas, and clearly MNCDS-specific conformance vectors before restructuring implementation code. + +Do not delete the historical source from MNCS until the new repository has equivalent content, CI, provenance notes, and cross-links. + +### 4. Separate validator surfaces + +The historical Python implementation is mixed under `src/mncs_validator`. Extract MNCDS validation behavior behind a dedicated package/CLI surface here. Preserve existing `mncds` command behavior and fixture outcomes before refactoring internals. + +Shared low-level utilities such as canonical JSON, hashing, safe file handling, or generic result types may remain duplicated temporarily or become explicitly versioned libraries later. Avoid creating a hidden runtime dependency from the MNCDS validator to the MNCS repository checkout. + +### 5. Split conformance and examples + +Copy MNCDS-specific valid/invalid vectors and development-record examples here. For combined release-candidate corpora, split by normative owner while retaining cross-project integration cases in a clearly labeled interoperability area. + +Cross-project fixtures should identify the exact MNCS and MNCDS versions they exercise. + +### 6. Re-home RFCs and documentation + +Move RFCs whose normative subject is MNCDS. For mixed MNCS/MNCDS RFCs, preserve the historical document and either: + +- keep an archival copy with provenance plus successor RFCs in the owning repositories; or +- retain one canonical historical source and link to it from both projects. + +Do not rewrite history so that an old combined RFC appears to have originated here. + +### 7. Establish independent release machinery + +MNCDS should end with its own: + +- package metadata and `mncds` CLI; +- CI and conformance checks; +- release tags and changelog; +- specification/schema version table; +- RFC index; +- governance and security policy; +- release checklist; and +- compatibility matrix for supported MNCS bindings. + +### 8. Clean the MNCS repository last + +Only after MNCDS is independently testable should the MNCS repository remove transferred implementation/specification material. Replace removed material with concise pointers and compatibility documentation, not duplicated normative text. + +## Acceptance criteria for the extraction + +The migration is complete when: + +- MNCDS 0.1-rc.1 can be located and validated entirely from this repository; +- all MNCDS-owned schemas and conformance vectors live here; +- the `mncds` validator/CLI no longer depends on private knowledge of the MNCS repository layout; +- equivalent pre/post-migration fixture outcomes are demonstrated; +- cross-project MNCS bindings remain explicit and versioned; +- historical provenance is documented; +- the MNCS repository can remove MNCDS-owned source without breaking MNCS-only validation; and +- neither repository contains an accidental second normative copy of the other's standard. + +## Important non-goal + +Do not use extraction as an opportunity to make MNCDS more tightly coupled to the rest of the MNCS tooling family. The purpose of this repository boundary is to let MNCDS evolve cleanly as an independent companion specification while keeping integration explicit. From 12f721a97fd0444b32c466a9887b4c8e30f98ef8 Mon Sep 17 00:00:00 2001 From: epi13 Date: Fri, 14 Aug 2026 12:20:27 -0800 Subject: [PATCH 07/19] chore: add migration ownership inventory --- migration/inventory.json | 106 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 migration/inventory.json diff --git a/migration/inventory.json b/migration/inventory.json new file mode 100644 index 0000000..eb24b16 --- /dev/null +++ b/migration/inventory.json @@ -0,0 +1,106 @@ +{ + "format": "mncds-repository-migration-inventory-0.1", + "source_repository": "epi13/machine-native-complexity-standard", + "bootstrap_observed_source_commit": "f0088c4d46dec84f289d9b4417eec32b0ac028e6", + "source_commit_policy": "Refresh and pin the actual source commit at migration time; do not treat bootstrap_observed_source_commit as a frozen migration source.", + "target_repository": "epi13/machine-native-complexity-development-specification", + "dispositions": [ + "MOVE", + "KEEP_IN_MNCS", + "SHARED_INTERFACE", + "SPLIT", + "REVIEW_REQUIRED" + ], + "items": [ + { + "source": "spec/MNCDS-v0.1-draft.md", + "target": "spec/MNCDS-v0.1-draft.md", + "disposition": "MOVE", + "reason": "MNCDS normative historical specification" + }, + { + "source": "spec/MNCDS-v0.1-rc.1.md", + "target": "spec/MNCDS-v0.1-rc.1.md", + "disposition": "MOVE", + "reason": "current MNCDS 0.1 release-candidate specification" + }, + { + "source": "spec/MNCDS-v0.1-records-and-decisions.md", + "target": "spec/MNCDS-v0.1-records-and-decisions.md", + "disposition": "MOVE", + "reason": "MNCDS records and design decisions" + }, + { + "source": "spec/MNCS-v0.3-MNCDS-v0.1-decisions.md", + "target": null, + "disposition": "REVIEW_REQUIRED", + "reason": "historical mixed-authority decision record; preserve provenance and decide archival/cross-link strategy" + }, + { + "source": "schemas/mncds-development-record-0.1.schema.json", + "target": "schemas/mncds-development-record-0.1.schema.json", + "disposition": "MOVE", + "reason": "versioned MNCDS aggregate schema" + }, + { + "source": "schemas/mncds-development-record.schema.json", + "target": "schemas/mncds-development-record.schema.json", + "disposition": "MOVE", + "reason": "historical/current MNCDS development-record schema surface" + }, + { + "source": "schemas/mncs-*", + "target": null, + "disposition": "KEEP_IN_MNCS", + "reason": "MNCS-owned schema namespace unless an individual artifact is proven to be an MNCDS-owned interface" + }, + { + "source": "examples/mncds-0.1-rc/**", + "target": "examples/mncds-0.1-rc/**", + "disposition": "MOVE", + "reason": "MNCDS release-candidate examples referenced by the current MNCS repository README" + }, + { + "source": "conformance/release-candidate/**", + "target": "conformance/**", + "disposition": "SPLIT", + "reason": "historical corpus is described as shared MNCS/MNCDS vectors; separate by normative owner and preserve explicit interoperability cases" + }, + { + "source": "src/mncs_validator/**", + "target": "src/**", + "disposition": "SPLIT", + "reason": "historical validator implementation mixes MNCS and MNCDS surfaces; extract MNCDS behavior while preserving fixture outcomes" + }, + { + "source": "tests/**", + "target": "tests/**", + "disposition": "SPLIT", + "reason": "move MNCDS-specific tests, keep MNCS-specific tests, and classify integration tests explicitly" + }, + { + "source": "rfcs/**", + "target": "rfcs/**", + "disposition": "REVIEW_REQUIRED", + "reason": "classify each RFC by normative subject; mixed historical RFCs require provenance-preserving treatment" + }, + { + "source": "docs/**", + "target": "docs/**", + "disposition": "REVIEW_REQUIRED", + "reason": "move MNCDS-owned guidance, keep MNCS-owned guidance, and rewrite only future-facing cross-project navigation" + }, + { + "source": "case-studies/**", + "target": "case-studies/**", + "disposition": "REVIEW_REQUIRED", + "reason": "case studies may exercise MNCS, MNCDS, or both; ownership should follow the primary normative purpose rather than file naming" + }, + { + "source": "execution-assurance and other mncs-test-evidence surfaces", + "target": null, + "disposition": "SHARED_INTERFACE", + "reason": "keep owning semantics with MNCS unless a specific MNCDS validator surface is independently specified; consume through explicit versioned bindings" + } + ] +} From ce93d794f170447044aa7824332170e8c568ab5e Mon Sep 17 00:00:00 2001 From: epi13 Date: Fri, 14 Aug 2026 12:20:42 -0800 Subject: [PATCH 08/19] docs: add independent repository architecture --- docs/architecture.md | 47 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 docs/architecture.md diff --git a/docs/architecture.md b/docs/architecture.md new file mode 100644 index 0000000..86576b0 --- /dev/null +++ b/docs/architecture.md @@ -0,0 +1,47 @@ +# MNCDS Repository Architecture + +This repository separates four concerns that were historically co-located with MNCS. + +## 1. Normative layer + +`spec/` and normative schemas define MNCDS meaning. They own development-process concepts such as charter binding, baseline/environment lock, authority separation, partitions, candidate lineage, reproducibility, selection, release, lifecycle, and MNCS binding requirements. + +Normative meaning changes only through the MNCDS governance process. + +## 2. Conformance layer + +`conformance/` contains machine-checkable valid/invalid vectors and release-candidate corpora. Conformance artifacts demonstrate whether an implementation agrees with a declared MNCDS version; they do not override specification meaning. + +Cross-project conformance should live under an explicit interoperability namespace and identify both MNCDS and MNCS versions. + +## 3. Implementation layer + +Reference validators, CLIs, helper libraries, scripts, Forge providers, and other tooling implement or exercise MNCDS. They are replaceable and non-normative unless a normative specification explicitly fixes an algorithm or wire representation. + +The target architecture should allow the `mncds` validator to operate from this repository without requiring an MNCS repository checkout. Dependencies on MNCS artifacts should be versioned inputs, packages, or fixtures rather than source-tree assumptions. + +## 4. Research and integration layer + +Case studies, recursive agents, RAVEL, Fabric, MNCS Forge, language implementations, and experimental evaluators may produce MNCDS records or evidence. Their behavior is bounded by declared authority and cannot promote itself into normative meaning. + +## Dependency direction + +```text +MNCDS specification + | + +--> MNCDS schemas / conformance contracts + | | + | +--> reference validators and tools + | + +--> versioned MNCS interoperability requirement + | + +--> externally supplied MNCS artifacts/results +``` + +The important rule is that implementation code depends on specifications and interfaces; specifications do not depend on a particular agent, model, validator, Forge workflow, or orchestration system. + +## Release independence + +MNCDS releases independently of MNCS. A release records the MNCS versions/interfaces it supports, but no synchronized version numbering or release date is required. + +This permits either project to evolve while compatibility remains explicit and testable. From 7adff4139f9d3658449aed930f0cb3c164b6b2b9 Mon Sep 17 00:00:00 2001 From: epi13 Date: Fri, 14 Aug 2026 12:20:48 -0800 Subject: [PATCH 09/19] docs: establish specification directory contract --- spec/README.md | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 spec/README.md diff --git a/spec/README.md b/spec/README.md new file mode 100644 index 0000000..490c953 --- /dev/null +++ b/spec/README.md @@ -0,0 +1,9 @@ +# Specification + +This directory is the home of normative MNCDS specification text. + +During extraction, preserve historical filenames and version identities such as `MNCDS-v0.1-draft.md` and `MNCDS-v0.1-rc.1.md`. Do not silently rewrite a historical release candidate into a new repository-native edition. + +Future versions SHOULD use stable versioned filenames and release notes that identify accepted RFCs, compatibility, known limitations, and the supported MNCS interoperability envelope. + +Normative changes require the process in `GOVERNANCE.md`. Editorial fixes that do not change meaning should still preserve released artifacts and issue corrected successor material where necessary. From 644f46351d3929e03757788634ce9c5e07a9d300 Mon Sep 17 00:00:00 2001 From: epi13 Date: Fri, 14 Aug 2026 12:20:56 -0800 Subject: [PATCH 10/19] docs: establish schema ownership boundary --- schemas/README.md | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 schemas/README.md diff --git a/schemas/README.md b/schemas/README.md new file mode 100644 index 0000000..9ed472a --- /dev/null +++ b/schemas/README.md @@ -0,0 +1,7 @@ +# Schemas + +This directory contains versioned machine-readable schemas owned by MNCDS. + +Schema identifiers and released schema behavior are compatibility surfaces. Migration MUST preserve existing IDs, required fields, validation behavior, and historical versions unless a reviewed normative change explicitly supersedes them. + +MNCS-owned schemas remain in the MNCS repository. If an MNCDS record binds to an MNCS artifact, validate the MNCDS side of that binding here and consume the MNCS artifact through its declared version/interface rather than copying the MNCS schema into this directory. From aa7b93cb41b7f17bca0bb36b439269622354c464 Mon Sep 17 00:00:00 2001 From: epi13 Date: Fri, 14 Aug 2026 12:21:02 -0800 Subject: [PATCH 11/19] docs: establish conformance layout --- conformance/README.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 conformance/README.md diff --git a/conformance/README.md b/conformance/README.md new file mode 100644 index 0000000..061e597 --- /dev/null +++ b/conformance/README.md @@ -0,0 +1,19 @@ +# Conformance + +This directory contains machine-checkable artifacts used to test implementations against a declared MNCDS version. + +Recommended structure after migration: + +```text +conformance/ + 0.1/ + valid/ + invalid/ + corpus/ + interoperability/ + mncs-/ +``` + +A conformance fixture MUST identify the normative version it exercises. Cross-project fixtures MUST identify both MNCDS and MNCS versions and must not blur an MNCS result into an MNCDS result. + +`PASS` means only that the tested implementation satisfied the declared conformance case within its scope. It does not create organizational independence, protected custody, security assurance, or release authority. From eb8b42b89563b6bd1631b629775ad31d0390d8af Mon Sep 17 00:00:00 2001 From: epi13 Date: Fri, 14 Aug 2026 12:21:10 -0800 Subject: [PATCH 12/19] docs: establish RFC ownership and migration rules --- rfcs/README.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 rfcs/README.md diff --git a/rfcs/README.md b/rfcs/README.md new file mode 100644 index 0000000..62b203e --- /dev/null +++ b/rfcs/README.md @@ -0,0 +1,16 @@ +# MNCDS RFCs + +RFCs are the review path for changes to normative MNCDS meaning, governance, authority rules, lifecycle semantics, conformance contracts, or MNCS interoperability. + +During migration, historical RFCs from the combined repository must be classified by normative subject. MNCDS-only RFCs may move here with provenance preserved. MNCS-only RFCs stay with MNCS. Mixed historical RFCs should remain traceable as historical combined documents and may be followed by project-specific successor RFCs rather than rewritten to imply a different origin. + +A future RFC template should require: + +- problem statement and scope; +- normative/non-normative classification; +- compatibility and migration effects; +- record/schema/conformance impact; +- authority and security considerations; +- MNCS interoperability impact, if any; +- alternatives considered; and +- rollout/release plan. From 8a8e9db3da6f7b2fec359ddf7a8590b1e03c3bb6 Mon Sep 17 00:00:00 2001 From: epi13 Date: Fri, 14 Aug 2026 12:21:26 -0800 Subject: [PATCH 13/19] ci: add standard-library repository bootstrap checker --- scripts/check_repository.py | 119 ++++++++++++++++++++++++++++++++++++ 1 file changed, 119 insertions(+) create mode 100644 scripts/check_repository.py diff --git a/scripts/check_repository.py b/scripts/check_repository.py new file mode 100644 index 0000000..312c3a9 --- /dev/null +++ b/scripts/check_repository.py @@ -0,0 +1,119 @@ +#!/usr/bin/env python3 +"""Bootstrap repository invariants for MNCDS. + +This checker intentionally uses only the Python standard library so it can run before +the reference validator/tooling migration is complete. It checks repository structure +and migration metadata; it is not an MNCDS conformance validator. +""" + +from __future__ import annotations + +import json +from pathlib import Path +import sys + +ROOT = Path(__file__).resolve().parents[1] + +REQUIRED_PATHS = [ + "README.md", + "AGENTS.md", + "CONTRIBUTING.md", + "GOVERNANCE.md", + "INTEROPERABILITY.md", + "MIGRATION.md", + "spec/README.md", + "schemas/README.md", + "conformance/README.md", + "rfcs/README.md", + "docs/architecture.md", + "migration/inventory.json", +] + +ALLOWED_DISPOSITIONS = { + "MOVE", + "KEEP_IN_MNCS", + "SHARED_INTERFACE", + "SPLIT", + "REVIEW_REQUIRED", +} + + +def fail(message: str) -> None: + print(f"ERROR: {message}", file=sys.stderr) + + +def main() -> int: + errors = 0 + + for relative in REQUIRED_PATHS: + path = ROOT / relative + if not path.exists(): + fail(f"required path missing: {relative}") + errors += 1 + + inventory_path = ROOT / "migration/inventory.json" + if inventory_path.exists(): + try: + inventory = json.loads(inventory_path.read_text(encoding="utf-8")) + except (OSError, json.JSONDecodeError) as exc: + fail(f"cannot parse migration inventory: {exc}") + errors += 1 + else: + if inventory.get("format") != "mncds-repository-migration-inventory-0.1": + fail("unexpected migration inventory format") + errors += 1 + + declared = set(inventory.get("dispositions", [])) + if declared != ALLOWED_DISPOSITIONS: + fail( + "migration disposition set mismatch: " + f"expected {sorted(ALLOWED_DISPOSITIONS)}, got {sorted(declared)}" + ) + errors += 1 + + items = inventory.get("items") + if not isinstance(items, list) or not items: + fail("migration inventory must contain at least one item") + errors += 1 + else: + for index, item in enumerate(items): + if not isinstance(item, dict): + fail(f"migration item {index} is not an object") + errors += 1 + continue + if not item.get("source"): + fail(f"migration item {index} has no source") + errors += 1 + if item.get("disposition") not in ALLOWED_DISPOSITIONS: + fail( + f"migration item {index} has invalid disposition: " + f"{item.get('disposition')!r}" + ) + errors += 1 + if not item.get("reason"): + fail(f"migration item {index} has no reason") + errors += 1 + + readme = ROOT / "README.md" + if readme.exists(): + text = readme.read_text(encoding="utf-8") + required_phrases = [ + "independently versioned, governed, and released", + "Machine-Native Complexity Standard (MNCS)", + "Repository bootstrap in progress", + ] + for phrase in required_phrases: + if phrase not in text: + fail(f"README boundary phrase missing: {phrase!r}") + errors += 1 + + if errors: + print(f"repository bootstrap check failed with {errors} error(s)", file=sys.stderr) + return 1 + + print("MNCDS repository bootstrap checks passed") + return 0 + + +if __name__ == "__main__": + raise SystemExit(main()) From 642f41c9e4b0fca31452865e2d6c91984aad03c0 Mon Sep 17 00:00:00 2001 From: epi13 Date: Fri, 14 Aug 2026 12:21:33 -0800 Subject: [PATCH 14/19] ci: add bootstrap GitHub Actions workflow --- .github/workflows/ci.yml | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 .github/workflows/ci.yml diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml new file mode 100644 index 0000000..21adb67 --- /dev/null +++ b/.github/workflows/ci.yml @@ -0,0 +1,35 @@ +name: CI + +on: + push: + branches: [main] + pull_request: + +permissions: + contents: read + +jobs: + repository-bootstrap: + runs-on: ubuntu-latest + steps: + - name: Check out repository + uses: actions/checkout@v5 + + - name: Set up Python + uses: actions/setup-python@v6 + with: + python-version: '3.13' + + - name: Validate repository invariants + run: python scripts/check_repository.py + + - name: Parse JSON files + run: | + python - <<'PY' + import json + from pathlib import Path + + for path in sorted(Path('.').rglob('*.json')): + json.loads(path.read_text(encoding='utf-8')) + print(f'validated JSON: {path}') + PY From b1c356da431ef3375541802742669c2babc6e833 Mon Sep 17 00:00:00 2001 From: epi13 Date: Fri, 14 Aug 2026 12:21:42 -0800 Subject: [PATCH 15/19] docs: add MNCDS security policy --- SECURITY.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 SECURITY.md diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..c41e8de --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,15 @@ +# Security policy + +MNCDS is experimental and pre-1.0. Until the validator migration is complete, supported-version statements remain provisional. + +Report validator path escape, hash or identity confusion, schema bypass, unsafe execution, protected-evidence exposure, archive handling, dependency, release-integrity, or other security-sensitive issues privately through GitHub's security advisory interface. Do not open a public exploit issue before coordination. + +Include the affected version or commit, impact, minimal reproduction when safe to share, and any suggested mitigation. + +## Scope boundary + +An MNCDS validator should treat development records, candidate metadata, archives, bindings, and externally supplied evidence as untrusted input. Validation must not silently execute candidate code or external evidence merely because a record references it. + +MNCDS conformance is not a security warranty. A `PASS` result does not establish sandboxing, organizational independence, protected custody, confidentiality, operational safety, or resistance to a malicious host unless those properties are separately supported by the required evidence. + +Security issues in MNCS-owned implementation-evidence semantics belong to the MNCS repository unless they also expose a distinct MNCDS specification, interoperability, or validator defect. From 8f00080f56f3a4cf0f2cf4c7ff126646ae72dbb0 Mon Sep 17 00:00:00 2001 From: epi13 Date: Fri, 14 Aug 2026 12:21:49 -0800 Subject: [PATCH 16/19] docs: add code of conduct --- CODE_OF_CONDUCT.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 CODE_OF_CONDUCT.md diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md new file mode 100644 index 0000000..c94633e --- /dev/null +++ b/CODE_OF_CONDUCT.md @@ -0,0 +1,15 @@ +# Code of Conduct + +## Our commitment + +We pledge to make participation in MNCDS free of harassment regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, experience, education, socioeconomic status, nationality, appearance, race, religion, or sexual identity and orientation. + +## Expected behavior + +Be respectful, critique ideas with evidence, acknowledge uncertainty, share credit, and make space for different backgrounds and tools. Unacceptable behavior includes harassment, threats, sexualized attention, deliberate intimidation, sustained disruption, doxxing, or publishing private communications without permission. + +## Enforcement + +Report conduct concerns privately through the repository's security contact when privacy is needed, or to the maintainers listed in governance. Maintainers should avoid conflicts of interest, investigate proportionately, and may warn, moderate, temporarily exclude, or permanently exclude participants. + +This policy applies in project spaces and when someone publicly represents MNCDS. It is adapted in substance from the Contributor Covenant 2.1. From 7ac9bf07e0d689c912023cfb489fa6b1fe37640c Mon Sep 17 00:00:00 2001 From: epi13 Date: Fri, 14 Aug 2026 12:22:34 -0800 Subject: [PATCH 17/19] chore: add authority-aware pull request template --- .github/pull_request_template.md | 35 ++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 .github/pull_request_template.md diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md new file mode 100644 index 0000000..87bd820 --- /dev/null +++ b/.github/pull_request_template.md @@ -0,0 +1,35 @@ +## Summary + + + +## Change class + +Check all that apply: + +- [ ] Migration-only transfer +- [ ] Editorial / no normative meaning change +- [ ] Implementation / tooling only +- [ ] Experimental / non-normative +- [ ] Normative specification change +- [ ] Schema or conformance change +- [ ] Governance change +- [ ] MNCS interoperability change + +## Authority and compatibility + +- MNCDS version(s) affected: +- Existing record/schema compatibility impact: +- MNCS version/interface affected, if any: +- Historical provenance preserved where applicable: yes / no / not applicable + +## Evidence + + + +## Boundary checks + +- [ ] This PR does not silently redefine MNCS semantics. +- [ ] This PR does not turn missing/unsupported evidence into `PASS`. +- [ ] This PR does not let a generator/evaluator/tool promote its own output by implication. +- [ ] Historical released artifacts are preserved or explicitly superseded. +- [ ] If normative meaning changes, the governing RFC is linked. From 3052c983d311410e90ac1f06ba4d7b6f5f011749 Mon Sep 17 00:00:00 2001 From: epi13 Date: Fri, 14 Aug 2026 12:22:40 -0800 Subject: [PATCH 18/19] docs: initialize independent MNCDS changelog --- CHANGELOG.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 CHANGELOG.md diff --git a/CHANGELOG.md b/CHANGELOG.md new file mode 100644 index 0000000..9700ebc --- /dev/null +++ b/CHANGELOG.md @@ -0,0 +1,15 @@ +# Changelog + +All notable MNCDS specification and reference-tooling changes should be recorded here. + +## Unreleased + +### Repository extraction + +- Established `machine-native-complexity-development-specification` as the independent development home for MNCDS. +- Defined separate MNCDS normative authority and governance from MNCS. +- Added explicit MNCS ↔ MNCDS interoperability rules. +- Added a provenance-preserving extraction plan and machine-readable migration inventory. +- Added specification, schema, conformance, RFC, documentation, and CI scaffolding. + +No normative MNCDS meaning is changed by this repository bootstrap. MNCDS 0.1-rc.1 remains sourced from the historical combined MNCS repository until the migration is completed and validated. From b1ea402d540fd7756a481a762b357dbf6a2e9b70 Mon Sep 17 00:00:00 2001 From: epi13 Date: Fri, 14 Aug 2026 12:22:50 -0800 Subject: [PATCH 19/19] docs: add extraction and independence roadmap --- ROADMAP.md | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 ROADMAP.md diff --git a/ROADMAP.md b/ROADMAP.md new file mode 100644 index 0000000..0391a5f --- /dev/null +++ b/ROADMAP.md @@ -0,0 +1,48 @@ +# MNCDS Repository Roadmap + +## Phase 0 — Repository bootstrap + +- [x] Independent project identity and scope +- [x] Governance and contribution boundary +- [x] MNCS interoperability contract +- [x] Migration plan and ownership inventory +- [x] Directory and CI scaffolding + +## Phase 1 — Provenance-preserving extraction + +- [ ] Freeze the actual MNCS source commit used for migration +- [ ] Transfer MNCDS 0.1 draft and 0.1-rc.1 specification material +- [ ] Transfer MNCDS-owned schemas and examples +- [ ] Split shared release-candidate conformance vectors by normative owner +- [ ] Classify historical RFCs, docs, and case studies +- [ ] Record provenance for migrated artifacts + +## Phase 2 — Independent validation surface + +- [ ] Extract the `mncds` CLI and validator behavior from the mixed historical implementation +- [ ] Preserve pre/post-migration fixture outcomes +- [ ] Remove source-tree coupling to the MNCS repository +- [ ] Establish package metadata and developer environment +- [ ] Add MNCDS-specific unit, schema, adversarial, and conformance CI + +## Phase 3 — Independent release line + +- [ ] Publish a version/support matrix +- [ ] Establish release checklist and artifact hashing +- [ ] Establish independent tags/releases for MNCDS +- [ ] Document supported MNCS binding versions +- [ ] Complete or explicitly disclose bootstrap governance gaps + +## Phase 4 — MNCS cleanup + +Performed in the sibling MNCS repository after this repository is independently testable: + +- [ ] Remove transferred MNCDS normative source from active MNCS paths +- [ ] Replace it with concise pointers and compatibility documentation +- [ ] Split or simplify mixed validator/package surfaces +- [ ] Verify MNCS-only validation remains functional +- [ ] Ensure no accidental duplicate normative copies remain + +## Long-term direction + +Keep MNCDS focused on development-process governance and evidence, not on becoming a general orchestration framework. Forge, RAVEL, Fabric, local models, frontier agents, programming languages, and other mechanisms should be able to implement or exercise MNCDS without becoming required architecture of the specification itself.