Proposals

Design notes that set out options and what each one costs, before anything is built. A proposal is not a commitment — it exists so that a decision can be argued with while it is still cheap to change, and so that the reasoning behind the option eventually chosen survives the session that produced it.

A proposal says what would decide the question, not only what the author prefers. If it cannot say what evidence would change its mind, it is an opinion wearing a heading.

This is where a harness feature’s proposal lives, and where it is updated. That covers initial analysis, the MVP, the options, and what was agreed (owner, 2026-09-23, issue #1164). When the feature ships, its proposal is moved to Requirements and filed against the Requirement schema. It is never copied: check:requirements refuses a name that is in both. The steps are in the CRDM requirements workflow.

proposal	question
Semantic subgraphs	Can a downstream mount the part of the harness it needs, a concern such as publication, SDLC or doc ingestion, instead of the whole harness? Owner, 2026-10-09: the just-the-docs chrome and the themes beyond light/dark become their own subgraphs. Measured: a remote mount names only top-level directory ids; the chrome is referenced by path from about 130 files; the themes are 14 entries in one TypeScript list plus 5.1 MB of art. Four layouts for the eight concern groups across docs and code; option C is recommended: kind-first, and a two-phase mount (load a named subgraph’s hydrated metadata, review it, then materialize a chosen set). Three gaps from today, measured. Five owner decisions
Workflow state in beans	Should a running BPMN process keep its position in the bean itself, or in its own store? Four options with what each costs. Decided 2026-09-18: Option A — two stores, one link — with both moved out from behind dotfiles to beans/ and beans/workflow/
Deployment topologies	How should the harness describe the ten deployment scenarios in #363 — local git only, private repo, sovereign cloud, self-sovereign, developer, swarm, benchmarking — when they can also be mixed? Decided 2026-09-19: ten topology axes plus six operating modes, so a mix is a point in the product rather than a new named mode. Carries the incompatible pairs a free product would otherwise admit. Still open: whether sovereign cloud and self-sovereign are two topologies or one
Credentials: needs and supply	How should credentials work when keys have as many deployment scenarios as the harness (personal, organization, sovereign forge, self-sovereign)? Proposal, 2026-10-02: a workflow DECLARES a capability need (an action and a target), and a deployment PROFILE supplies a mechanism (GitHub App, fine-grained token, deploy key, forge token, keystore). Secrets are named for the capability (PUBLISH_SITE_BOOTSTRAP, not BOOTSTRAP_PAGES_TOKEN). Authenticating is not signing, and today the harness signs nothing it publishes. An agent reads needs and secret names and never a value. A measured inventory of every secrets.* reference, an outline of a secrets skill and a secrets:check tool, and four owner decisions. Bean vobp
Wallet custody	May a self-sovereign harness HOLD a person’s credentials, not just produce what wallets consume? Owner, 2026-09-24: it may. Seven questions come before any code: whose credentials, hold or broker, where the bytes live (never the repository), which actors may use one, audit, offline revocation, and which standards. Issue #370
Migrating AGENTS.md into skills	Which of AGENTS.md’s 19 sections are bootstrap, which are pointers, and which are the “migration debt” the file names in its own banner? Survey, not a migration: every section classified with its destination, four subjects found to have no owning skill at all, and the two-AGENTS.md constraint that decides what may move. Corrects two counts an earlier survey asserted
The bootstrap graph	What is bootstrap/ — the graph an agent reads before it knows whether the repository is an instance, what kind, or what for? A standalone graph that may not import the harness, a README that is a conformance test of the graph’s own self-documentation, a two-branch BPMN, two skills and no MCP. Not built: the design is settled, no code exists. Records the late correction that intent is an INSTANCE REFERENCE, not a harness-type enum, and the two questions it does not answer
SDLC process audit	Which of the 33 BPMN diagrams owns which phase of the software life cycle, and which phases nothing owns? Audited against ISO/IEC/IEEE 12207’s technical processes. Five phases unowned, one half-owned, and the missing artefact has an exact template already in the repository: content-change-review.bpmn draws this loop at 22 activities, for content, and there is no code-change sibling. Confirms the MVP subprocess already exists, so #363’s MVP ask is a reference rather than a drawing. Nothing is drawn here by design
Actor facts and their processes	Two asks — air-gapped as a property of an ACTOR forcing a human signing route, and the missing actor/role processes — answered as one defect: a declared actor fact that no process reads. The crux is a schema gap: degradation’s fallback is always another CAPABILITY, so “the API cannot reach out, therefore a person signs” is unexpressible. Also: the actor→role→lane join is clean (31 of 31 roles bound), but role-management is held by one actor and exercised by nothing. Fourth sighting of the category error ind9 already fixed once
Does the prose say what the artefact does?	One review axis for every declared prose ↔ code pair — a diagram and the workflow it draws, a skill and the code beside it, a proof and its Lean — with Lean as a specialisation. Signed off 2026-09-23 (#1042) as three stages: a staleness flag first, because it asserts nothing about truth and so cannot cry wolf; then mechanical claim checks; then a review branch that sends disagreement to adjudication
Actors, ODRL and PROV-O	How to simplify the actor / role / permission schema, now that the owner has chosen W3C ODRL 2.2 for permissions and W3C PROV-O for logging (2026-09-23)? Actors become prov:Agents with no permission list. The 14 flat permission ids become an ODRL profile in which 9 are kinds of task under cat-harness:perform. Grants are ODRL rules scoped by Process, Task and Role constraints, and every task run is a prov:Activity. The deterministic and the agentic BPMN engine then check one policy, before and after the fact. Computable data sharing agreements (odrl:Agreement as a VC, GDHCN, HCERT) are the next proposal
Which top-level directories are not declared subgraphs?	The first half of the owner’s 2026-09-23 subgraph ruling — “in harness <stub>/*.* should be a subgraph” — measured rather than swept. 80 top-level directories across 17 instances, 62 declared, 18 not; but only 12 hold a file no declared directory covers, and cat-harness/content is 718 of those 744 and already bean ylj7’s. Outside it the whole gap is 11 directories and 26 files. Each is classified declare / fold / remove / already-declared / not-mine. Four of the removal candidates are QOU folio content the partition left in the platform stub; cat-harness/viewer/ is the sharp case, being folio-specific and e2e-tested. Records three corrections to an earlier count, including the scope: "repository" join that made eight declared directories look undeclared
Translation support by block kind	Which of the 16 block kinds does the gettext pipeline actually translate? An audit: none is supported end to end, because nothing renders a translated block. prose is partial. The math kinds are extracted, but their math is corrupted in the msgid ($a_i$ becomes $ai$). Captions, titles and figure descriptions sit in the .ts manifest, and nothing extracts them. Injection deletes every blank line. Storage check: the per-locale .po files match the owner’s model, but the .pot is copied into every target locale (363 templates against 19 catalogues) instead of kept as one source
KG subscriptions	How does a folio or harness consume an external Knowledge Graph (a substrate: bootstrap-conformant, with at least one harness), choosing which subgraphs, assets and harnesses to materialise? Argued: not a new mechanism but the relation joining remoteGraphs, associatedHarnesses, MaterializationSchema, Process_MaterializeRemote and pinned sync. Also covers known substrates (derived from #1652 where possible), a generated visualizer, and an eight-slice MVP inside the folio separation. Issue #1719
smart-* separation	How do the staged the DAK layer, the trust IG and the immunizations IG instances leave for the litlfred forks? Owner, 2026-10-01: one harness named the DAK layer that every IG repository instantiates identically (<dak-layer>.config.json plus the DAK layer), the DAK layer needing the FHIR IG layer, and everything FHIR-generic pushed down first. A per-file classification (F/S/D/X), six wrong-direction edges found in declarations rather than imports, six staged PRs, seven questions with defaults. Issue #1767
DTH candidates	What do the WHO Digital Transformation Handbooks define that this repository should adopt? 16 methodologies, 24 processes and 241 glossary terms read from the three DTHs and the draft DPI-H Reference Architecture, each with a verbatim citation, for the owner to choose from before anything is authored. 40 terms conflict, and one methodology contradicts diig.md. Bean 5blc, issue #1767
DAK kinds as a contribution	How do the DAK block kinds leave core without core importing the DAK layer? Through the registration path that already exists (ContributionRegistry), with the DAK layer as its first contributor of an adapter and block kinds. Core’s compile-time unions narrow to what core owns; “every kind” becomes a registry question. Measured: no content uses a DAK builder. Bean 1335, issue #1767
SMART document kinds: L1 and DAK	Stage D5 of the smart-* separation: L1 and DAK become document kinds inside the DAK layer, not harness layers. A generic document-kind graph typology in core (named structures of sections, fixed or semi-fixed, naming no WHO), with dak (the ten components, generated from DAK_COMPONENTS) and l1 as the DAK layer’s data, a viewer per kind, and a computed DAK view of every ingested IG. Why a content profile was the wrong mechanism, and two questions for the owner. Bean qvxh, issue #1767
Vocabulary mappings as declared ETL	One value, several target vocabularies (SKOS, Dublin Core, schema.org, PROV-O, a navbar tile), each written today as a hand-made line in a generator. An inventory: 59 mappings across 17 files, each with file:line. Two are already declarative tables (DCTERMS_MAP, replacedBy). Five findings: one IRI named by two predicates from two generators, a stale “exactly as the main export” comment, and a licence one RDF reader can see and another cannot. Four options for a declared mapping shape. Decided 2026-10-02: option 1, tables as KG data applied by one in-process Tool. Tables are ConceptMap-shaped, and every published HL7 ConceptMap example (174, R4 and R5) round-trips exactly. glossary-export now runs on them with byte-identical output. Bean k74z, issue #1872
Merge gate: adversarial review and compile gates	What must a merge to main PROVE beyond green CI? An independent agentic adversarial review of every agent-touched head with a committed verdict, a closed RED FLAG taxonomy that blocks until resolved or overridden on the record, Lean / SUSHI / JSON-LD compile gates scoped by changed path and run on the merge-train RESULT, and the same review run per content block for backfill. Site renders stay advisory. Not built. With a 30-item open-access reading list. Bean nok9
SPDX 3: where it should, could and should not be used	Where does SPDX 3 belong in this platform? At trust boundaries, as a generated export: the release SBOM, the kg-to-portal package manifest, licence ids and the notices built from them, and a published instance’s dependencies. Not as the store for QA verdicts, health reports or BPMN logs. A release points at its QA report through qualityAssessmentReport, and a certification report may be exported through SPDX 3.1’s EvaluationResult once 3.1 is final. Checked against the held SPDX 3.0 specification (library/omg-2024-spdx-3-0, methodology node spdx-3). Impact on existing processes, missing processes, prerequisite gaps, five owner decisions. Not built. Bean sd5v
index.config.json: who controls index.html	When a checkout instantiates several harnesses, which one is <base>/index.html, and where is that written down? Decided 2026-10-07 and being built: one root index.config.json (folio-index-config/v1) lists the instantiated harnesses, each one’s source (local, or a remote mount moved off the root declaration’s remoteMounts), its imported <name>.config.json with inline overrides, and site.landing. When the file is absent, today’s behaviour is unchanged. The lock is renamed to index.lock.json, with a legacy read fallback. index is reserved in every root scan, the mount paths go in a generated .gitignore block, and a converter handles the separated repositories. Issue #2483, bean ymvt
Tool releases and profiles	How does every repo use the same, auditable tools? Named, versioned, sha256-hashed tool releases, each with its OWN runtime (two tools may need two JREs; nothing is pinned globally), grouped into profiles a test selects. Each run logs in PROV-O which release and runtime it used (prov:used entities, not agents); an SPDX 3 SBOM is generated from the same records. Logging, not a gate: a tool that cannot be provisioned is a logged state, never a silent “rendered 0”. Reuses binary-release digests, upstream-pins, folio-tool-run, the PROV store. Closes G4 of the SPDX proposal and gives its D1 a consumer. Four owner decisions. Not built. Bean 3sbm, issue #2481
Checkout layout	Which of the three standalone layouts in force — the folio-assistant aggregate index, sibling clones, remote mounts inside the checkout — is canonical? Measured: one declaration got two answers in two layouts (the graph-typology registry, fixed); 31 scripts in the tools layer compute a root at a fixed depth; the layer’s own CI runs only inside the aggregate. Four options; option 1, remote mounts everywhere with package imports, is recommended. Not decided — the owner’s ruling (L1–L3)

---

Table of contents

• 5hox: the QA files that leave main - Inventory for bean 5hox (arc 3fva, proposal item 3.7): exactly which tracked files are the derived QA results that leave main, with their count, size and age, what was excluded and why, and the hash check against qa-reports.
• Actor facts and the processes that must read them - Two asks — air-gapped as an actor property forcing a human route for signing, and the missing actor/role processes — are one defect: an actor fact that nothing consumes. The fallback model can swap a tool and cannot swap an ACTOR, which is why the two signing routes are unexpressible today.
• Actors, ODRL and PROV-O: one permission language, one execution log - How to simplify the actor / role / permission schema now that the owner has chosen W3C ODRL 2.2 for permissions and W3C PROV-O for logging. Actors shrink to prov:Agents with no permission list; the 14 flat permission ids become an ODRL profile of actions that inherit through includedIn; grants become ODRL rules scoped by Process, Task and Role constraints; every task run becomes a prov:Activity. The deterministic and the agentic BPMN engine then check the same policy, before and after the fact.
• Auto-docs as rendered sub-graphs - Proposed 2026-10-03: 488 of the 908 pages under cat-harness/docs/ declare their generator in their own front matter, yet eleven merge-conflict patterns rediscover that fact by hand-maintained glob, 42 files are covered by none of them, one pattern id covers two generators, and the `docs` declaration itself admits the mixture without recording it. The arrow already exists in prose — `uml`'s declaration says "the rendered pages are docs/uml/overview/". The proposal is to declare that arrow structurally, so the merge pattern, the audit coverage and the gating decision all derive from one fact instead of eleven globs. Measurement and options; nothing is built, and the two questions that are the owner's are named rather than answered. SUPERSEDED the same day: the owner ruled for a reserved `auto-docs/` prefix with `docs/` kept for authored content, which is the option this page argued against — see §"SUPERSEDED" for why that recommendation was wrong (permalinks already decouple URL from path, so no published URL need break; and the namespace argument was never weighed) and for the measured migration cost. Includes the consolidation the same declaration would allow — 16 writers into docs/, 31 hand-written --check branches, 11 merge globs and 13 skill sections — with what must NOT consolidate (the per-writer carry-forward judgement, and the gated/ungated split, which turns on input set rather than generated-ness) and a three-step sequencing whose middle step is provably a no-op.
• Bean archiving in BPMN — the terminal state nothing draws - Every process that touches the work plan reaches `resolve` and stops. Archiving is drawn in no diagram, named in no skill, and unsupported by the engine — and `Process_BeanLifecycle`, the one diagram that models bean state at all, is called by NOTHING. That is mechanically why 219 completed beans sat inline until 2026-09-20.
• Checkout layout: which of the three standalone layouts is canonical - Three definitions of "a checkout of a separated layer" are in force at once — the folio-assistant aggregate index, sibling clones under one parent, and remote mounts inside the downstream — and every tool resolves its roots for all three, by guesses that disagree. Measured 2026-10-12: the graph-typology registry read kinds from the harness module's grandparent while the checks read declarations from cwd, so one file got two answers in two layouts (fixed in place, lesson 19); 31 cat-harness-tools scripts compute a root as `import.meta.dir/../..`; cat-harness-tools' own CI runs inside the aggregate. Four options; option 1 (remote mounts inside the checkout, everywhere, with package imports for code) is recommended. Not decided: the owner's ruling.
• Contributions and validators as KG nodes - A harness contributes block kinds, an adapter, QA checkers, renderers, pipeline plugins and MCP tools by exporting TypeScript from a contributions.ts module, and a graph typology names its validators as path strings. Owner, 2026-10-04: all of it becomes declared nodes in the contributing harness's KG, with code referenced as :path#export, and validators are nodes too. This note proposes the node shapes, one loader for all of them, and the order, and puts three choices to the owner.
• Credentials: needs declared, supply chosen by deployment - Owner, 2026-10-02: credentials need a design before any secret is created, because keys have as many deployment scenarios as the harness does (personal, organizational). A workflow or tool DECLARES a capability need (an action and a target); a DEPLOYMENT PROFILE resolves each need to a mechanism (GitHub App, fine-grained token, deploy key, forge token, keystore). Secrets are named for the capability, never the mechanism or the consumer. Authenticating and signing are separate needs, and today nothing the harness publishes is signed by the harness. An agent reads needs and secret NAMES and never handles a value. Four owner decisions; nothing is built.
• DAK block kinds as a smart-base contribution - Bean 1335, the remainder of stage D of the smart-* separation. Core's content model still names DAK — the `dak` adapter, its 21 block kinds, the ten components — so dak-blocks.ts cannot leave for smart-base without core importing a harness. The registration path already exists (ContributionRegistry, loadContributions, and folio-assistant-sci uses it); smart-base becomes its first contributor of an ADAPTER and BLOCK KINDS. Measured first: no content in the repository uses a DAK block builder, so the move changes how no existing folio parses.
• DTH candidates: methodologies, processes and glossary - What the three WHO Digital Transformation Handbooks and the draft DPI-H Reference Architecture define, extracted with a verbatim citation each, for the owner to choose from BEFORE anything is authored (bean 5blc). 16 methodologies, 24 processes, 241 glossary terms; 40 terms conflict with another definition.
• Deployment topologies and operating modes - Accepted 2026-09-19: ten topology axes x six operating modes. Moved out of the rendered site because a design proposal is not what a folio's readers need; the decision it records lives on issue #363.
• Derived-graph dependencies - A directory declaration says what a directory holds and where it is stored, but never what it is computed FROM. So regen, the main publish workflow and the staging cone cannot know that a change to the IG AST cache invalidates the IG pages, or that the IG pages feed the published site. This proposes one edge, `derivedFrom`, on the derived directory, resolved and checked the way a document kind's `computedFrom` already is; a topological rendering order computed from it; and, until it exists, declaration order as the rule, with a check that flags a consumer declared before its source.
• Does the prose say what the artefact does? - One review axis for every declared prose ↔ code pair, with Lean as a specialisation rather than the model. Signed off 2026-09-23 as three stages: a staleness flag, then mechanical claim checks, then a review branch that sends disagreement to adjudication.
• Instance versioning and dependency resolution, aligned to FHIR/SUSHI - Downstream alignment to FHIR/SUSHI is a hard constraint, which settles exact-version pinning over npm-style ranges. Proposes id + version on publishable instances, a dependsOn-shaped published record, and a version bump COMPUTED by diffing the exported graph rather than asserted by a commit message.
• KG subscriptions - A folio or harness SUBSCRIBES to an external Knowledge Graph (a repository that meets bootstrap's schema requirements and declares at least one harness), then walks each of its subgraphs, assets and harnesses from referenced to materialised, one item at a time and through the same five gates as every other materialisation. Also covers the list of known substrates, a visualizer, and the MVP inside the folio separation.
• LSI and CA on who-iris — each document, and the three together
• LSI epic-filing proposal — 2026-09-29
• LSI — applicability to ingestion, KG development, QA and the work plan
• Merge gate reading list - Thirty open-access sources behind the merge-gate proposal: code review evidence, keeping main green and merge queues, two-person review and supply chain, the risks of LLM-written code and LLM reviewers, adversarial oversight and judge bias, severity, formal-proof CI, FHIR IG CI and JSON-LD. Each has its URL's verification status, for uploading to the library.
• Merge gate: adversarial review and compile gates - Proposed 2026-10-02: what a merge to main must PROVE, beyond green CI. An independent agentic adversarial review of any agent-touched change with a committed verdict, a closed RED FLAG taxonomy, content-type compile gates (Lean, SUSHI/IG AST, JSON-LD + schema) scoped by changed path, and the same review run per content block so the corpus can be backfilled. AMENDED 2026-10-03 — the owner ruled the agentic review WARN-ONLY, so its findings are reported and never hold a merge; the compile gates are unchanged. Research, design and a reading list; nothing is built.
• Migrating AGENTS.md into skills - Survey of which AGENTS.md sections are bootstrap, pointers, or migration debt.
• Placement audit — every skill, tool, scenario, process and role checked against its layer (2026-10-01)
• Placement proposal: concern sub-subgraphs and staged moves across the layers
• Public comment, round 2: requirements from the chief-editor walkthrough - Proposed 2026-10-06, for the chief editor's sign-off BEFORE approval: seventeen requirements and four defects from a 17-minute CRDM walkthrough of the DPI-H Reference Architecture public-comment dashboard with its chief editor. Change sets get a type axis and a committee axis, new comments are ingested incrementally with duplicate detection, only an editor proposes or splits a change set, and human and agent categorisation are compared. It also carries the TWG Coordinator's 30-requirement specification for the categorisation skill (CAT-01 to CAT-30), mapped against both. Requirements are not built; the demo's defects are fixed.
• QA and test evidence off main - Derived QA verdicts move to an orphan, commit-keyed `qa-reports` branch; a strawperson TestPlan → TestRun → TestReport → certification process reuses the same execution record. Workplan, dispatch map and five owner decisions.
• QA readers audit - Every code path, workflow step, MCP tool, test and skill that reads a committed QA result, classified by how it must change when derived QA leaves main for the qa-reports branch. Each one records how it fails today when the file is absent, measured by moving the results aside. 95 read sites; 20 of them are false-clean or data-loss, from 11 distinct defects, and three of those are live on main today. Then a fix order and a dispatch grouping.
• SDLC process audit - Step 1 of bean haya: which of the 33 BPMN diagrams owns which phase of the software life cycle, and which phases nothing owns. Five phases are unowned and one is half-owned; the missing artefact has an exact template already in the repository.
• SMART document kinds: L1 and DAK - Stage D5 of the smart-* separation. L1 and DAK stop being harness layers and become DOCUMENT KINDS inside smart-base — a declared structure of sections, fixed (DAK: the ten components) or semi-fixed (L1) — with a viewer for each. The mechanism is generic and names no WHO; the two kinds are smart-base's data. Bean qvxh; the DTH subtype is bean 5blc.
• SPDX 3: where it should, could and should not be used - SPDX 3 belongs at trust boundaries, as a GENERATED export: the release SBOM, the kg-to-portal package manifest, licence ids and the notices built from them, and a published instance's dependencies. It is not the store for QA verdicts, health reports or BPMN task logs. A release instead POINTS at its QA report (3.0's qualityAssessmentReport), and a certification report may be EXPORTED through 3.1's EvaluationResult once 3.1 is final. Checked against the SPDX 3.0 specification, now ingested with a methodology node. Covers the impact on existing processes, the missing processes and tasks, the prerequisite gaps, and five owner decisions.
• Semantic subgraphs: site chrome, themes, and concern groups a downstream can mount - Owner, 2026-10-09, after who-iris's standalone site could not be composed without the whole of cat-harness's 97 MB docs graph: make the just-the-docs CHROME its own subgraph, make the THEMES beyond the light/dark/accessibility base their own subgraph, and carry the eight concern groups (`9umr`) through docs and code so a downstream mounts a concern, not a monolith. Measured: chrome is 4 generic includes, 8 CSS and 11 JS files and the theme keys of one config, referenced by path from ~130 files; the themes are 14 entries in one TypeScript list plus 45 art declarations (5.1 MB). A mount can name only top-level directory ids today. Four layout options for the concern groups; C is recommended: kind-first layout plus a TWO-PHASE mount (hydrated metadata of any named subgraph, review, then materialize a chosen set), which the owner described and which is three gaps from today (Tools have no hydrated index; mounts take no hydrated or nested ids; materialization takes whole top-level directories). Five owner decisions.
• Separation arc — consolidated workplan, gaps and migration checklist (2026-10-01)
• Separation placement review — 2026-10-06
• Split plan: cat-harness/ → litlfred/cat-harness (content) + litlfred/cat-harness-tools (code)
• State graphs on a declared branch - Proposed 2026-10-02: move process-written STATE graphs (beans, workflow instances, todos, issue-marks, health) off main onto one declared `state` branch, and make "which ref holds this graph" a declared property of every graph — generalising the qa-reports arc (3fva) rather than competing with it.
• The bootstrap graph - Design for `bootstrap/` — the graph an agent reads before it knows whether the repository is an instance, what kind, or what for. NOTHING HERE IS BUILT. Arrived on main in docs/ the same day proposals left the rendered site; moved here by the same rule, since a design a folio's readers do not need is not a page. Bean `x3bd`.
• Tool releases and profiles — named, versioned, hashed tools with per-tool runtimes, logged in PROV-O, exported as SPDX 3
• Translation support by block kind - An audit, not a change. For each of the 16 block kinds: where its reader-visible text lives, whether the gettext pipeline extracts it, injects it, renders it and QAs it, and what breaks. No kind is fully supported. Prose is partial. The math kinds are extracted but their math is corrupted in the msgid. Captions, titles and figure descriptions sit in the `.ts` manifest, and nothing extracts them. No build renders a translated block. The storage check against the owner's model: the `.po` files match it, but the `.pot` does not. There is no single source template: one copy of the `.pot` is written per target locale, which comes to 363 templates beside 19 catalogues.
• Vocabulary mappings as declared ETL - One value, several target vocabularies, today written as a hand-made line in each generator. An inventory of 59 such mappings across 17 files, each with file:line, plus five places where two generators disagree or a condition is only implicit. Four options were put to the owner, who chose option 1 on 2026-10-02: mapping tables as KG data, applied by one in-process Tool, and interoperating with FHIR ConceptMaps (representable in, producible out, round-trip exact). Built, with glossary-export moved onto it and its output byte-identical.
• Wallet custody in a self-sovereign harness - Owner, 2026-09-24: in self-sovereign mode the harness MAY hold credentials. This reverses the strawperson, which said the harness only produces artefacts. Holding a person's credentials is a security design in its own right. This proposal states what has to be decided before any code, and decides none of it.
• Which top-level directories are not declared subgraphs? - The first half of the owner's 2026-09-23 subgraph ruling, measured. 80 top-level directories across 17 instances; 62 declared; 18 not. Twelve of the 18 hold at least one file no declared directory covers, and one of those twelve (cat-harness/content, 718 files) is already another bean's. Outside it the entire remaining gap is 11 directories and 26 files. Each is classified declare / fold / remove / already-declared / not-mine, with the evidence for the classification. Three separate corrections to an earlier count are recorded, because the way that count went wrong is the same defect the ruling is about.
• Workflow state in beans - Decided 2026-09-18: Option A, two stores with one link, both moved out from behind dotfiles.
• Zod schemas as Tools — audit and analysis - Is Zod usage reachable through skills and Tools? No. 199 exported schemas, 3 named by a Tool node, 0 Tools that validate, 0 Tools bound to kg-navigation. The requirement already exists in #223 and is unmet. Analyses three routes; recommends one parameterised pattern keyed on graph typology, because the parameter is the graph typology. Corrected in place while implementing: the reference field already existed as GraphTypologyDef.schema, and it is not a validator — qa's declared module exports interfaces only — so a second field, validator, was added beside it.
• cmsl — the 23 directories cat-harness declares but does not hold
• index.config.json: who controls index.html - One root file, index.config.json (folio-index-config/v1), declares which harnesses a checkout instantiates, where each comes from (local, or a remote mount pinned to a SHA), how each imports and overrides its .config.json, and which one controls /index.html. It replaces an inference from every root *.config.json, a landing flag spread across those files, and remoteMounts on the root declaration. Decided and being built, 2026-10-07.
• smart-* separation - How the staged smart-base, smart-trust and smart-immunizations instances leave folio-assistant for the litlfred forks: one harness named smart-base that every IG repo instantiates the same way, smart-base needing fhir-harness, and everything FHIR-generic pushed down into fhir-harness first. A per-file classification, the wrong-direction edges it found, six staged PRs and the questions that gate them.