WP6 E1 Ratifier — Frontmatter Compliance Verdict

WP6 E1 Ratifier — Frontmatter Compliance Verdict

Sub-agent: WP6 E1 Ratifier (S236). Inputs verified: docs/ontology/01-…29-*.md (29 files), docs/ontology/README.md, docs/specs/wp6-ontology-harness/TECH.md §5/§6/§7. Branch: content-items-investigation @ 39b9c5f8 (C2). Method: Programmatic Zod-equivalent schema verification (Python script under /tmp/claude/wp6-verifier/verify.py) plus per-CV manual cross-check against §6.3 canonical shape, README index table, and Liam direct rulings.

---

1. Verdict

PASS-WITH-NOTES.

All 29 frontmatters validate against the revised TECH.md §6 Zod schema (cv_name regex, layer enum, provenance_model enum, client_extensible bool, editable_via enum, core_seed_path string|null, status enum, baseline_values .min(1) with strict per-row schema, related_layers ⊆ {1..6}). Strict-mode (.strict()) extra-key rejection is satisfied across all files. The README index table is consistent with all 29 frontmatters on status / provenance_model / editable_via. Liam direct rulings on CV 03 / 13 / 15 / 28 are correctly applied.

The four C2-flagged known-unresolved items remain in the file bodies as deferred items per the handoff plan; none constitute schema-level failures.

Recommendation: Ready for handoff. No fix wave required prior to merge. The known-unresolved items belong to Wave D (Implementer) or post-merge rulings and are documented under §5.

---

2. Summary table (29 rows)

#	File	Schema-validates	§6.3-fidelity	Liam-rulings-applied	Notes
01	01-taxonomy-domains.md	Y	Y	NA	hybrid · 7 baseline rows · all core provenance — matches §6.3 application_types pattern (baseline shipped, client extensions added via admin UI runtime)
02	02-taxonomy-subtopics.md	Y	Y	NA	hybrid · 33 baseline rows · prose body says “31 baseline-provenance” — known C2 drift, see §5
03	03-layer-vocabulary.md	Y	Y	Y	hybrid · 4 keys · all core · editable_via: admin_ui · provenance_model: hybrid — Liam C1 ruling carried through verbatim
04	04-content-type.md	Y	Y	NA	core · 15 keys (matches DB CHECK; live snapshot has 15)
05	05-platform.md	Y	Y	NA	core · 6 keys
06	06-lifecycle-type.md	Y	Y	NA	core · 4 keys (Liam ruling ADD CHECK recorded in body)
07	07-dedup-status.md	Y	Y	NA	core · 5 keys
08	08-freshness.md	Y	Y	NA	core · 4 keys
09	09-governance-review-status.md	Y	Y	NA	core · 5 keys
10	10-publication-status.md	Y	Y	NA	core · 4 keys
11	11-change-type.md	Y	Y	NA	core · 11 keys
12	12-requirement-type.md	Y	Y	NA	hybrid · 7 keys · all core
13	13-ingest-source.md	Y	Y	Y	core · 11 keys · bid_library correctly absent from baseline_values, documented in body Notes (INV-1 ruling)
14	14-bid-states.md	Y	Y	NA	core · 10 keys · cv_name: BID_STATES UPPER_SNAKE — schema explicitly accepts (TECH.md §6 cv_name regex [A-Za-z][A-Za-z0-9_]*)
15	15-workspaces-type.md	Y	Y	Y	core · 3 keys · bid / intelligence / proposal — kb_section correctly absent (Liam retired-S237+ ruling); proposal correct identifier (not proposal-placeholder)
16	16-extraction-method.md	Y	Y	Y	core · 5 keys · firecrawl retained as provenance: core; Notes block flags retired-S236 status (no deprecated enum value exists, kept as core) — known-unresolved §5
17	17-diff-mode.md	Y	Y	NA	core · 2 keys (kebab key qa accepted by regex)
18	18-entity-aliases.md	Y	Y	NA	client · 2 keys · recommended + client provenances (per WP-ONTO-R1 §6.2: client model permits recommended platform-shipped patterns + client-extension rows)
19	19-engineering-types.md	Y	Y	NA	core · 13 keys · 6 kebab-case keys (bid-metadata, unified-gap, filter-preset, intelligence-refinement) — explicitly accepted by §6 BV key regex
20	20-chunk-kind.md	Y	Y	NA	core (planned) · 3 keys · 2 kebab-case keys (heading-section, qa-block)
21	21-scope-tag.md	Y	Y	NA	client (planned) · 1 key (client-defined) — matches client model “no platform baseline”
22	22-origin-kind.md	Y	Y	NA	core (planned) · 4 keys
23	23-extractor-kind.md	Y	Y	NA	core (planned) · 5 keys
24	24-citation-kind.md	Y	Y	NA	core (planned) · 4 keys
25	25-application-type.md	Y	Y	NA	hybrid (needed) · 6 keys · procurement rename applied per Q-OQR1-16 plan
26	26-form-type.md	Y	Y	NA	hybrid (needed) · 11 keys
27	27-form-format.md	Y	Y	NA	core (needed) · 5 keys
28	28-change-report-category.md	Y	Y	Y	core (planned) · 4 keys · status: planned per Liam ruling; 4 closed values ratified by INV-3 archaeology
29	29-cocoindex-source-kind.md	Y	Y	NA	core (planned) · 7 keys

Tally: 29 / 29 PASS schema validation. 0 FAIL. 0 require pre-merge fix.

---

3. Per-failure detail

None. No schema-level failures detected across the 29 files.

---

4. Cross-check observations

4.1 README index consistency

The README §“File index” table (docs/ontology/README.md lines 92-122) lists all 29 files and is fully consistent with the per-file frontmatter:

• All 29 cv_names match the cv_name: field of the corresponding file (including BID_STATES UPPER_SNAKE for CV 14).
• All 29 status values match (active × 19, planned × 7, needed × 3).
• All 29 provenance_model values match (core × 21, hybrid × 6, client × 2).
• All 29 editable_via values match (database_migration × 21, admin_ui × 8).

The README rollup tables (§“Provenance rollup”, §“Editable-via rollup”, lines 162-176) report counts that match the actual file frontmatters: core 21, hybrid 6, client 2; database_migration 21, admin_ui 8, seed_data 0.

4.2 Body-vs-frontmatter mismatches

CV 02 (taxonomy-subtopics) — frontmatter baseline_values has 33 entries; prose body line 124 says “31 baseline-provenance subtopics observed live” and Notes line 150 says “31 are baseline-provenance and ship as the platform default”. This is the known C2-flagged drift (see §5). Frontmatter validates; body prose lags. Not a schema failure; a content-quality item for a follow-up wave (or for D1 to reconcile when the snapshot DB is refreshed).

No other body-vs-frontmatter mismatches found across the 29 files.

4.3 Liam direct ruling verification

CV	Ruling	Verified
03	4 keys with provenance: core, editable_via: admin_ui, provenance_model: hybrid	Y — exact match
13	bid_library NOT in baseline_values	Y — absent; documented in body Notes as inference-function-internal parameter
15	kb_section NOT in baseline_values; proposal (not proposal-placeholder)	Y — kb_section absent (retired-S237+); proposal is correct identifier
28	status: planned; baseline_values has 4 closed values	Y — exact match

4.4 Schema acceptance of edge cases

All schema-edge cases the TECH.md §6 contract was specifically widened to accept are present in the corpus:

• UPPER_SNAKE cv_name — CV 14 (BID_STATES). Accepts via cv_name regex ^[A-Za-z][A-Za-z0-9_]*$.
• Kebab-case BV keys — CV 19 (6 kebab keys: bid-metadata, unified-gap, filter-preset, intelligence-refinement), CV 20 (2 kebab keys: heading-section, qa-block), CV 18 / 21 (client-defined), CV 01 / 02 (kebab category names like product-feature, data-protection). Accepts via BV key regex ^([a-z][a-z0-9_-]*|TBD)$.
• TBD placeholder sentinel — None observed in the C2 corpus. The schema retains the TBD arm of the regex for forward-compatibility per TECH.md §6 line 217.
• null core_seed_path — 21 core files (CVs 04, 05, 06, 07, 08, 09, 10, 11, 13, 14, 15, 16, 17, 19, 20, 22, 23, 24, 27, 28, 29) carry core_seed_path: null per the spec rule “null if no seed file (closed CORE enums)”. Schema rejects missing key (load-bearing distinction per TECH.md §6 line 272).
• status required field — every file declares status: per the README lifecycle classification. Schema would reject any file omitting it (.strict()).

4.5 Provenance per BV row (per WP-ONTO-R1 §6.2 / §6.3)

For hybrid CVs, the §6.3 example shows all baseline rows as provenance: core (the platform’s baseline; client/recommended rows would be added at runtime via admin UI). All 4 hybrid baseline files (01, 12, 25, 26) follow this pattern: 100% core rows. CV 02 also all-core (33 rows).

For client CVs, CV 18 ships one recommended (generic acronym mapping pattern) + one client (tenant-specific) row — accurate per the §6.2 description that the client model permits “platform-recommended patterns” plus client-extension rows. CV 21 ships one client row — accurate per “empty by default; clients add via admin UI”.

For core CVs, all 21 files ship 100% core-provenance baseline rows. Correct.

---

5. Confirmation of carried-forward items

The handoff prompt should mention the following as outstanding (per the user prompt’s “known-unresolved” list, plus any other items the E1 ratifier observed as deferred to a later wave):

5.1 C2-flagged known-unresolved (4)

1. CV 02 prose-vs-frontmatter count drift — frontmatter has 33 baseline values; prose says “31 baseline-provenance subtopics”. Body content lag, not a schema failure. The ratifier confirms the drift is present in the file but is not flagged via an explicit Notes block bullet (bullet 4 says “31 are baseline-provenance” without explicitly noting the 33-vs-31 reconciliation gap). Recommend a future Editor wave reconcile or add a one-line Notes bullet flagging the reconciliation pending the seed-file landing.
2. CV 16 firecrawl provenance — Liam ruling retires firecrawl (S236) but no deprecated enum value exists in the schema’s PROVENANCE_VALUES. Currently kept as provenance: core; Notes block flags the retirement. Acceptable per the user’s brief; future schema extension could add a deprecated provenance value if a wider lifecycle vocabulary is wanted.
3. CV 16 Python extractor divergence — trafilatura / pdfplumber write paths exist in the Python pipeline that may emit values not in the CV 16 baseline_values. Documented in C1’s body. Not a schema-level failure; needs reconciliation when the Python pipeline taxonomy snapshot is regenerated and the parity test sees a CHECK mismatch (TECH.md §5.4 case 2 will flag).
4. CV 02 prose seed-file derivability — body refers to scripts/seed/baseline-taxonomy-subtopics.sql as the canonical enumeration “once the seed file lands”. The seed file does not yet exist. Same status for 01, 03, 12, 18, 25, 26 — all hybrid/client files reference seed paths that the migration wave (Q-OQR1-16) is expected to materialise.

5.2 Liam-pending items (in body Notes)

The C1 commit message explicitly listed several Liam decisions still pending. These appear in body Notes blocks and are NOT schema failures but should be tracked in the handoff:

• CV 04 content-type — policy / compliance semantic boundary, methodology / capability semantic boundary (INV-2 deferred to Liam); capability (0 prod rows) flagged as retire candidate.
• CV 19 engineering-types — Liam keep-or-drop decision pending on whether this CV stays as a general engineering register or splits.
• CV 25 application-type — depends on application_types table migration in Q-OQR1-16 combined PR; status remains needed until the table lands.
• CV 26 form-type — depends on form_types table migration; status needed.
• CV 27 form-format — depends on form_templates column landing; status needed.

5.3 Wave D dependencies

Wave D (Implementer) needs:

• lib/ontology/schemas.ts (Zod schema per TECH.md §6 verbatim).
• lib/ontology/loader.ts with gray-matter dep (bun add gray-matter).
• lib/ontology/content-type-registry.ts.
• __tests__/lib/ontology/markdown-parity.test.ts.
• lib/validation/schemas.ts lines 41-57 swap to re-export from registry.
• The 2 z.enum(VALID_CONTENT_TYPES) call sites at lib/validation/schemas.ts:264 and lib/validation/ingest-schemas.ts:11 need explicit as readonly [string, ...string[]] cast (per TECH.md §5.3).
• scripts/ontology-sync/parse-flow.py cocoindex stub.

5.4 E2 (out of scope for this E1 wave)

The user prompt mentions “Wave D + E2 + Liam-pending items” as outstanding. E2 is the ratifier’s verification of the implementer’s code (Wave D’s output); not relevant until Wave D ships.

---

6. Recommendation

Ready for handoff. No fix wave required prior to merging C1+C2 to main.

Justification:

• 29 / 29 frontmatters validate against the revised TECH.md §6 Zod schema (programmatic verification + manual §6.3 fidelity cross-check both pass).
• 4 Liam direct rulings (CV 03, 13, 15, 28) correctly applied verbatim.
• README index table fully consistent with all 29 frontmatters.
• The 4 known-unresolved items C2 flagged are content-quality / future-wave items, not schema failures; they belong to Wave D (Implementer) reconciliation or post-merge content edits.

Proposed handoff actions:

1. Merge content-items-investigation (C1 + C2 + this E1 report) to main without further ontology MD edits this session.
2. Open Wave D (Implementer) ticket for lib/ontology/* + __tests__/lib/ontology/markdown-parity.test.ts + gray-matter dep + VALID_CONTENT_TYPES swap + parse-flow.py stub.
3. Add a single-line note to the next continuation prompt covering the 4 C2-flagged items (so Wave D Implementer is aware they are out-of-scope content drift and not test failures to chase).

No fix agent dispatch required.

---

End of E1 ratifier report. Verifier: WP6 E1 sub-agent (S236). Method: Python YAML verifier under /tmp/claude/wp6-verifier/verify.py (deleted with worktree) + manual §6.3 fidelity / Liam-ruling / README cross-check. UK English.