Cognitive Operator Registry

Registry checks public

The registry checks a public catalogue of named thinking moves and asks which operators have actually changed a live decision, not just described one tidily. cognitive_operator_registry is a checker for the system's catalogue of named thinking moves. Each entry describes one reusable operator, for example "reduce competing pressure to one bounded action" or "compile a handoff packet when validated work cannot be committed". The component reads the public catalogue and answers one question: which of these operators has actually changed a live decision, and which is only a tidy description of one.

Validates every operator

It validates every operator row against a fixed shape, makes each active operator cite a dogfood record with concrete evidence, and rejects voice or authority overclaims. It runs over a public fixture. It reads three input files, validates every operator row against a fixed shape, requires each operator marked active to point at a dogfood result record carrying concrete evidence, and rejects any row that claims the owner's voice or that grants itself launch, provider, or mutation authority. It writes result records that name refs, hashes, counts, and verdicts, never the operator text itself.

Purpose

active requires resolved cognition-delta evidence

An entry may call itself active only when it cites a dogfood record whose cognition_delta_evidence names a decision that changed, with evidence surfaces resolved against the public system. A team that writes its reusable thinking moves down as a registry tends to accumulate entries faster than it can prove any of them helped. A loose registry passes on prose alone: an entry says it was useful, and the reader has to take its word. This component refuses that. An entry may call itself active only if it points to a dogfood record, and that record must carry cognition_delta_evidence describing a concrete decision that came out differently because the operator was applied. Where the record cites evidence surfaces or command paths, the checker resolves each one against the public system rather than trusting the prose.

How it works

Two entrypoints over _build_result

Two entrypoints, run over the first-wave fixture and run_registry_bundle over the exported bundle, both call _build_result to run the ordered pipeline. The runtime lives in src/microcosm_core/organs/cognitive_operator_registry.py. There are two entrypoints. run validates the first-wave fixture and includes the negative cases; run_registry_bundle validates the exported bundle and makes the copied source-body manifest mandatory. Both call _build_result, which runs the pipeline in this order.

The five-step pipeline and pass rule

The pipeline loads inputs, checks copied bodies, runs the secret scan, validates operator rows, and exercises negatives; status is pass only when all four conditions hold. First, _load_payloads reads the three public inputs: operator_registry.json, operator_standard.json, and dogfood_index.json (plus the eight negative inputs in fixture mode). Second, _source_module_manifest_result checks the copied source bodies carried by the exported bundle. Third, scan_paths runs the secret-exclusion pass over every input. Fourth, _positive_findings validates the operator rows. Fifth, _negative_findings exercises the declared rejection cases. The status is pass only when there are no positive findings, no expected negative case went unobserved, no blocking secret hit was found, and the source-module check is pass or not_present.

_positive_findings carries the core contract

_positive_findings checks each row's shape and status, resolves every active operator's dogfood result record and evidence commands, and flags any policy that sets an OVERCLAIM_KEYS flag true. _positive_findings carries the core contract. For each operator row it requires all eleven fields in OPERATOR_REQUIRED_FIELDS and a status drawn from candidate, active, or retired. For each active operator it looks up a dogfood row keyed by operator_id, requires the nine fields in DOGFOOD_REQUIRED_RECEIPT_FIELDS, and calls _dogfood_receipt_ref_resolves to confirm the result record ref points at a real dogfood row. It then calls _record_dogfood_evidence_resolution_findings, which parses each evidence surface as a command and resolves its path and handle tokens against the public system. A row whose prose says it was dogfooded but whose evidence does not resolve is recorded as a failure. Finally it checks the registry policy against OVERCLAIM_KEYS: if the policy sets any of release_authorized, provider_calls_authorized, source_mutation_authorized, or the other listed flags to true, that is an overclaim.

The bundle body-floor manifest check

_source_module_manifest_result proves the bundle's copied bodies by class, module_count, sha256 across three digest fields, and declared anchors, recording ids and hashes but never the body text. _source_module_manifest_result is the body-floor check used by the bundle entrypoint. The exported bundle at examples/cognitive_operator_registry/exported_cognitive_operator_registry_bundle copies the source registry, standard, and projection-tool bodies. The manifest must classify each as copied_non_secret_macro_body, keep body_in_receipt false, match its declared module_count, and for every row: use a material class, copy the body into source_modules, hash to the recorded sha256 across all three digest fields, and carry the declared anchors in the copied text. The result summary records module ids, classes, line counts, and hashes, never the body text.

flowchart TD Inputs["operator_registry.json operator_standard.json dogfood_index.json"] Positive["_positive_findings shape, status, dogfood, policy overclaim"] Negative["_negative_findings eight rejection cases"] Manifest["_source_module_manifest_result copied bodies by sha256"] Secret["scan_paths secret exclusion"] Result["result record refs, hashes, counts, verdicts; body text omitted"] Inputs --> Positive Inputs --> Negative Inputs --> Manifest Inputs --> Secret Positive --> Result Negative --> Result Manifest --> Result Secret --> Result

Negative cases

Eight perturbed inputs and their error codes

The fixture ships eight perturbed inputs, each of which _negative_findings must observe and map to a specific error code, from missing fields to unresolvable dogfood evidence. The fixture ships eight perturbed inputs, and a pass requires every one to be observed and recorded. _negative_findings reads each and emits the matching error code. Missing operator fields give COGOP_MISSING_REQUIRED_FIELD. An active operator with no backing dogfood row gives COGOP_ACTIVE_WITHOUT_DOGFOOD. A dogfood row with no cognition-delta evidence gives COGOP_DOGFOOD_MISSING_COGNITION_DELTA. Two operators sharing a slug or a near-identical claim with no recorded accretion decision give COGOP_OPERATOR_SPRAWL. A policy that grants itself launch, provider, or mutation authority gives COGOP_AUTHORITY_OVERCLAIM. A row that claims operator-voice authority gives COGOP_OPERATOR_VOICE_FORBIDDEN. A private source body or model-output data in a public input gives COGOP_PRIVATE_SOURCE_FORBIDDEN. A dogfood result record whose evidence surfaces do not resolve gives COGOP_COGNITION_DELTA_EVIDENCE_UNRESOLVABLE.

Prior Art Grounding

Cognitive work analysis, PROV, schema, policy

The design draws on cognitive work analysis, W3C PROV provenance, JSON Schema shape checks, and Open Policy Agent's data/policy separation, applied as a public contract check. This component sits in the lineage of cognitive work analysis, provenance tracking, schema validation, and policy-gated registries. Cognitive Work Analysis, summarized in this information-systems design overview, studies reusable moves in complex sociotechnical work. W3C PROV connects a claim to the activities, agents, and evidence used to judge it. JSON Schema is the required-shape pattern behind the operator-row check. Open Policy Agent is a precedent for keeping policy evaluation distinct from the data being evaluated. This component applies those patterns as a public contract check over already-public inputs.

Validation Result record Path

Run the first-wave fixture into disposable output from the Microcosm root:

Run the exported bundle through the same component:

cd microcosm-substrate
PYTHONPATH=src ../repo-python -m microcosm_core.organs.cognitive_operator_registry run-registry-bundle --input examples/cognitive_operator_registry/exported_cognitive_operator_registry_bundle --out /tmp/microcosm_cognitive_operator_registry_bundle

Then run the focused tests:

cd microcosm-substrate
../repo-pytest tests/test_cognitive_operator_registry.py -q

What a pass means here

A pass means the public operator contract replayed from public inputs with every shape check holding and every rejection observed, but does not certify the operators as correct. A pass means the public operator contract replayed from public inputs: every shape check held, every expected rejection was observed, and no body text reached the result records. It does not certify the operators as generally correct.