Executable Doctrine Grammar

Component turns doctrine

This component turns doctrine shape into something a program can pass or fail, checking each standard and paper-module fixture for a stated purpose, governing rule, result records, and honest scope statement. Executable doctrine grammar is a component that turns doctrine shape into something a program can pass or fail. It reads a folder of example standards and paper-module write-ups and checks each one for the parts doctrine here requires: a stated purpose, a governing rule, the result records it should produce, and an honest statement of what it does not claim. It writes a per-file report saying which entries are well formed and which fail a required check.

Report is set

The report is a set of metadata-only result records carrying references, hashes, counts, and verdicts, and a pass means the fixtures carry the required structure and every expected failure was observed. The report is a set of metadata-only result records. They carry references, hashes, counts, and verdicts. They never inline the document bodies being checked. A pass means the fixtures carry the required structure and that the checker observed every failure it is supposed to catch.

Checks are structural

The checks are structural, not semantic: they judge whether load-bearing fields are present, so a row cannot quietly drop its result-record expectations or scope statement and still pass. They judge whether the load-bearing fields are present, so a row cannot quietly drop its result-record expectations or its scope statement and still pass.

Purpose

Doctrine as prose convention

In most systems doctrine is prose convention that nothing checks, so a loose fixture reads the part then drops a required field with no signal; this component asks per row whether the structure is real. Doctrine in most systems is prose convention. A standard says a rule should hold, a paper module says a section should be present, and nothing checks whether the claim is true. A loose fixture passes review because it reads the part, then drops a required field later with no signal. This component removes that gap. It answers one question per row: does this standard or paper-module fixture carry the structure doctrine here requires, or is it text that looks the part?

Failure is first class

The less obvious half is that failure is first class: five negative cases are part of the contract, so a run that never demonstrates a rejection is treated as blocked. The less obvious half is that failure is first class. Five negative cases are part of the contract. A run that accepts every input but never demonstrates a rejection is treated as blocked, so the checker has to prove it can reject, not only that it can accept.

How it works

validate reads and merges two checks

validate reads standards_registry.json and every paper_modules/*.md file, scans them for forbidden content classes, then runs two structural checks and merges their results. The entry point is validate. It reads standards_registry.json and every paper_modules/*.md file from the input directory, scans them for forbidden content classes, then runs two structural checks and merges their results.

Standard-registry field and overclaim checks

validate_standard_registry records missing-field, duplicate-slug, prose-authority, and doctrine-completeness overclaim findings per row, and accepts a row only when it has no findings and no expected-failure marker. validate_standard_registry walks each standard row. It records MISSING_TELEOLOGY, MISSING_RECEIPT_EXPECTATIONS, MISSING_GOVERNING_STANDARD, and MISSING_ANTI_CLAIM when those fields are absent. It records DUPLICATE_STANDARD_SLUG_CONFLICT when two rows share a slug. It records PROSE_STANDARD_NOT_EXECUTABLE_AUTHORITY when a row marked standard_kind: prose also claims executable authority, and GRAMMAR_PASS_OVERCLAIMS_DOCTRINE_COMPLETE when a row claims doctrine completeness. A row with no findings and no expected-failure marker is accepted.

Paper-module heading and sentinel checks

validate_paper_modules checks each fixture module for the Teleology, Governing Standard, Receipt Expectations, and Scope boundary headings and rejects any that carries the copied-body sentinel or a completeness marker. validate_paper_modules calls validate_paper_module_shape on each fixture module. That function checks for the Teleology, Governing Standard, Receipt Expectations, and Scope boundary headings, and rejects any fixture that contains the copied-body sentinel text or a doctrine-completeness marker.

Merging findings and required negatives

validate passes only when no required negative case is missing and the content scan is clean, writing four result records under result records/sign-off/first_wave/. validate then computes which of the five required negative cases were observed and which are missing. The run status is a pass only when no required case is missing and the content scan is clean. It writes four result records: the standards report, the standards group index, the paper-module report, and the fixture result record under result records/sign-off/first_wave/.

Two bundle entry points reuse the checks

validate_standards_bundle and validate_executable_grammar_metabolism_bundle reuse the same checks over the exported public standards bundle and the exported specimen, each passing only on a clean scan with valid rows. Two more entry points reuse the same checks over exported bundles. validate_standards_bundle validates the exported public standards bundle and passes only when the scan is clean, there are no findings, and at least one standard row and one paper module are valid. validate_executable_grammar_metabolism_bundle validates the exported specimen: it reads bundle_manifest.json, README.md, grammar_board.json, and receipt.json, runs _metabolism_bundle_findings over their required keys and boundary phrases, then calls the copied-body gate.

The copied-body digest gate

validate_source_module_imports requires each of the 12 declared bodies to be a copied, allowlisted, non-result record source body whose SHA-256 recomputes to match the manifest, treating any mismatch as a finding. validate_source_module_imports is that gate. It reads source_module_manifest.json and requires source_import_class to be copied_non_secret_macro_body, body_in_receipt to be false, and the declared module_count to equal the number of rows. For each of the 12 declared bodies it checks the material class against public_macro_standard_body, public_macro_tool_body, and public_macro_receipt_body, requires body_copied true and body_in_receipt false, requires the source reference to sit on the allowlist, confirms the copied target file exists, and recomputes its SHA-256 digest with _sha256_file to match the manifest. A mismatch is a finding, not a silent pass.

result_card projects a metadata-only card

result_card projects any result into a compact card of status, counts, and verdicts, dropping the full finding lists and any body-bearing fields named in CARD_OMITTED_FULL_PAYLOAD_KEYS. result_card projects any of these results into a compact card for a reader or the Atlas. It keeps status, counts, and verdicts and drops the full finding lists and any body-bearing fields named in CARD_OMITTED_FULL_PAYLOAD_KEYS.

To run the fixture check from microcosm-substrate/:

PYTHONPATH=src python3 -m microcosm_core.organs.executable_doctrine_grammar validate --input fixtures/first_wave/executable_doctrine_grammar/input --out receipts/first_wave/executable_doctrine_grammar --card

flowchart TD A["Public fixtures standards_registry.json + paper_modules/*.md"] --> B["validate"] B --> C["validate_standard_registry field, slug, authority checks"] B --> D["validate_paper_module_shape heading and sentinel checks"] C --> E["Merge findings observed vs required negative cases"] D --> E E --> F["metadata-only result records result records/first_wave/executable_doctrine_grammar/"]

Negative cases

Fixture keeps five

The fixture keeps five failures executable rather than described in prose. The fixture keeps five failures executable rather than described in prose. Each maps to an error code the checker must observe:

• invalid_standard_and_module: a row missing teleology, result-record expectations, governing standard, and scope statement, raising MISSING_TELEOLOGY, MISSING_RECEIPT_EXPECTATIONS, MISSING_GOVERNING_STANDARD, and MISSING_ANTI_CLAIM.
• prose_standard_claims_runtime_authority: a prose-only standard that claims executable authority, raising PROSE_STANDARD_NOT_EXECUTABLE_AUTHORITY.
• macro_doctrine_body_copied_into_fixture: a copied private body pasted into a public fixture, raising MACRO_DOCTRINE_BODY_IN_PUBLIC_FIXTURE.
• duplicate_standard_slug_conflict: two rows sharing a slug, raising DUPLICATE_STANDARD_SLUG_CONFLICT.
• grammar_index_pass_overclaims_doctrine_complete: a passing fixture that claims doctrine completeness, raising GRAMMAR_PASS_OVERCLAIMS_DOCTRINE_COMPLETE.

Required cases enforce provable rejection

The required cases live in EXPECTED_NEGATIVE_CASES, and if a run does not observe every one validate returns a blocked status. The set of required cases lives in EXPECTED_NEGATIVE_CASES. If a run does not observe every one, validate returns a blocked status.

Prior Art Grounding

Schema validation and executable semantics

The design follows schema validation, generated grammars, and executable-semantics work like JSON Schema, Tree-sitter, and the K framework, checking doctrine shape by program instead of leaving it as convention. The design follows schema validation, generated grammars, and executable-semantics work. JSON Schema is the reference for validating document shape against a shared machine contract. Tree-sitter shows the value of generated grammars for inspectable structure. The K framework is a close reference for turning semantic rules into executable artifacts. The borrowed pattern is narrow: doctrine shape, result-record expectations, duplicate slugs, copied bodies, and scope statements are checked by a program instead of left as convention.

Validation Result record Path

./repo-pytest tests/test_executable_doctrine_grammar.py -q --basetemp=/tmp/microcosm_executable_doctrine_grammar_pytest
./repo-python scripts/build_doctrine_projection.py --check-paper-module-corpus

What a pass means here

A green run here means only that the focused tests and the corpus parity check both accept these fixtures and this projection. A pass means the focused test suite and the corpus check both accept the current fixtures and this projection.