Skip to content

spec: the rest of the incident-response, training and change-management families — every remaining key and all fifteen defs — has zero readers; whole-def enforce-or-remove is the open question left after #14477 #15513

Description

@os-sales

Found while executing #14477 (retiring the fourteen hour/minute/day-shaped deadline keys of these three families under ADR-0049). Not addressed there — the ruling on that card scoped the retirement to the deadline-shaped keys, and this is the same enforce-or-remove question one level up: the whole families.

What was measured

The reader census that grounded #14477 was run over the families, not only the deadline keys, on origin/main (a06faebbe, re-run on the merged head 83a3353e3):

  • zero references to any of the fifteen schema or type names exported by packages/spec/src/system/incident-response.zod.ts, training.zod.ts and change-management.zod.ts (IncidentSeveritySchemaIncidentResponsePolicySchema, TrainingCategorySchemaTrainingPlanSchema, ChangeTypeSchemaChangeRequestSchema, and their z.input / Parsed types) anywhere in packages/**, apps/**, examples/** or skills/** outside packages/spec — the only holders are the generated api-surface/ and declaration-map/ shards and the families' own unit tests;
  • zero hits in objectui at the pinned sha 00d3f09c5 for the same names;
  • the schemas are exported from @objectstack/spec/system (system/index.ts), mounted by no key of stack.zod.ts, registered as no metadata type, and absent from the 2026-06 liveness ledgers under docs/audits/ (which is why spec: hour/minute/day-shaped deadline keys in incident-response, training, change-management and ESignature schemas have zero readers and no EXPERIMENTAL tag (ADR-0049 shape) #14477 could not be a ledger dead verdict either).

So after #14477 lands, roughly a hundred declared keys remain on these fifteen defs (counted as schema key: lines: 40 in incident-response, 25 in training, 52 in change-management, fourteen of them now tombstones), every one on the exported surface and in the generated reference docs, and every one read by nothing. Several are boolean capability claims of exactly the shape ADR-0049 names: IncidentNotificationRule.notifyRegulators, IncidentResponsePolicy.requirePostIncidentReview, TrainingPlan.trackCompletion / sendReminders, TrainingCourse.mandatory, ChangeRequest.securityImpact.requiresSecurityApproval, ChangeRequest.approval.required — an author writing notifyRegulators: true holds a compliance promise the platform does not keep, with no error and no feedback.

Why it is filed rather than folded into #14477

The ruling on #14477 (2026-09-02, ruled A) retired the deadline keys per family and left the families standing. Whether a family is roadmapped — the one variable that flips retirement into an [EXPERIMENTAL — not enforced] tag — is product knowledge, and it was asked per family there; the answer for the remaining surface is not in the code.

Suggested disposition (for triage, not decided here)

Per family, the two ADR-0049 routes: whole-def retirement via RETIRED_DEFS_BY_MAJOR (the integration/ErrorMappingConfig precedent, #14676 — every def leaves the public surface and the manifest ratchet adjudicates it), or an [EXPERIMENTAL — not enforced] marker on every def plus liveness-ledger enrolment so the next audit does not miss them again. Either way the reference docs stop advertising a compliance subsystem that does not exist.

Refs #14477 (the deadline-key retirement; branch claude/issue-14477-inert-deadline-key-retirement).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions