the-custodian/workplans/CUST-WP-0060-work-record-canonization.md

---
id: CUST-WP-0060
type: workplan
title: "Work-record canonization — unified ontology, stages 1–2"
domain: infotech
status: finished
owner: codex
topic_slug: custodian
planning_priority: high
planning_order: 60
created: "2026-07-20"
updated: "2026-07-20"
state_hub_workstream_id: "68cb635b-8c6d-5e43-8def-0e520506bcf0"
---

# Work-record canonization — unified ontology, stages 1–2

Execute stages 1 (canonize) and 2 (schema + CI) of
`research/WorkOrchestrationArchitectureDraft.md` v0.2 (founder-reviewed
2026-07-20): ratify the work-record umbrella ontology as canon and make it
machine-enforced, with **binky-control as pilot** — its AWQ/DEC/OH queue
items become schema-valid, hub-indexed work records without renaming a
single id. Stages 3–6 (hub intake entity, generated views/index, tags &
flow metrics, legacy retirement) follow in successor workplans once this
foundation holds.

Origin: AWQ-010 sidetrack reintegration (2026-07-19); every artefact this
plan lands exists to make that class of manual reintegration structurally
unnecessary.

## Task: Founder ratification of the two canon standards

Present `work-record-types_v0.1.md` (+ `work-record-types.yaml`) and
`autonomy-lanes_v0.1.md` for founder review; apply edits; flip both from
`status: draft` to `status: active`. Ratification is a decision work record
(hub decision, red lane — canon change per constitution review gate).
Yellow lane (preparation); resolution founder-only.

```task
id: CUST-WP-0060-T01
status: done
priority: high
state_hub_task_id: "afacbb73-4285-5593-80ec-7ab4fe21375d"
```

## Task: Extend workplan-terminology standard, don't fork it

Add the work-record umbrella and kind vocabulary to
`workplan-terminology-fleet_v0.1.md` as a v0.2 revision (workplan and task
definitions unchanged; new terms cross-referenced to
`work-record-types_v0.1.md`). Update the terminology scan tooling exclusion
list if needed. Green lane.

```task
id: CUST-WP-0060-T02
status: done
priority: medium
state_hub_task_id: "2a5ee66b-c95c-5bdb-9784-e3d2eba781b6"
```

## Task: YAML block schemas per kind

Author JSON-Schema definitions for the authored YAML block of each kind
(intake, decision, engagement; task/workplan blocks already parsed by
state-hub — align, don't duplicate). Schemas live in
`canon/standards/schemas/work-records/` with the machine registry as the
pattern source. Include the spine-field requirements and grandfathered
legacy patterns (AWQ-/DEC-/OH-). Green lane.

```task
id: CUST-WP-0060-T03
status: done
priority: high
state_hub_task_id: "3bfabd1b-faf4-5f8f-93bb-b138912ebc97"
```

## Task: Forgejo CI validation action

A reusable Forgejo workflow (`repo-seed` + rollout to control-plane repos)
that validates all work-record YAML blocks in changed files against the
schemas and the id-pattern registry on push/PR — the GitOps
"validate before apply" gate and the first half of the sidetrack detector.
Must be fast (<5 s), zero-config when the repo has no records. Blue lane.

```task
id: CUST-WP-0060-T04
status: done
priority: high
state_hub_task_id: "50eded2b-62c0-55d6-b622-26251a80c250"
```

## Task: fix-consistency sidetrack detector (C-25)

Extend `statehub fix-consistency` with a check that scans registered repos
for id-like patterns (`[A-Z]+-[A-Z]+-[0-9]+` heuristic) **not** matching the
type registry and warns with the reintegration-cost message. No
registration yet (that is stage 3) — detection only, so new species surface
the day they appear. Green/Blue lane, lands in state-hub per its
governance.

```task
id: CUST-WP-0060-T05
status: done
priority: medium
state_hub_task_id: "03ff7177-9156-539f-a9c8-cb7266e958ed"
```

## Task: binky-control pilot — queues schema-valid

Bring binky-control's live documents (AutopilotWorkQueue, DecisionQueue,
OfficeHourQueue, RiskRegister) to schema validity: add missing spine fields
(`kind`, `lane`, `owner` where absent) to open items, wire the CI action,
run fix-consistency clean with the new checks. **No id renames, no format
migration** — grandfathered patterns must pass as-is; that is the
acceptance test for the grandfathering design. Blue lane (binky-control
commits).

```task
id: CUST-WP-0060-T06
status: done
priority: high
state_hub_task_id: "c05b4c51-2d78-5940-aaa9-afa6895e6ab7"
```

## Task: Closure — stage-3 handoff package

Closure review per ADR-001; write the stage-3 successor workplan seed
(state-hub intake entity, promotion transition CLI/MCP, generated per-repo
index) with evidence from the pilot: schema friction observed, CI runtimes,
detector findings across the fleet. Green lane.

```task
id: CUST-WP-0060-T07
status: done
priority: medium
state_hub_task_id: "f0c6ab7e-47ef-5ef0-baf9-bfa02e09a65a"
```

## Closure Review — 2026-07-20

**Outcome:** All 7 tasks completed same-day; stages 1–2 delivered end-to-end
with green proof runs.

### Completed
- T01 — canon ratified (founder, no edits; hub decision `f4640f9e`); both
  standards + machine registry flipped to `active`.
- T02 — `workplan-terminology-fleet` v0.2 addendum (umbrella vocabulary;
  file keeps `_v0.1` name for reference stability).
- T03 — JSON schemas: `canon/standards/schemas/work-records/`
  (spine/intake/decision/engagement; conditional spine requirements,
  historical grace for terminal records).
- T04 — `tools/validate_work_records.py` + reusable Forgejo workflow
  (repo-seed `work-records.yaml`). Substrate lesson: ubuntu-latest =
  node:20-bookworm, python via apt (first run failed 127, fixed).
- T05 — sidetrack detector landed as **C-31** (C-25 was taken — the
  workplan text said C-25; registry numbering, not this plan, is
  authoritative). Unit-verified: rogue id flagged, grandfathered id passes.
- T06 — binky-control pilot green: 45 records, 0 errors, 0 warnings,
  **zero id renames**; CI run #1751 success. Registry additions during
  pilot: legacy task variants `-T1`, `-LEGACY-Txx`.
- T07 — this review.

### Evidence
- Local runs: the-custodian 384 records / binky-control 45 records clean.
- CI: binky-control Work Records run 1747 (fail, substrate) → 1751 (green).
- fix-consistency on binky-control with C-31: 0 sidetrack warnings.

### Stage-3 successor seed (next workplan, state-hub + the-custodian)
1. **Intake entity** in state-hub (fresh table per founder decision;
   UUIDv7 keys), fix-consistency registration for intake/decision/
   engagement kinds (the write-back fields `state_hub_intake_id` etc. are
   already in the schemas).
2. **Promotion transition** as one CLI/MCP call (`intake.routed →
   workplan|task|decision|engagement` with `promoted_to`/`origin`
   back-links, both files written, both synced).
3. **Generated per-repo work-record index** (transclusion-style; markitect
   involvement) + regeneration of binky queue view tails as `[auto]`.
4. Friction observations for stage 3: schema authoring cost was near zero
   for existing binky items (they passed unmodified); the only true churn
   risk is the view/authored split — keep authored blocks where they are,
   generate *around* them.
5. Suggestion-table close-out (read-only legacy) once the intake entity is
   live.
6. **New report-sink for activity-core** (added 2026-07-20, Forgejo-issue
   housekeeping session): `daily-todo-md-stale-review` was found still
   routing through the deployment-wide `IssueSink` (`ISSUE_SINK_TYPE=rest`
   → issue-core → Forgejo) — the only fleet consumer of the `task_template`
   rule action, and the source of 5 stale-review issues nobody was meant
   to see (Forgejo issue tracking is not the fleet coordination mechanism).
   Paused (`enabled: false`) rather than left running; re-enable requires
   a new activity-core report-sink type that authors a `kind: intake` work
   record in the target repo (per this workplan's stage-3 promotion
   design) instead of an `IssueSink` task spec. Any other `ActivityDefinition`
   that later adds a `rule.action.task_template` inherits the same trap —
   worth a fleet-wide grep before stage 3 ships.