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. 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 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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" + } + ] +} 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. 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. 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()) 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.