Source Projection Import Protocol

The checkpoint for copying source material

macro_projection_import_protocol is the checkpoint for copying material out of a much larger source project into the public Microcosm folder. macro_projection_import_protocol is the checkpoint for copying material out of a much larger source project into the public Microcosm folder. It reads a proposed set of copied files, classifies each one, and decides whether the copy is allowed out and honestly tied to the source it claims to come from.

It exists so the public folder can stay dense and real without becoming a place where a secret, an operator conversation, a model-output data, or launch material leaks out alongside genuinely useful code. It exists so the public folder can stay dense and real without becoming a place where a secret, an operator conversation, a model-output data, or launch material leaks out alongside genuinely useful code. Every run answers one question per copied file: was this body allowed out, and does the public copy match the source it names.

The output is a metadata-only result record. It lists what was imported, what was deliberately left out with a note saying so, and what was refused. The output is a metadata-only result record. It lists what was imported, what was deliberately left out with a note saying so, and what was refused. The record carries paths, hashes, counts, and validation refs, never the private bodies themselves.

Purpose

Microcosm grows by copying real files out of a private codebase. A loose copy is the exact artifact that quietly carries a account secret or an operator thread along with the code you wanted. Microcosm grows by copying real files out of a private codebase. A loose copy is the exact artifact that quietly carries a account secret or an operator thread along with the code you wanted. A trust statement ("we checked, it is fine") does not scale and cannot be re-run by a reader.

So the check is an accounting check, not a trust statement. Each copied row declares its source ref, its public target ref, a content digest, and a material class. So the check is an accounting check, not a trust statement. Each copied row declares its source ref, its public target ref, a content digest, and a material class. The protocol sorts the class into one of two sets. PUBLIC_SAFE_BODY_MATERIAL_CLASSES holds five classes that may be copied with provenance: pattern, standard, tool, result-record, and proof bodies. TRUE_FORBIDDEN_MATERIAL_CLASSES holds fifteen classes that can never appear as an imported body, including raw operator source, operator thread, model-output data, account secret, secret, recipient material, launch material, and the six private formal-math body classes. Anything claiming to be must also carry a verification record naming the digest, the source-to-target relation, and the mode used to check the copy.

How it works

main dispatches four commands. run validates a first-wave fixture directory (the positive slices plus the named negative cases) and writes result records through write_receipts. main dispatches four commands. run validates a first-wave fixture directory (the positive slices plus the named negative cases) and writes result records through write_receipts. run_projection_bundle validates an exported bundle and writes one exported_projection_import_bundle_validation_result.json. plan calls preview_import_plan, which scores each proposed cell and writes nothing. refresh-exact-copy-source-modules calls refresh_exact_copy_source_modules to re-copy exact-copy slices whose source has moved on. run and run_projection_bundle both assemble their answer through _build_result, which runs four validators over the fixture: validate_projection_protocol for the copied and omitted rows, validate_cleaning_policy for the cleaned rows, validate_standalone_runtime_severance for standalone-runtime dependency leaks, and validate_import_plan for the forward plan.

The core is validate_projection_protocol. It reads the protocol payload and runs these checks in order: The core is validate_projection_protocol. It reads the protocol payload and runs these checks in order:

First it enforces a density floor: the protocol must cite at least two source refs, two public runtime refs, and two validation refs, or the row fails as MACRO_PROJECTION_PROTOCOL_DENSITY_MISSING. First it enforces a density floor: the protocol must cite at least two source refs, two public runtime refs, and two validation refs, or the row fails as MACRO_PROJECTION_PROTOCOL_DENSITY_MISSING. Then it walks each copied row. A row whose class is goes to _public_safe_import_status; anything it flags becomes a blocking finding. A row whose class is in TRUE_FORBIDDEN_MATERIAL_CLASSES, or any row that sets body_copied without a valid verification record, is rejected as MACRO_PROJECTION_FORBIDDEN_BODY_IMPORT. Omitted rows must carry an omission_receipt_ref. The result is PASS only when the floors are met, copied, omitted, cleaned, and step rows are all present, and no blocking finding remains.

Digest requirements for a copied body

For a body that is copied, _body_import_verification_findings does the real integrity work. For a body that is copied, _body_import_verification_findings does the real integrity work. The verification record must be marked verified and must use one of two modes in BODY_IMPORT_VERIFICATION_MODES: exact_source_digest_match or verified_light_edit_recipe. The target body digest must equal the declared target digest. For an exact copy it also re-hashes the named source, requires a relation from EXACT_COPY_SOURCE_TO_TARGET_RELATIONS, and checks the source digest.

The load-bearing detail is how the protocol treats an exact copy whose source has since changed. A mismatch on an exact-copy row is not a failed import. The load-bearing detail is how the protocol treats an exact copy whose source has since changed. A mismatch on an exact-copy row is not a failed import. It is recorded as live source drift: the original copy was still honest, the source has simply moved on, and the row is flagged for the refresh path rather than failed. That separates a dishonest import from a stale one, so a routine upstream edit is not mistaken for a broken proof, and the public copy stays faithful without tracking every upstream change in lock-step.

validate_import_plan guards the forward direction. Each proposed cell must name source and target refs, must name validation refs, must not use a private-system- shaped ref, and must only reference body material that the protocol already carries. validate_import_plan guards the forward direction. Each proposed cell must name source and target refs, must name validation refs, must not use a private-system- shaped ref, and must only reference body material that the protocol already carries. A plan needs at least three cells to pass. preview_import_plan wraps this as the macro_projection_import_intake_preview_v1 record: it scores each cell, projects the intake and severance boards, and lists blocking surfaces without writing anything.

flowchart TD A["Copied row source ref, target ref, digest, material class"] --> B["validate_projection_protocol"] B --> C["Class in forbidden set Reject: forbidden body import"] B --> D["Class _public_safe_import_status"] D --> E["_body_import_verification_findings mode, verified flag, digest binding"] E --> F["Exact copy: re-hash live source"] F --> G["Match: body floor"] F --> H["Mismatch: flag live source drift, refresh later"] H --> G G --> I["metadata-only result record"]

Negative cases

The first-wave fixture drives these named rejections through validate_projection_protocol, validate_import_plan, and validate_standalone_runtime_severance: The first-wave fixture drives these named rejections through validate_projection_protocol, validate_import_plan, and validate_standalone_runtime_severance:

• forbidden_body_import_overclaim: a request to import a account secret or account-bound body.
• missing_omission_receipt: omitted material with no omission result record ref.
• authority_upgrade_overclaim: a claim that a public import grants live private-source authority.
• release_or_private_equivalence_overclaim: a launch, public sharing, recipient, or private-equivalence claim.
• formal_math_claim_boundary_overclaim: a formal-math theorem, proof, private target status, solver-trace, or provider-oracle authority claim.
• missing_validation_ref: a proposed cell with no validation refs.
• standalone_dependency_leak: a runtime dependency on the live source root that a standalone public checkout cannot resolve.

Prior Art Grounding

The check follows established provenance and software-supply-chain patterns: a copied or refactored artifact needs source refs, target refs, digests, validation refs, omission records, and a stated claim boundary. The check follows established provenance and software-supply-chain patterns: a copied or refactored artifact needs source refs, target refs, digests, validation refs, omission records, and a stated claim boundary. The closest public anchors are W3C PROV for entity, activity, and agent provenance, the SLSA specification for artifact integrity and provenance in software supply chains, and in-toto for linking supply-chain steps through signed metadata. This component applies those patterns to a public and private projection boundary rather than to launch attestation, and it stays a local validator over public fixtures and exported bundles.

Validation Result record Path

From microcosm-substrate/, reproduce this page's checks with temporary result records:

What the fixture and bundle validate

A pass means the fixture and bundle slices carried their required refs and digests, the named negative cases were rejected, and the result records stayed metadata-only. A pass means the fixture and bundle slices carried their required refs and digests, the named negative cases were rejected, and the result records stayed metadata-only. Re-enter this module when a new projection cell lands, a source-module manifest is refreshed, or a result record count changes.