MNCS Atlas

The map of the MNCS project family

Machine-native systems should make authority, evidence, and uncertainty explicit.

MNCS Atlas is the family-level guide to the Machine-Native Complexity Standard research ecosystem: what it is, how its projects fit together, how the reference operator stack actually runs, where authority lives, and where a human or agent should start.

Find your entry point See the architecture View on GitHub

What is MNCS?

A research program for accepting machine-produced software through bounded evidence.

The Machine-Native Complexity Standard (MNCS) is an open experimental standard for accepting generated or machine-optimized implementations through bounded evidence. The Machine-Native Complexity Development Specification (MNCDS) is an independently versioned companion that governs the development process.

The wider project family tests what happens when contracts, evidence, semantic identity, authority, execution, coordination, learning, and operator control are designed for machine participation from the beginning—while remaining inspectable by humans.

Atlas is non-normative. MNCS and MNCDS remain the only specification authorities. Harness, Control, Fabric, Forge, Commons, and the rest of the operator stack are not required for MNCS conformance.

Transport ≠ trust Execution ≠ conformance Publication ≠ acceptance Learning ≠ authority Missing evidence = UNKNOWN

Start with the job

You should not need to read the whole family before finding the right boundary.

Choose the thing you are trying to accomplish. Then go deep in the component that actually owns it.

01

Standard

Understand acceptance or conformance

Start with MNCS. Tool documentation cannot override the governing implementation-evidence and status semantics.

Open MNCS ↗
02

Specification

Understand the development process

Start with MNCDS, the independently versioned development-process specification for candidate lifecycle and evidence flow.

Open MNCDS ↗
03

Development

Build or evaluate a candidate

Start with Forge for declared development/evidence workflows, then the governing MNCS or MNCDS validator for the claim being evaluated.

Open Forge ↗
04

Operator

Route models or operate the workspace

MNCS Harness owns model/tool policy and deployment acceptance. MNCS Control MCP owns protected remote workspace access. Neither is a normative MNCS requirement.

Read the operating model ↗
05

Execution

Run work on an exact worker

Start with Fabric. It owns worker presence, target admission, transport, bounded execution, retry identity, and execution evidence.

Open Fabric ↗
06

Knowledge

Share findings, work, or decisions

Start with Commons for durable structured coordination. Publication makes a record available; it does not make it trusted.

Open Commons ↗
07

Learning

Learn from governed outcomes

RAVEL and MNEL can change future strategy and experiments without rewriting the status of the evidence they consume.

See learning projects ↓
08

Research

Challenge a claim empirically

Use Reference Studies for frozen empirical protocols or an independent validator for a supported normative record subset.

Open Reference Studies ↗
09

For agents & tooling

Load the family map programmatically

atlas.json exposes stable IDs, project roles, operator components, relationships, entry points, and freshness guidance.

Open atlas.json ↗ Schema ↗

Authority architecture

Different layers, deliberately different authority.

The family becomes understandable when responsibility and authority are mapped before runtime call paths.

01

Execution is not conformance

Fabric can establish that an identified bounded execution occurred under recorded conditions. That does not make the workload formally MNCS-conformant.

02

Coordination is not command

Commons can preserve knowledge and durable work state without becoming an unrestricted permission channel or source of truth.

03

Learning remains governed

RAVEL and MNEL can improve strategy from validated experience, but confidence cannot turn unsupported evidence into PASS.

04

Persistence has an owner

Fabric owns fleet/execution lifecycle; Commons owns knowledge/work persistence. Consumers do not gain lifecycle authority by observing them.

Reference operator stack

What a representative MNCS work path actually looks like.

The runtime path is descriptive, not normative. It explains the reference operator stack without making Control, MNCS Harness, Fabric, Forge, or Commons mandatory for MNCS conformance.

  1. 1
    Human or external agent states intent

    A human or external agent requests bounded work and supplies approvals through its own interface.

  2. 2
    Control bounds workspace access

    MNCS Control gets the client in and constrains where remote/operator actions may occur through a fail-closed sandboxed boundary.

  3. 3
    Harness or Forge establishes the work

    MNCS Harness owns model/tool policy and deployment acceptance; Forge owns declared development/evidence workflows and lineage. Neither is a normative MNCS requirement.

  4. 4
    Fabric executes when distribution is needed

    The persistent controller rechecks an exact target, transports the bounded workload, manages durable execution, and records execution evidence.

  5. 5
    Providers emit observations

    An identified model, compiler, analyzer, verifier, or other tool returns only the bounded computation it was asked to perform.

  6. 6
    Commons preserves reusable knowledge

    Findings, work, replications, advisories, and decisions can outlive the client that produced them without becoming automatically trusted.

  7. 7
    Evaluation stays scoped

    Validators or studies judge only the claims their contracts/protocols authorize; remaining gaps stay UNKNOWN.

Authority view

Who may claim what?

Use the authority architecture when deciding whether a result is execution evidence, a verifier observation, a study result, or a governing conformance claim.

Lifecycle view

Who owns persistence?

Fabric owns worker/execution state. Commons owns coordination/knowledge state. Control owns remote-control state. Harness owns routing/policy/model-loop state.

Failure view

Which layer actually failed?

Attribute workspace failures to Control, routing/policy failures to Harness, target/transport/execution failures to Fabric, and storage/coordination failures to Commons.

Read the full operating model ↗

Project family

Follow the responsibility boundary, then go deep in the owning project.

Public project repositories are linked directly. Operator components are documented separately so reusable operator infrastructure is not mistaken for a normative MNCS or MNCDS requirement.

Standard

MNCS

Normative implementation-evidence standard: technical acceptance, evidence/status semantics, schemas, RFCs, and claim boundaries.

machine-native-complexity-standard ↗ Specification

MNCDS

Independently versioned development-process specification for candidate lifecycle, evidence flow, selection, release, and related development controls.

machine-native-complexity-development-specification ↗ Language

MNCS Language

Verification-native language and semantic representation research, including contracts, effects, evidence, HIR, and SSA.

mncs-language ↗ Development control

Forge

Non-normative bounded development/evidence workflows, provider orchestration, lineage, evidence gaps, and evaluator-mode boundaries.

mncs-forge-mcp ↗ Execution substrate

Fabric

Persistent fleet ownership, exact-target execution, authenticated transport, capability/resource observations, retries, recovery, and execution evidence.

mncs-fabric ↗ Coordination

Commons

Persistent, provenance-aware knowledge exchange and durable work coordination for observations, claims, requests, replications, advisories, and decisions.

MNCS-Commons ↗ Adaptive intelligence

RAVEL

Evidence strategy, scoped memory, causal interpretation, and reusable learning beneath MNCS/MNCDS authority.

RAVEL ↗ Experimental learning

MNEL

Investigators, bounded interventions, causal attribution, negative memory, and verified-experience distillation.

Machine-Native-Experimental-Learning ↗ Research

Reference Studies

Controlled empirical comparisons, case studies, reimplementations, reproducibility, and first-class negative results.

mncs-reference-studies ↗ Validation

Rust Validator

Independent offline validation for supported MNCS subsets without wrapping the Python implementation or executing evidence.

mncs-validator-rs ↗

Reference operator stack

Reusable operator infrastructure, not normative project requirements.

Operating model ↗
Protected control surface

MNCS Control MCP

Authorized remote workspace, Git/process/project tools, sandboxing, and bounded adapters to Harness, Fabric, Forge, and Commons.

deployment-specific · implementation may be private
Model & tool policy

MNCS Harness

Reusable operator infrastructure for workspace meaning, model/tool routing, guarded tool loops, approvals, verification/escalation, and deployment-level result acceptance. Not a normative MNCS requirement.

mncs-harness ↗

Status & maturity

Everything here is experimental. Treat claims as scoped, not universal.

Atlas does not publish a readiness scoreboard. These labels orient; each owning repository remains authoritative for current implementation reality.

Experimental

MNCS

Open implementation-evidence standard. Non-accredited. Technical acceptance and status semantics live here.

Experimental

MNCDS

Independently versioned development-process specification. Non-accredited. Candidate lifecycle and evidence-flow semantics live here.

Research

MNCS Language

Verification-native language and semantic representation research. Not required for MNCS conformance.

Active infrastructure

Forge

Declared development/evidence control and lineage. Non-normative.

Active infrastructure

Fabric

Persistent worker/execution substrate. Execution records are not MNCS status.

Active infrastructure

Commons

Persistent coordination and knowledge exchange. Publication is not acceptance.

Active deployment

Operator stack

Control + MNCS Harness are reference operator-stack implementations with deployment authority only. Not required for MNCS conformance.

Research

RAVEL & MNEL

Adaptive strategy and experimental learning beneath governing authority.

Research

Reference Studies

Controlled empirical challenge; protocols and claims stay study-local.

Active infrastructure

Rust Validator

Independent offline validation for supported subsets.

Orientation

Atlas

Family map, operator orientation, and machine-readable discovery only.

Maturity labels are descriptive, not ranked. Atlas machine metadata records its own review date so agents can detect that orientation data may need re-checking.

Shared language

A small vocabulary prevents large architectural misunderstandings.

Family terminology is intentionally conservative. The full index lives in docs/TERMINOLOGY.md.

Open the terminology index ↗
Authority
The bounded right to make a particular decision or claim. Capability is not authority.
Evidence
Identified observations or records supporting a bounded claim, with provenance, scope, and freshness.
UNKNOWN
An intentional result for missing, stale, unsupported, unavailable, or insufficient evidence—not an inconvenience to hide.
Lifecycle owner
The component authoritative for a persistent identity/history/recovery domain. Consumers do not inherit that ownership.
Acceptance
A scoped decision by the layer authorized to decide whether a result is sufficient for its workflow. Deployment acceptance is not automatically MNCS conformance.
Worker
An identified execution participant. Availability does not imply independence, trust, or suitability for every claim.

For new contributors & agents

Start with the map. Then read the owning project.

The fastest safe path into MNCS is not to read every repository. It is to identify authority, lifecycle ownership, and the public boundary first.

  1. 1
    Orient

    Read Atlas architecture and terminology so family names mean the same thing.

  2. 2
    Locate ownership

    Find the project or operator component that owns the requested behavior and any persistent state it touches.

  3. 3
    Read locally

    Use that owner's README, specs, architecture docs, tests, and public interfaces as implementation authority.

  4. 4
    Preserve boundaries

    Do not turn transport into trust, execution into conformance, publication into acceptance, persistence into shared ownership, or learning into authority.

  5. 5
    Contribute evidence

    Prefer narrow changes, explicit uncertainty, reproducible results, and versioned public contracts.

Human contributors

Prefer clarity over completeness

Update Atlas when the family map drifts. Keep implementation detail in the owning repository and mark deployment-specific details as such.

Read CONTRIBUTING.md ↗

Coding & research agents

Establish authority before editing

AGENTS.md now includes authority, lifecycle, operator-stack, and cross-project integration checks before an agent changes a boundary.

Read AGENTS.md ↗

Cross-project changes

Define the boundary first

State who owns the semantic decision, persistence, execution, storage, and governing claim. Prefer versioned public records over shared internals.

Read ARCHITECTURE.md ↗

Machine orientation

Building an agent or tool that needs to navigate MNCS?

Start from atlas.json for stable IDs and relationships, then follow the owning project's current documentation before acting.

Open atlas.json Open schema