Bootstrap MNCDS as an independent specification repository

.github/pull_request_template.md

@@ -0,0 +1,35 @@
+## Summary
+
+<!-- What problem does this change solve? -->
+
+## 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
+
+<!-- Tests, valid/invalid fixtures, before/after results, migration equivalence, or limitations. -->
+
+## 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.

.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

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.

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.

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.

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.

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.

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.