Skip to content
Canonical

ID-132 {132.1} PRODUCT — OKF L-concepts layer + 2-pass producer

PRODUCT — OKF L-concepts layer + 2-pass producer (the client-owned concept bundle)

Section titled “PRODUCT — OKF L-concepts layer + 2-pass producer (the client-owned concept bundle)”

Status: DRAFT — 28/06/2026. Behaviour invariants for Task A of the four-Task OKF re-architecture — the L-concepts layer and the two-pass producer that emits the client-owned OKF concept bundle. This Task depends on ID-131 (the L-records foundation, fully ratified) and owns the bundle-publication irreversibility (the first publish pins record uuids into a durable client-owned artefact — the true point-of-no-return).

Spec chain: {132.1} PRODUCT (this doc) → {132.2} TECH → {132.3} PLAN. RESEARCH is served by the ratified okf-record-model-v3.md §1/§7 + ID-131’s {131.1} RESEARCH, so no separate {132.0/.1} research Subtask is authored.

How to read this: every numbered Behaviour invariant (BI-N) is a testable statement the owner ratifies and the Checker verifies. Invariants tagged RATIFY: need the owner’s explicit call at the ratification gate before {132.2} TECH proceeds — they are the genuine product decisions (concept granularity, the concept-type set, the resource: scheme string, git-sync timing). Everything else LOCKS a decision already ratified in okf-record-model-v3.md or inherited from ID-131 (do not re-litigate; if you believe one is wrong, flag it).

De-identification: the real first ingest corpus is referred to throughout as “the first client”. The client’s name is deliberately omitted, here and in every command/path.

Summary

Section titled “Summary”

The OKF concept bundle (L-concepts) is a distilled, client-owned knowledge map: ~30–50 markdown concept files (topics, products, certifications, the company, case studies, and — owner’s call — metrics/datasets/playbooks) plus an index.md (progressive disclosure) and a log.md (change history). Concepts cite L-records via a resource: URI and a # Citations section; they never store record content. A two-pass producer drafts each concept from Canonical L-records (Pass-1) then enriches it from the gated authoritative corpus (Pass-2, host-allowlist + depth-limited), gated on every write by an ontology + frontmatter validator. The bundle lives in a client-owned private git repository; its first publication is the irreversible act, because the canonical://<table>/<uuid> pointers it pins are durable — so ID-131’s frozen seed contract MUST be CI-green before the first publish. RAG posture is reduce-not-remove: the whole bundle fits one context window (~86k tokens for the first client) so it can be loaded wholesale where that helps, with a vector index (ID-131’s record_embeddings, owner_kind='concept') for the long tail.

Problem

Section titled “Problem”

Canonical’s core value is high-quality structured data accessible by AI. L-records (ID-131) gives us typed, citeable records — but records are high-cardinality, churny, and DB-resident: an AI agent drafting a bid response cannot load 65 Q&A masters + N source documents + the entity graph into context and reason over it as a map. The first client already solved this by hand: their Phew-Bid-Library-2026-v4_4.md carries a hand-built “BID RESPONSE TOPIC INDEX” — ~17 themes over ~55 topic entries — i.e. the client performed the concept≠record split themselves. L-concepts operationalises that hand-built map as a generated, versioned, citeable bundle the client owns.

Code-intelligence orientation (verbatim — Checker: confirm this ran). Tools: gitnexus_query (repo canonical, 28/06/2026), grep over lib//scripts//app/, and the ratified ID-131 {131.3} TECH for the contract this Task consumes.

  • No OKF producer exists — net-new confirmed. gitnexus_query({query:"OKF concept bundle markdown producer enrichment agent", repo:"canonical"}) returned no producer process: the top-ranked process was the unrelated Function:app/reference/[id]/page.tsx:ReferenceDetailPage (lines 54–139, priority 0.107); remaining hits were scattered definitions (lib/intelligence/content-extractor.ts, lib/ai/classify.ts:isGenericConcept 299–301, components/ui/concept-help.tsx). No enrich_concept, declare_file, bundle-writer, or Source-protocol symbol exists.
  • No resource: scheme, no producer package. grep -rln "canonical://" --include=*.ts --include=*.py → zero hits. scripts/cocoindex_pipeline/sources/ does not exist (confirms v3 §7.2: the reference_agent sources/base.py pattern is theirs, not ours; our sources are localfs.walk_dir + a hand-rolled url_source.py). The only okf/concept text hit across lib//scripts//app/ is app/item/new/create-content-client.tsx — the legacy generic create form that ID-131 BI-33 removes; it is not a producer.
  • The EMB-STORE the bundle vector index relies on is ID-131-owned, not in the code graph yet. gitnexus_query({query:"embedding store vector index hybrid search record embeddings"}) surfaced only lib/mcp/tools/search.ts:registerSearchTools (76–819) / runItemSearch (89–233) and cocoindex test fakes — no record_embeddings symbol, because it is the net-new ID-131 table. Its contract is therefore grounded against ID-131 {131.3} TECH M1b verbatim: CREATE TABLE record_embeddings with owner_kind text CHECK (owner_kind IN ('source_document','content_chunk','q_a_pair', 'reference_item','concept')), owner_id uuid, model text, embedding vector(1024), UNIQUE (owner_kind, owner_id, model), per-owner_kind partial HNSW indexes (ID-131 TECH:288).
  • Concept identity has no DB row. ID-131 {131.3} TECH:257–259: record_embeddings deliberately uses the (owner_kind, owner_id) + CHECK idiom with no FKs “because its kind set includes concept, which has no DB row (its identity is a bundle path); a per-kind FK is structurally impossible for concept.” Citations to concepts use a path: ID-131 TECH M4b adds citations.cited_concept_path text (TECH:293), and ID-131 BI-8 locks anchors-only.

The first client’s corpus (the empirical concept map). At /Users/liamj/Documents/development/local-fs-client/corpus:

  • markdown/Phew-Bid-Library-2026-v4_4.md — the company-wide master: **123 original Q&As → 44 masters
    • 21 upgraded = 65 masters** (header lines 1–8); a “BID RESPONSE TOPIC INDEX” (line 16) of ~17 ### themes (Company Overview & Credentials; Data Protection & GDPR; Security & Information Governance; Penetration Testing & Vulnerability Management; Business Continuity & DR; Encryption & Data Security; Development & Change Management; Support & Implementation; Insurance & Commercial; CSR & Social Value; Sub-Contractors & Supply Chain; Staffing & People; Secure Disposal & Data Sanitisation; Audit & Monitoring) over ~55 ## topic entries.
  • Three per-product libraries: LMS_Bid_Library_v2.2.md, Advanced_Audits_Bid_Library_v5.md, Website_Bid_Library_v4_2.md → products {Audit, LMS, Websites}.
  • 13 structure files 01-company-overview.md … 13-follow-up-scrape-results-phase-0b.md — 01 (company), 02-services-and-digital-products (products), 04-named-clients-and-case-studies (case studies), 05-team-structure-and-key-people (company/people), 07-compliance-governance-and-certifications (certifications), 08-technology-and-tools, 10-site-structure-and-key-urls (the authoritative web sources for Pass-2).
  • binary-originals/Telehouse-South-Fact-Sheet-2025.pdf — a third-party datasheet (external evidence → an L-records reference_item; a dataset/metric concept may cite it).

This corpus resolves into exactly the L-records ID-131 defines (source_documents, q_a_pairs, reference_items) plus a hand-built concept map — validating the three-layer model empirically.

Figma: none — this is a backend producer + a client-owned file artefact. No Canonical-hosted UI is designed here (a read-only bundle viewer is lift-and-shift per v3 §7.2 and scoped in {132.2} TECH).

Goals / Non-goals

Section titled “Goals / Non-goals”

Goals. Define the L-concepts layer (concept model, identity, type set, granularity); the resource: URI scheme and the anchors-only citation contract; the bundle structure (index.md / log.md / required frontmatter); the two-pass producer behaviour (Pass-1 from L-records, Pass-2 from the gated corpus); client-ownership and the bundle-publication irreversibility; and the reduce-not- remove RAG posture over ID-131’s record_embeddings.

Non-goals (sibling Tasks — referenced for sequencing only). The L-records refactor and the record_embeddings/record_lifecycle schema (ID-131 — this Task consumes, never alters them); the ontology pass and the allowed_types/allowed_relations register (Task D — this Task consumes the validator it produces, and the OKF concept-frontmatter ontology may be authored there); the {127.4} promotion-confidence corpus (Task C). ID-132 does not change any L-records table, RPC, or the pipeline’s extraction write-sites.

Behaviour

Section titled “Behaviour”

A. The concept model (what an L-concept is)

Section titled “A. The concept model (what an L-concept is)”

  1. BI-1 (concepts distil, never store). An L-concept is a markdown file that points to L-records (via resource: + # Citations) and carries a distilled, human-and-AI-readable synthesis — it never copies or re-hosts the underlying record content beyond that synthesis. No concept file is the system-of-record for any datum; the record is. (okf-record-model-v3.md §1, §7.2.)

  2. BI-2 (concept identity = the file path). A concept’s identity is its relative path within the bundle (e.g. security/encryption.md). A concept has no DB row and no uuid of its own (ID-131 {131.3} TECH:257–259). Renaming/moving a concept file changes its identity; the producer and the log.md must record such moves so inbound concept→concept references can be re-pointed (BI-9).

  3. BI-3 (a Q&A pair is never a concept). No bundle file represents a single q_a_pair. A Q&A pair is a record, not a concept (ID-131 BI-8; v3 §2.2). A concept that needs Q&A data references the q_a_pairs collection as a table/query (BI-8), never a per-row file.

  4. BI-4 — RATIFY: the concept-type set. Concepts are typed, and the type is carried in the tags: frontmatter list (Google’s okf pattern — a value, not a separate schema field; BI-12). (Amended S436 / DR-019: the type-in-tags reading misread the upstream spec — the type is carried in a free-form type: frontmatter field directly, which is simpler AND more conformant.) Recommended type set: {topic, product, company, certification, case_study, metric, dataset, playbook}.

    • Locked-by-evidence (warranted directly by the corpus): topic (the ~55 entries of the client’s BID RESPONSE TOPIC INDEX — the spine), product (Audit / LMS / Websites — three per-product libraries exist), company (01-company-overview + size/structure/PSC), certification (07-compliance-governance-and-certifications: ISO, Cyber Essentials, CREST, CSA CCM v4.0, NCSC Cloud Principles), case_study (04-named-clients-and-case-studies).
    • The genuine discretion (owner’s call): whether metric (quantitative claims — RTO 2hr, 99.9% SLA, PL £10m/PI £5m/EL £10m insurance, retention periods), dataset (structured references such as the Telehouse fact sheet, server-log retention tables), and playbook (process narratives — Secure Development Lifecycle, Support Model & SLA structure, incident/breach procedures) are distinct types or are folded into topic + a finer tag. Recommendation: keep metric and playbook distinct (they have different consumption shapes — a metric is a citeable number; a playbook is a “how we do X” narrative) and fold dataset into reference-tagged concepts unless a structured-table concept proves needed. RATIFY the final set.
    • Bid-outcome re-entry types (amended S443 / DR-029 — see §S443 Amendment). The retired won-bid content_types policy / methodology / capability re-enter as facet tags: on topic concepts (methodology ≡ the existing playbook facet), not new enumerated types; case_study (already enumerated) gains a won-bid source. The re-entry adds no new enumerated type — the enumerated grid stays {topic, product, company, certification, case_study}.

  5. BI-5 — RATIFY: concept granularity grain. Recommended: author topic concepts at the topic-index entry level — one concept per distinct citable answer-cluster (e.g. Encryption, GDPR & DPA Compliance, Business Continuity & Disaster Recovery) — and render the ~17 themes as index.md navigation sections (progressive disclosure), not as separate concept files. Target a bundle of ~30–50 concept files total (v3 §1). Per-product scoping: a product’s distinctive answers (LMS/Audit/Websites) become product-tagged concepts or product-scoped sub-sections; company-wide topics stay single. Owner’s call: entry-vs-theme grain for borderline topics, and whether near-duplicate per-product topics collapse to one company-wide concept with product-scoped detail. (This is the granularity decision v3 risk 5 flags as hardening at first publication — drive it from the client’s hand-built index, not invented.)

B. The resource: URI scheme + anchors-only citation

Section titled “B. The resource: URI scheme + anchors-only citation”

  1. BI-6 — RATIFY: the resource: URI scheme. Recommended: canonical://<table>/<uuid> for per-row record anchors — a stable, opaque, vendor-namespaced pointer value, never an identity key. Only {source_documents, reference_items} ever appear in the per-row uuid form (canonical://source_documents/<uuid>, canonical://reference_items/<uuid>). RATIFY the scheme string (canonical:// vs an alternative namespace).

  2. BI-7 (deterministic anchors only). Every record uuid that appears in a bundle is a deterministic seed-contract uuid — uuid5(_KH_PIPELINE_DOC_NS, "sd:"+rel_path) for a source_document, uuid5(…, "ri:"+source_url) for a reference_item (ID-131 BI-3/BI-6/BI-7). An opaque, re-minting q_a_pairs.gen_random_uuid() master uuid is never bundle-cited (ID-131 BI-5 / BI-8) — it would orphan on the next full-replace rebuild.

  3. BI-8 (the table/query resource form). A concept that references the Q&A corpus (e.g. a metric or dataset concept) uses a table/query resource form that names the collection and a filter, never a row uuid — recommended shape canonical://q_a_pairs?scope_tag=<tag> (or ?domain=…&subtopic=…). This is BI-3 made operational: the bundle may point at q_a_pairs as a queryable table, but never at an individual answer.

  4. BI-9 (ANCHORS-ONLY citation — LOCKED, owner-ratified 28/06/2026). The bundle’s # Citations sections cite only {source_document, reference_item, concept}. q_a_pair citation is DB-internal only (draft reuse, forms completion, win-rate — ID-131 BI-8). Record anchors use the BI-6 canonical://<table>/<uuid> value; concept→concept cross-references use the concept path (matching ID-131’s citations.cited_concept_path text, TECH:293), never a uuid.

  5. BI-10 (the single ingress of a Canonical id). The resource: field and # Citations body are the only places a Canonical record uuid enters the client-owned bundle. No frontmatter key, no concept body prose, and no index.md/log.md entry carries a record uuid as anything other than a citation/resource pointer value. (v3 §1: “the only place a Canonical record id touches the client-owned bundle, and it is a pointer value, never the concept’s identity key.”)

C. Bundle structure

Section titled “C. Bundle structure”

  1. BI-11 (bundle shape). A published bundle is: N concept .md files (organised in type/theme sub-directories), exactly one index.md (progressive-disclosure entry point: themes → concepts, with one-line descriptions), and exactly one log.md (append-only change history per producer run — concepts added/changed/removed/moved). (v3 §1, §7.2.)

  2. BI-12 (required frontmatter). Every concept file carries frontmatter with at least: type (or the type expressed via tags: per BI-4 — amended S436: a type: field directly), title, description, timestamp, plus resource: (its primary record anchor where one exists) and tags:. A concept missing any required key is not publishable (BI-13). Dates are UK format (DD/MM/YYYY); UK English throughout the bundle. (Amended S436 / DR-019: the timestamp frontmatter field and ALL log.md dates are ISO-8601 — the UK DD/MM/YYYY house rule applies to body prose only; a strict OKF consumer must be able to machine-parse timestamps.)

  3. BI-13 (validator gate on every write). No concept is written/published unless it passes a concept-frontmatter validator — required-key check + the BI-4 type set + the BI-6 resource: scheme + the closed ontology (12 entities / 10 relations) used as a semantic linter. This gates L-concept writes exactly as the Pydantic gate gates extraction writes (v3 §6 item 6, §7.2). The validator/ontology may be authored by Task D and consumed here; if Task D has not landed it, {132.2} TECH defines a minimal in-Task validator. (Evaluate lifting Google’s okf-skills validator rather than building from zero.)

Forward note (consumer permissiveness — E8 / OKF SPEC §6). The producer write-gate (BI-12/BI-13: required frontmatter + validator) is deliberately STRICTER than the OKF SPEC’s consumer contract. A producer-side superset of OKF SPEC §6’s type-only minimum is OKF-legal, but any future Canonical OKF consumer (an MCP reading the bundle) MUST be permissive per OKF SPEC §6 — tolerate missing optional fields, unknown type values, and broken links — and MUST NOT inherit this write-gate’s strictness as a read contract.

Backlog candidate (E8). A consumer-side OKF-bundle MCP — list/read/search over the bundle directory, lifting the MarkdownFileset pattern (see {132.2} TECH, Pass-2 reader note) — is a backlog candidate that would complement the EMB-STORE vector traversal (BI-25) with a direct file-tree reader for wholesale/local bundle reads.

  1. BI-14 (client-owned private git repo). The bundle lives in a client-owned private git repository — not inside the Canonical application repo and not in the L-records DB. Canonical operates the producer; the client owns the artefact (v3 §1: two of three layers are client-owned). This is what makes “we don’t extract your value / you keep your canonical files” literally true.

D. The two-pass producer

Section titled “D. The two-pass producer”

  1. BI-15 (Pass-1 — draft from L-records only). Pass-1 drafts one concept per named asset purely from Canonical L-records, via a pluggable Source adapter over the typed tables + entity graph (the list_concepts / read_concept_raw / sample_rows Source protocol). Pass-1 performs no web access. It writes the concept body + initial # Citations (record anchors) + frontmatter (v3 §7.2).

  2. BI-16 (Pass-2 — enrich from the GATED corpus only). Pass-2 enriches each concept from the gated authoritative corpus (the client’s own sources — 10-site-structure-and-key-urls), with the reference_agent’s host-allowlist + depth-limit + path-filter knobs wired to those sources only, never the open web (owner §B; v3 §7.2). Pass-2 adds enrichment prose, creates references/<slug> reference concepts, and appends citations.

  3. BI-17 (concepts point, never store — producer obligation). Across both passes the producer emits pointers (BI-6/BI-8/BI-9), never copies of record content. Any datum a concept asserts is traceable to a cited record or a cited gated-corpus reference; an uncited factual assertion is a producer defect.

  4. BI-18 (incremental / delta-only). The producer is incremental — re-running regenerates only concepts whose source records/corpus changed (the declare_file memoised FILE-target pattern, v3 §7.2), and regenerates index.md + appends to log.md. A no-op re-run produces a no-op diff.

  5. BI-19 (git knowledge-sync — RATIFY: timing). A git “knowledge-sync” writer, outside cocoindex, commits producer output to the client-owned private repo and supports point-in-time rollback. Recommended: one commit per producer run (atomic, auditable, easy rollback). Owner’s call: per-run vs batched commit cadence (v3 §7.2 marks this unspecified). The git layer is what makes the bundle versioned and the irreversibility (Group E) durable.

E. Client-ownership & the bundle-publication irreversibility

Section titled “E. Client-ownership & the bundle-publication irreversibility”

  1. BI-20 (first publication is the true point-of-no-return). The first publication of the bundle to the client-owned repo is the irreversible act of the entire programme — it pins deterministic record uuids (BI-7) into a durable, client-owned artefact (v3 §0.3, §2.4, §10 SEED-CONTRACT). Before first publish the whole stack is re-seedable pre-launch (ID-131 BI-2); after it, a canonical://source_documents/<uuid> in a shipped concept is a contract.

  2. BI-21 (seed contract must be CI-green before first publish — HARD gate). The producer must not publish a bundle until ID-131’s frozen seed contract (the _KH_PIPELINE_DOC_NS namespace

    • the sd:{rel_path} / ri:{source_url} / qa:{rel_path}:{idx} seed-string formats) is asserted by its CI test and green (ID-131 BI-7). If the seed strings or namespace are later “tidied”, every pinned canonical://<table>/<uuid> silently orphans (v3 risk 4) — so the publish step checks the seed-contract test as a precondition.

  3. BI-22 (no silent re-pointing of a pinned anchor). Once a record uuid is pinned in a published concept, a subsequent producer run must not silently change that anchor to a different uuid. If a previously-cited uuid no longer resolves in L-records (e.g. a source file was removed/renamed upstream of the seed), the producer flags an orphaned citation (in log.md and as a producer warning) rather than quietly re-pointing or dropping it. (Derives from v3 risk 4; protects the durable artefact.)

  4. BI-23 (EMB-STORE must be ratified before the producer relies on it — sequencing). The producer relies on ID-131’s record_embeddings for the concept vector index (BI-25). Per v3 §7.3 the EMB-STORE is a Task B → Task A dependency: if it lands after the producer, Pass-1 has no vector index for the long-tail RAG retention. Producer scaffolding + the agent-loop port (Group D) may be built in parallel with ID-131, but concept vector indexing and first publish wait on ID-131.

F. RAG posture — reduce, not remove

Section titled “F. RAG posture — reduce, not remove”

  1. BI-24 (load wholesale where it helps). The bundle is sized to fit one context window (~86k tokens for the first client — v3 §1) so an AI agent can load the whole bundle into context for a drafting/synthesis task rather than retrieving fragment-by-fragment. RAG is reduced, not removed (owner §A): wholesale load is the default where the bundle fits; retrieval is the fallback for the long tail.

  2. BI-25 (vector index over the bundle via the shared EMB-STORE). Each concept is embedded into ID-131’s record_embeddings with owner_kind='concept' and the pinned model (text-embedding-3-large, dim 1024 — ID-131 TECH M1b), so one store serves both L-records hybrid_search and L-concept bundle traversal. The producer writes the concept embedding on each create/change (delta-only, BI-18).

  3. BI-26 — RATIFY: concept vector key reconciliation. record_embeddings.owner_id is typed uuid (ID-131 TECH:288) but a concept’s identity is a path (BI-2). Recommended: the producer derives a deterministic owner_id = uuid5(<concept-namespace>, <concept-path>) so the concept’s embedding key is stable across regenerations and storable in the uuid column, while the citation still uses the path (BI-9). Owner/TECH note: this is the one place the path-vs-uuid duality surfaces — {132.2} TECH must reconcile it (a concept-namespace constant added to the seed-contract family, or an ID-131 follow-up to widen owner_id). RATIFY the approach; flag to ID-131 if a schema touch is needed.

Deferred to {132.2} TECH (not resolved in PRODUCT)

Section titled “Deferred to {132.2} TECH (not resolved in PRODUCT)”
  • Agent-loop framework. Porting the reference_agent two-pass loop from Google ADK+Gemini to the Anthropic tool-use surface (claude-opus, already used at extraction.py) for provider consistency, with a Gemini lift-and-shift fallback if the port slips (v3 §7.2, risk 3). This is the real cost behind “lift-and-shift” and is a TECH/implementation-framework decision, not a product behaviour — TECH must run the ID-131-style empirical import-and-call verification against the pinned Anthropic SDK before relying on any agent-loop API.
  • The Source adapter shape over L-records (which tables/joins back each concept type; how the entity graph feeds a concept) — a TECH design driven by BI-4/BI-5.
  • The bundle viewer (lift-and-shift of the reference_agent viewer/) — read-only, out of the product-behaviour scope here.
  • BI-26 owner_id reconciliation — concept-namespace constant vs an ID-131 owner_id widening.

Sequencing constraints carried into TECH/PLAN

Section titled “Sequencing constraints carried into TECH/PLAN”

ID-131 first (record uuids + record_embeddings + the green seed-contract test) → producer scaffolding + the ADK→Anthropic agent-loop port may proceed in parallel with ID-131 → Pass-1 (Source adapter, L-records only) → Pass-2 (gated-corpus enrichment) → concept vector indexing (needs record_embeddings) → first publish only after BI-21 (seed contract green) and BI-23 (EMB-STORE ratified). The concept-frontmatter validator (BI-13) is consumed from Task D or minimally defined in {132.2}.

Quality bars (inherited by {132.2} TECH and every Executor)

Section titled “Quality bars (inherited by {132.2} TECH and every Executor)”

UK English (DD/MM/YYYY, “colour”, “organisation”) in the spec and in the produced bundle; semantic design tokens only for any viewer UI; auth.success + authFailureResponse(auth); getAuthorisedClient() / sb() / tryQuery() Supabase safety; no barrel re-exports (direct file imports); TanStack Query only for any UI data fetch; bun run test (never bun test); behaviour-first tests (test-philosophy.md). Tool-discipline for the implementation wave: gitnexus impact({direction:'upstream'}) before modifying any existing symbol (warn on HIGH/CRITICAL), gitnexus detect_changes() before committing, gitnexus rename for renames; ast-dataflow column-reads/column-writes to pin any TS consumer of record_embeddings; grep for the Python pipeline + SQL migrations. Pre-ratification empirical import-and-call verification (date / pinned version / symbol / result) is MANDATORY in {132.2} TECH for any third-party API the producer cites (Anthropic SDK, cocoindex declare_file, reference_agent ports).

S436 Amendments (2026-07-02 — owner-ratified via the S436 decision board)

Section titled “S436 Amendments (2026-07-02 — owner-ratified via the S436 decision board)”

Ratified after the S436 upstream-conformance check (reports/s436-okf-adjudications/s436-okf-conformance.md) and storage/review-bridge adjudication (reports/s436-okf-adjudications/s436-okf-storage-adjudication.md). Register entries: DR-016, DR-018, DR-019.

  1. BI-4/BI-12 conformance fixes (DR-019). Concept type is a free-form type: frontmatter field (the “type-in-tags is the okf pattern” claim is dropped — upstream uses type: values like metric/playbook directly). The timestamp field + all log.md dates are ISO-8601; DD/MM/YYYY applies to body prose only. The bundle-root index.md frontmatter stamps okf_version: "0.1". The bundle ships a short CONFORMANCE.md documenting the two deliberate OKF-legal supersets (closed validator-enforced type taxonomy; the opaque canonical:// scheme) — and restates E8: the validator never gates READS of third-party OKF.

    SUPERSEDED IN PART 2026-08-10 (id-427 {427.13}), on THREE independent axes:

    • Superset 1 — the closed, validator-enforced type taxonomy — is WITHDRAWN, ratified at DR-019’s S545/S546 amendment (“Divergence 1 … is WITHDRAWN”), with the reasoning and the replacement enumeration model in DR-141. The producer holds no concept-type register: type is validated by SHAPE (validator.check_type_shape).
    • okf_version is "0.2", not "0.1" (id-426, S546 — generated: { by, at } replaces timestamp, provenance moves to frontmatter sources[] plus [^id] footnotes, and the # Citations trailer is retired).
    • Whether the file should exist at all is an OPEN question owned by id-431, whose entire goal is deciding that once its supersets are gone. DR-019 records the CONFORMANCE.md house rule as “re-opened with id-431”.

    The E8 restatement is UNAFFECTED and still holds: the validator never gates reads of third-party OKF. {427.13} deliberately did not edit the bundle’s own CONFORMANCE.md — see its record in tasks/id-427.md for why that edit routes to id-431.

  2. BI-27 (human edits are producer overrides — NEW invariant, frozen before first publish; DR-016). An approved human edit to a concept is captured as a producer override keyed by concept_path + section/frontmatter-field, applied ON TOP of the fresh Pass-1/Pass-2 draft on every regeneration (draft → apply overrides → diff → propose) — never a direct file mutation, which declare_file’s fingerprint-overwrite/orphan-delete would clobber. This upgrades the BI-22/TECH 3-way reconcile from flag divergence to flag → capture-as-override → re-apply, and requires the producer to EMIT its per-run proposed-change set machine-readably (it already computes this for log.md). The user-facing accept/edit/reject review UI is a follow-on human surface (DR-013 shape, id-135-adjacent) — id-132 owns only the producer-side contract.

  3. Producer trigger (DR-018, {132.16}). A successful ingest walk with source_documents deltas chains a producer run; manual operator invocation retained; TECH’s unpinned “different cadence” wording is superseded by this ruling.

S443 Amendment (2026-07-09 — DR-029 bid-outcome concept re-entry, {132.17})

Section titled “S443 Amendment (2026-07-09 — DR-029 bid-outcome concept re-entry, {132.17})”

Scopes the re-entry of the four won-bid KB-integration content types retired by {131.28} Part 2 (OQ oq-66a0c5410864622b HYBRID RETIRE / DR-029) — case_study / policy / methodology / capability + the update_existing rebuild action removed from app/api/procurement/[id]/outcome/integrate/route.ts (landed main b89ae76a), with the intent that they re-enter via THIS producer as concepts, never as content_items rows. The won-bid Q&A branch already re-points to draft q_a_pairs (UC5 promote path, origin_kind='derived_from_form_response'); this amendment rules the non-QA re-entry.

  1. BI-4 mapping ruling (bid-outcome types).

    • case_study — already a ratified enumerated type; a won bid is a first-class case_study source (gains a won-bid enumeration grain in {132.4} G-SOURCE — see the TECH G-SOURCE amendment).
    • methodology — folds under the existing playbook facet tag (the same “how we do X” narrative shape BI-4 already names for the Secure Development Lifecycle / incident procedures); no new tag.
    • policy and capability — enter as two new facet tags: (policy, capability) on topic concepts (a policy IS a citeable answer-cluster — several BID RESPONSE TOPIC INDEX themes already ARE policies; a capability is a “we can do X” answer-cluster, product-scoped per BI-5 where product-specific).
    • No new enumerated type, no new join for policy/methodology/capability: they refine the existing topic enumeration (which already reads all promoted q_a_pairs by scope_tag), matching the ratified BI-4 precedent that metric/dataset/playbook are tag-carried facets, not enumerated types. Rationale: three new enumerated types would fragment the BI-5 ~30–50-file spine and duplicate the topic join over identical source data.

  2. BI-28 (bid-outcome re-entry is proposal-shaped — NEW invariant; DR-029, DR-025 admission gate). A concept (or topic-concept facet refinement) seeded by a won-bid outcome enters the bundle as a DRAFT concept PROPOSAL in the producer’s staged proposed-change set (the BI-27 substrate), carrying won-bid provenance (source_workspace_id), gated by the human accept/edit/reject review before publish — never an automatic bundle write and never a content_items row. It differs from the Pass-1/Pass-2 drafting-from-promoted-L-records flow (§D) only in provenance: the won-bid outcome does not itself trigger a producer run (DR-018 triggers on source_documents deltas), and its q_a_pairs flow in when promoted through the knowledge-admission gate (DR-025 — authority earned at promotion, human review the launch posture). An auto-published or content_items-written bid-outcome re-entry is a defect.