📊 Implementation Status & Capability Matrix
Evalium — Execution Ledger Edition (Authoritative)
This document tracks the implementation state of Evalium’s capabilities in a single, canonical view.
It is intentionally layered to distinguish:
- what defines the truth of the system
- what constitutes first-class product functionality
- what enables adoption and usability
- what is derived or future-facing
Important reading rule Section placement reflects importance to platform integrity, not engineering effort or commercial value.
- If a capability in Section A is wrong, the product fails under scrutiny.
- Capabilities in later sections may be essential for adoption, but they do not redefine truth.
Column Definitions
| Column | Meaning |
|---|---|
| Capability | Stable, broad name (non-industry-specific) |
| Description | What the capability does |
| Backend | Backend/API/domain implementation state |
| Workflow | End-to-end operational workflow state |
| Frontend | UI surface state (including intentional deferrals) |
| K / O / E | Which KOE modes use it |
| WORM Scope | Execution, Scaffolding, or N/A |
| Defensibility Controls | Append-only, Snapshot, Context, Verification, Step-Up |
| Current Implementation Notes | How it exists today |
| Dependencies / Blockers | What must exist first |
| Source Docs | Canonical references |
Status Lens (Backend-First Execution)
Evalium is intentionally developed backend-first. Matrix rows should be read with this lens:
- Backend answers: are primitives/contracts/enforcement implemented and testable?
- Workflow answers: is the operational flow usable end-to-end at the API/engine level?
- Frontend answers: is there a production UI surface for this capability?
Status values used across the three dimensions:
ImplementedPartialPlannedNot StartedDeferred (by design)(intentional frontend postponement while backend matures)N/A
Backend Maturity Gate
A capability is considered backend-mature when all are true:
- Contract is stable (schema/API semantics fixed enough for frontend activation).
- Enforcement is active where required (RLS, idempotency, verification/context policy).
- Regression coverage exists (smoke/integration tests listed in notes).
- Canonical docs are aligned (
FOUNDATION,architecture, security/policy docs).
KOE Consistency Note: K/O/E features must consume the Phase A primitives consistently. See the KOE Primitive Consistency Map in Section B.
🟥 Section A — Core Execution Ledger (Non-Negotiable)
These capabilities define forensic truth. They are not optional and must remain stable over time.
| Capability | Description | Backend | Workflow | Frontend | K/O/E | WORM Scope | Defensibility Controls | Implementation Notes | Dependencies | Source Docs |
|---|---|---|---|---|---|---|---|---|---|---|
| Append-Only Submissions | Durable execution records are never mutated | Implemented | Implemented | N/A | K O E | Execution | Append-only | submissions, submission_items treated as immutable | — | FOUNDATION.md |
| Amend (Not Edit) | Corrections via additive records | Implemented | Implemented | N/A | K O E | Execution | Append-only, History | submission_score_versions, correction batches | — | FOUNDATION.md, ADR-0010 |
| Void (Not Delete) | Logical invalidation with audit trail | Implemented | Implemented | N/A | K O E | Execution | Append-only, Reason | Submission/evidence void endpoints append ledger events (submission.voided, evidence.voided); submissions move to status=voided; evidence void supported for submission + item scope and blocks further evidence actions | Step-up auth | FOUNDATION.md |
| Version Snapshots | Freeze definition at execution time | Implemented | Implemented | N/A | K O E | Execution | Snapshot | version_snapshot stored on submission | — | FOUNDATION.md |
| Execution Ledger Boundary | Separate runtime vs durable data | Implemented | Implemented | N/A | K O E | Execution | Lifecycle separation | delivery_sessions vs submissions | — | FOUNDATION.md, LEDGER-BOUNDARY-AND-ENFORCEMENT.md |
| Verification Levels (L1–L4) | Trust grading of execution events | Implemented | Implemented | N/A | K O E | Execution | Verification | verification_level_policies drive context/step-up requirements; submissions, evidence, review actions, claims/disputes, and evaluation publish enforce policy at write boundary | Step-up auth | FOUNDATION.md |
| Contextual Binding | Require context for high-trust events | Implemented | Implemented | N/A | K O E | Execution | Context | Policy-driven context enforcement across submissions/evidence/review/claims/disputes/evaluation publish via validateVerificationContextWithPolicyTx | Policy engine | FOUNDATION.md |
| Step-Up Identity | Re-authentication for high-risk actions | Implemented | Implemented | N/A | K O E | Execution | Step-Up | step_up_proofs issued on auth verify (magic link) and validated by context (auth.step_up + method/id + expiry + actor match); evaluation publish + L4 actions require valid proof | Auth work | roles-and-access-control.md |
| Ledger-Derived Reporting | Reports from snapshots, not live joins | Implemented | Implemented | N/A | K O E | Execution | Snapshot | Reporting models built from submissions with async projection jobs (submission/range/remediation/telemetry); coverage includes summary, question-health, and range-backfill smokes (backend/tests/test_reporting_all.sh) | — | architecture |
| Execution Truth Canon | Ledger is final source of history | Implemented | Implemented | N/A | K O E | Execution | All | Enforced by architecture | — | FOUNDATION.md |
| Idempotent Writes (Keyed) | Prevent duplicate execution writes | Implemented | Implemented | N/A | K O E | N/A | Consistency | idempotency_keys now protects all targeted durable/admin write surfaces: sessions; assignments; users/roles/groups/import; subjects/import; submissions/evidence/approval/hash/void/subject-links; claims/disputes; engagements; remediation create/apply/revert; compliance job creation; evaluation + bucket authoring (including feedback/sections/items); question + passage authoring; programme administration; reporting projection/percentile maintenance. Smoke coverage includes backend/tests/admin_idempotency.sh, backend/tests/authoring_idempotency.sh, backend/tests/programmes_idempotency.sh, backend/tests/reporting_idempotency.sh, backend/tests/results_remediation_idempotency_key.sh, backend/tests/compliance_idempotency.sh, and backend/tests/engagements_idempotency.sh. | — | FOUNDATION.md |
| Delegated Authority Provenance | Record acting-on-behalf relationships | Implemented | Implemented | N/A | K O E | Execution | Provenance | Authority context accepted on submissions + evidence decisions; remediation batch create/apply/revert writes authority context into compliance ledger outbox metadata; defensibility smoke validates submission approval + remediation authority context | A1, A3 | FOUNDATION.md |
| Visibility Events | Capture view/export/client-access events | Implemented | Implemented | N/A | K O E | Execution | Visibility | View/export events emit visibility metadata (visibilityType, visibilityChannel); Glass Box access treated as visibility event; evidence access logged on submission view when evidence is present; subject list/detail reads logged; assignment link redeem logs visibility; programme/engagement list/detail/timeline/glass-box reads logged; enrolment list/detail/progress/user reads logged | A1 | FOUNDATION.md, architecture |
| Retention Intent Markers | Retain/hold metadata on records | Implemented | Implemented | N/A | K O E | Execution | Retention | Submission-level retain_until/retention_basis/hold_flag markers added; defaults now derived from active retention_policies on submit | Compliance | FOUNDATION.md |
| Enforcement Mode Declaration | Capability enforcement modes (mandatory/optional/situational/future) | Implemented | Implemented | N/A | K O E | N/A | Enforcement | Enforcement mode registry seeded in defensibility_enforcement_modes | FOUNDATION, Scorecard | FOUNDATION.md |
| Identity & Attribution (Actor vs Subject) | Separate subject-of-record from actor identity | Implemented | Implemented | N/A | K O E | Execution | Attribution | Subject/asset scaffolding + assignment subjects auto-link to submissions at submit-time; manual submission subject links remain | Subjects | docs/implementation/observational-implementation.md |
🟧 Section B — Primary Platform Capabilities (First-Class)
These are core product features built on top of the ledger.
| Capability | Description | Backend | Workflow | Frontend | K/O/E | WORM Scope | Defensibility Controls | Implementation Notes | Dependencies | Source Docs |
|---|---|---|---|---|---|---|---|---|---|---|
| Knowledge Delivery (K) | Structured question-based execution | Implemented | Implemented | Deferred (by design) | K | Execution | Snapshot | Strong backend maturity | — | KOE-model.md |
| Observation Delivery (O) | Structured capture of observed work | Implemented | Implemented | Deferred (by design) | O | Execution | Context | Findings enforcement live (comment/evidence) with finding.detected ledger events; approval endpoints include approve/reject/request-changes/reopen with approval_status transitions; four-eyes enforced via evaluation version reviewPolicy; auto-approve supported via autoApprove; submission subjects + assignment subjects links in place; batch_id copied into submissions | Context rules | KOE-model.md |
| Observation Findings | Defects / issues logged during O | Implemented | Implemented | Deferred (by design) | O | Execution | Append-only, Context | finding.detected ledger events + reporting.report_findings projection (with ledger_event_id); evidence/comment required before approval; reporting exposes /reporting/findings?submissionId=... for claims/disputes linkage | Observation Delivery | docs/implementation/observational-implementation.md |
| Claims / Assertions | Durable professional verdicts | Implemented | Partial | Deferred (by design) | K O E | Execution | Append-only, Snapshot | Claim objects + sources (submission/submission item/ledger event) + authority/context stored; L4 sources require full verification context; validity windows enforced (valid_from/valid_until + expiry without deletion) + validAt list filter + validityStatus response; list/get/create + event append live; lifecycle events (asserted,amended,withdrawn,voided,note) with status updates | A1, A3, A8 | docs/implementation/implementation-phasing-and-maturity-plan.md |
| Dispute Lifecycle | Formal challenge/response containers | Implemented | Partial | Deferred (by design) | K O E | Execution | Append-only, Audit | Dispute containers + event stream (opened, challenge, response, resolution, withdrawn, note); L4 targets require context on creation/events; status derived via events; list/get/create + event append + event list live; UI and dispute review workflow pending | Claims / Assertions | docs/implementation/implementation-phasing-and-maturity-plan.md |
| Subjects (People/Assets) | First-class subjects of record | Implemented | Implemented | Deferred (by design) | O | Scaffolding | reference | Subjects/asset schema + CRUD + import/filter APIs + submission subject links live with org/tenant scoping; assignment-based visibility implemented via assignment_subjects + assignment target read policy; multi-subject assignment linking supported | Observation Delivery | docs/implementation/observational-implementation.md |
| Evidence Delivery (E) | Artefact capture as execution events | Implemented | Implemented | Deferred (by design) | E | Execution | Context | First-class, ledger-bound, policy-driven; standalone + inline + mixed implemented; smokes upload to MinIO and ledger includes hashing + storage tier + storage-tier worker | Upload workflow | KOE-model.md, architecture, evidence-ledger-implementation.md |
| Inline Evidence | Evidence attached to K/O items | Implemented | Implemented | Deferred (by design) | K O | Execution | Context | Inline entry point with item-level ledger events; reuses evidence core | Evidence core | KOE-model.md, architecture, evidence-ledger-implementation.md |
| Mixed Evidence | Answer + evidence in same item | Implemented | Implemented | Deferred (by design) | K O E | Execution | Context | Mixed answer + artefact flow with item-linked ledger events | Evidence core | KOE-model.md, architecture, evidence-ledger-implementation.md |
| Standalone Evidence | Evidence as primary task output | Implemented | Implemented | Deferred (by design) | E | Execution | Context | Submission with zero items + ledger decisions | Evidence core | KOE-model.md, architecture, evidence-ledger-implementation.md |
| Evidence Integrity Verification | Hash checks against stored artefacts | Implemented | Implemented | Deferred (by design) | K O E | Execution | Integrity | evidence_integrity_checks queue + worker; on-demand enqueue via /submissions/\{id\}/evidence/verify (or item route) writes evidence.integrity.checked ledger events | Evidence core | implementation-phasing-and-maturity-plan.md, evidence-ledger-implementation.md |
| Assignments | Issue executable tasks | Implemented | Partial | Deferred (by design) | K O E | Scaffolding | Snapshot | Core issuance + redeem + monitor + override + schedules are live (POST /assignments, POST /assignments/redeem, GET /assignments/\{id\}/monitor, POST /assignments/\{id\}/override, POST /assignments/schedules) with validity windows (validFrom, validUntil) and durable override records. Command-centre monitor label mapping is now explicit for frontend consistency: backend `invited | started | completed |
| Delivery Sessions | Runtime execution window | Implemented | Partial | Deferred (by design) | K O E | Scaffolding | N/A | Session create/answer/submit + event/probe APIs are live (POST /evaluations/\{id\}/sessions, POST /evaluations/\{id\}/sessions/\{sessionId\}/answers, POST /evaluations/\{id\}/sessions/\{sessionId\}/submit, POST /evaluations/\{id\}/sessions/\{sessionId\}/events, GET /evaluations/\{id\}/sessions/\{sessionId\}/lockdown/probe) and remain non-durable runtime state. UX gap now tracked: explicit proctor command contract (pause/resume/terminate with normalized reason/metadata semantics) is not yet a first-class backend action surface. | Assignments + proctor command contract | FOUNDATION.md, UX-OPERATIONS.md |
| Programmes | Reusable execution templates | Implemented | Implemented | Deferred (by design) | K O E | Scaffolding | Snapshot | Well-implemented | — | architecture |
| Engagements / Projects | Instance-level execution thread | Implemented | Implemented | Deferred (by design) | K O E | Scaffolding | reference | Core tables + timeline + glass-box feed in place; lifecycle guardrails block assignment/session starts when engagement is not open; programme enrolments now accept engagementId so orchestrated assignments inherit engagement context and submissions persist it end-to-end (TestProgrammeProgressLifecycle, backend/tests/engagements_programme_linkage.sh) | Programmes | architecture |
| Client Glass Box | Read-only execution visibility | Implemented | Partial | Deferred (by design) | K O E | Projection | Snapshot | Backend lenses (assignment/submission/engagement/programme) + link-principal auth are implemented with scope-id enforcement, read-only middleware, amendment history, and normalized verification summaries (not_required for L1/L2). Coverage includes integration tests (TestGlassBoxAssignmentLinkPrincipal) and smoke suite (backend/tests/test_glassbox_all.sh, including backend/tests/glassbox_engagement.sh). Remaining gap is frontend glass-box views. | Engagements | architecture, glass-box-implementation.md |
| Role & Capability Engine | Permission enforcement | Implemented | Implemented | N/A | All | N/A | Authorization | Capability-based | — | roles-and-access-control.md |
| Magic Link Access | Low-friction access | Implemented | Implemented | N/A | All | N/A | Auth | Viewer tier exists | — | roles-and-access-control.md |
KOE Primitive Consistency Map (Phase A Consumption)
| KOE Capability | Phase A Primitives Consumed |
|---|---|
| Knowledge Delivery (K) | A1 Lifecycle, A2 Snapshots, A3 Amendments, A4 Authority, A5 Visibility, A7 Enforcement, A8 Identity & Attribution |
| Observation Delivery (O) | A1 Lifecycle, A2 Snapshots, A3 Amendments, A4 Authority, A5 Visibility, A7 Enforcement, A8 Identity & Attribution |
| Evidence Delivery (E) | A1 Lifecycle, A2 Snapshots, A3 Amendments, A4 Authority, A5 Visibility, A7 Enforcement, A8 Identity & Attribution |
Proof Runs (Consistency Evidence)
| Proof Run | Primitives Exercised |
|---|---|
backend/tests/test_delivery_all.sh | A1, A2, A5, A6 |
backend/tests/test_observations_all.sh | A1, A3, A8 (subjects visibility + batch_id + findings gating) |
backend/tests/evidence_ledger_events.sh + backend/tests/evidence_standalone.sh + backend/tests/evidence_inline.sh | A1, A3, A5, A6, A7 |
backend/tests/test_defensibility_all.sh | A4, A6, A7 |
backend/tests/test_glassbox_all.sh | A2, A5 |
backend/tests/test_hashing_all.sh | A2, A6 |
backend/tests/test_reporting_all.sh | A2 |
🟨 Section C — Supporting & Enabling Capabilities
Important for adoption and usability, but not defining truth. Frontend deferrals in this section are intentional while backend contracts and primitives are hardened.
| Capability | Description | Backend | Workflow | Frontend | K/O/E | WORM Scope | Defensibility Controls | Implementation Notes | Dependencies | Source Docs |
|---|---|---|---|---|---|---|---|---|---|---|
| Offline Capture | Execute without connectivity | Planned | Planned | Deferred (by design) | O E | Scaffolding | Sync rules | Full spec exists | Sync API | offline-delivery-implementation.md |
| Offline Sync | Batch submit execution events | Planned | Planned | Deferred (by design) | O E | Scaffolding | Integrity | Requires batch endpoints | Ledger API | offline-delivery-implementation.md |
| Smart Paste | Structured paste for authoring | Planned | Planned | Deferred (by design) | N/A | N/A | N/A | Spec exists | authoring pipeline | smart_paste_feasibility_updates_addendum_v_1.md |
| Structured Error & Validation Contract | Stable API error semantics for localisable UX flows | Partial | Partial | Deferred (by design) | All | N/A | Consistency | Platform already emits stable top-level error envelopes (code, message, optional details) and domain-specific status/reason enums. Remaining work is cross-surface field-error normalization + warning/error contract alignment for authoring and operations workflows so UI can localise and gate actions consistently without parsing raw strings. | Shared error schema + endpoint contract tests | STATUS-AND-READINESS-CONTRACT.md, UX-SHARED-COMPONENTS-CONTRACT.md |
| Bulk Import | Users, assignments, content | Partial | Partial | Deferred (by design) | N/A | N/A | N/A | CSV preview/commit import is live for users, subjects, assignments, and authoring content (POST /users/import/preview, POST /users/import/commit, POST /subjects/import/preview, POST /subjects/import/commit, POST /assignments/import/preview, POST /assignments/import/commit, POST /questions/import/preview, POST /questions/import/commit, POST /passages/import/preview, POST /passages/import/commit, POST /evaluations/import/preview, POST /evaluations/import/commit) with keyed idempotent commit semantics on commit endpoints. Preview response shapes are now normalized (valid/errors always arrays, never null) across import surfaces, with smoke assertions tightened to assert array types and counts. CI guardrail scripts/check_openapi_import_preview_shapes.sh now enforces required valid/errors/total contract fields in OpenAPI preview schemas. Smoke coverage: backend/tests/users_import_idempotency.sh, backend/tests/observation_subjects_import.sh, backend/tests/observation_subjects_import_idempotency.sh, backend/tests/bulk_import_content_types.sh, backend/tests/assignments_import_idempotency.sh, backend/tests/questions_import_idempotency.sh, backend/tests/passages_import_idempotency.sh, backend/tests/evaluations_import_idempotency.sh (authoring suite includes question/passage/evaluation import smokes). | Import engine | Product docs |
| Domain-Scoped Taxonomy Engine | Controlled taxonomy with domain separation | Partial | Partial | Deferred (by design) | N/A | N/A | N/A | Backend taxonomy foundation is live with facets/terms, retire/restore, where-used counts, content assignment endpoints for questions/evaluations, hierarchy primitives, and inventory taxonomy filters. taxonomy_term_relations provides relation-first parent/child links with strict-tree default and cycle rejection; read lineage endpoints are available (GET /api/v1/taxonomy/terms/\{id\}/children, GET /api/v1/taxonomy/terms/\{id\}/ancestors). Inventory list surfaces now support taxonomy filters (terms_any, terms_all, optional include_descendants) on questions and evaluations. Domains remain explicitly separated (content, skills, subjects, identity) with RLS and content-domain assignment enforcement. Submission version_snapshot now freezes taxonomy references (evaluationTaxonomyTermIds, questions.{questionVersionId}.taxonomyTermIds) for defensible reconstruction. Cross-domain mapping foundation is now in place with versioned mapping sets/rules and resolver APIs (POST /api/v1/taxonomy/skill-mapping-sets, POST /api/v1/taxonomy/skill-mapping-sets/\{id\}/versions, POST /api/v1/taxonomy/skill-mapping-sets/\{id\}/versions/\{versionId\}/publish, GET /api/v1/taxonomy/skill-mappings/resolve). Capabilities taxonomy.read / taxonomy.manage are active. OpenAPI publication is in place for taxonomy endpoints. Remaining gap (parked while authoring hardening is prioritized): bind resolver output into skills projection workers/outcomes with persisted mapping-version provenance facts. | Inventory APIs + mapping-resolution -> skills projection integration (parked) | content-library-approach.md, taxonomy-engine-evolution-proposal.md, COMPONENT-INTERACTION-MAP.md |
| Content Library Hardening Programme | Multi-phase hardening of inventory and packs | Partial | Partial | Deferred (by design) | K O E | N/A | N/A | Milestone 1 (terminology alignment) completed. Inventory hardening phase 1 (richer filters/sort) completed. Taxonomy foundation phase (domain-scoped backend primitives) completed. Inventory hardening phase 2 saved-filter slice is now live with shared inventory-view engine + paired question/evaluation endpoints. Lifecycle parity increment is now live with explicit archive/restore endpoints on both inventories. Soft-delete harmonization increment is now live for question delete fallback (question_in_use -> archive). Collection presets/taxonomy conventions increment is now live via canonical inventory-view filter schema + preset keys (status.*, taxonomy.focus) with taxonomy descendants conventions. Bulk metadata actions parity is now live via paired bulk endpoints (POST /questions/bulk, POST /evaluations/bulk) supporting archive, restore, and taxonomyReplace with dryRun + per-item outcomes. Dependency/where-used graph parity is now live via paired usage endpoints (GET /questions/\{id\}/usage, GET /evaluations/\{id\}/usage) with structured dependency blocks. Normalized readiness/status projection contract enforcement is now live (shared canonical status/reason taxonomy + response contract tests + CI OpenAPI drift guardrail). Packs lineage read slice is now live (GET /content-packs/\{id\}/revisions/\{revisionId\}/lineage) including install chain + submission snapshot linkage metrics. Planned next now explicitly includes publish-propagation orchestration (publish + guided propagation impact model with active-run safeguards), granular saved-view sharing ACLs (named user/group grants beyond personal/shared), and packs workflow expansion on top of lineage read surfaces. Parity rule: where capabilities apply to both Questions and Evaluations, backend delivery is paired by default unless an explicit documented exception exists. | Taxonomy + inventory roadmap execution | content-library-approach.md, STATUS-AND-READINESS-CONTRACT.md, UX-AUTHORING.md |
| Compliance Case Orchestration | Case-level legal workflow over async privacy jobs | Partial | Partial | Deferred (by design) | All | Scaffolding | Audit, Verification | Compliance Centre v1 backend is live for jobs/ledger/actions (/api/v1/compliance/jobs, /api/v1/compliance/forget, /api/v1/compliance/restrict, /api/v1/compliance/dsar-export, /api/v1/compliance/privacy-pack, /api/v1/compliance/unlink, /api/v1/compliance/ledger, /api/v1/compliance/retention/incidents). Missing UX-aligned backend layer now tracked: first-class request/case entity, case timeline projection, DSAR extension-notification enforcement, review/redaction stage tracking, and structured deny/partial legal-basis outcomes. | Compliance jobs + ledger + case projection model | compliance-centre.md, compliance-centre-v1-handover.md, UX-GOVERNANCE-COMPLIANCE.md |
| Proof Readiness & KOE Status Lens | Derived, explainable operator-facing status across submission, engagement, programme, and glass-box lenses | Partial | Partial | Deferred (by design) | K O E | Projection | Snapshot, Context, Verification, Step-Up | Contract defined for dual-time readiness (defensibleAtExecution vs readyNow), explainable KOE/readiness reason codes, capability-based redaction, and a triage-friendly exceptions queue (state, owner, firstSeenAt, lastSeenAt, suppressedUntil). Phase 1 backend rollout is live for submission surfaces: canonical derived koeStatus + proofReadiness blocks now emit on core submission DTOs (GET /submissions/\{id\}, user/evaluation submission lists) and glass-box submission detail (GET /glass-box/submissions/\{id\}) with stable reason-code unit coverage and shared OpenAPI schemas. Phase 2 increment now wires dual-time policy refs on submission detail, submission lists, and glass-box detail (policyRefExecution, policyRefCurrent) using execution snapshot verification policy vs current active-version policy, with batched list-policy lookup by submission IDs (no N+1) and policy_requirements_tightened when readyNow is stricter. Phase 3 increment enforces reason redaction for link-principal glass-box submission responses by default, with explicit token capability override (canViewReadinessReasons=true) and integration/smoke contract coverage proving internal detail/list surfaces retain full reasons while glass-box defaults remain redacted. Phase 4 queue scaffold is live for submission lens: derived queue read + triage endpoints (GET /defensibility/exceptions/submissions, POST /defensibility/exceptions/submissions/{submissionId}/triage) plus explicit lifecycle refresh automation (POST /defensibility/exceptions/submissions/refresh) that upserts active exceptions and resolves cleared items while preserving triage ownership/suppression semantics. Phase 5 rollup increment is now live with engagement/programme exception rollup read surfaces (GET /defensibility/exceptions/engagements, GET /defensibility/exceptions/programme-requirements) including aggregated reason codes and affected-submission counts, and refresh sync now manages lifecycle state across submission, engagement, and programme lenses in one pass. Phase 6 now adds independent rollup triage writes (POST /defensibility/exceptions/engagements/{engagementId}/triage, POST /defensibility/exceptions/programme-requirements/{programmeRequirementId}/triage) so operators can acknowledge/suppress at each lens without mutating execution truth. Phase 7 adds persisted verification-policy snapshot versioning beyond raw level (version_snapshot.verificationPolicy.policyRef + policy profile fields) and readiness refs now prefer snapshot-captured policy refs with profile-based current-policy refs for dual-time defensibility reconstruction. Phase 8 now centralizes canonical status/reason taxonomy in a shared backend contract package and enforces it across readiness + exceptions responses with unit/integration contract coverage and tighter OpenAPI enums. Remaining gaps are now workflow-facing (lens-specific action UX), not missing backend policy snapshot provenance. | Canonical reason taxonomy + policy version refs + projection tables + redaction enforcement + contract tests | STATUS-AND-READINESS-CONTRACT.md, KOE-model.md, architecture |
| Question Library (Inventory & Management) | Organize and manage question assets | Partial | Partial | Deferred (by design) | K O E | N/A | N/A | Backend inventory management is live through question and passage authoring surfaces: list/get/filter (GET /questions, GET /questions/\{id\}, GET /passages, GET /passages/\{id\}), metadata lifecycle (POST/PATCH/DELETE /questions/\{id\}, POST /questions/\{id\}/archive, POST /questions/\{id\}/restore, passage CRUD), version lifecycle (POST /questions/\{id\}/versions, POST /questions/\{id\}/publish), and passage/question linkage (PUT /passages/\{id\}/questions). Question delete now follows in-use safety semantics (409 question_in_use + archive fallback) instead of FK-error behavior when referenced by authored/execution records. Question inventory supports richer filters/sort in list APIs (status, full-text query, qtype, contributes-to-score, created/updated sorting) plus taxonomy-term list filters (terms_any / terms_all, optional include_descendants). Taxonomy term assignment is available via /api/v1/taxonomy/questions/\{id\}/terms. Saved-filter views (virtual folders) are now live via /api/v1/questions/views and /api/v1/questions/views/{viewId} with personal/shared visibility and canonical filter conventions (including preset keys + taxonomy descendants semantics). Bulk actions are now live via /api/v1/questions/bulk (archive, restore, taxonomyReplace, dryRun). Usage/where-used graph is now live via /api/v1/questions/\{id\}/usage including authored evaluation references and passage link references. Remaining gaps: granular saved-view sharing ACL (named user/group grants) and packs-linked lineage exposure where applicable. | authoring model + taxonomy foundation | question-library-mvp.md, content-library-approach.md, UX-AUTHORING.md |
| Evaluation Library (Inventory & Management) | Organize and manage evaluation assets | Partial | Partial | Deferred (by design) | K O E | N/A | N/A | Backend inventory management is live through evaluation authoring surfaces: list/get/create/update/delete (GET/POST /evaluations, GET/PATCH/DELETE /evaluations/\{id\}, POST /evaluations/\{id\}/archive, POST /evaluations/\{id\}/restore), version lifecycle (GET/POST /evaluations/\{id\}/versions, POST /evaluations/\{id\}/versions/\{versionId\}/publish, GET /evaluations/\{id\}/versions/active), structure management (sections/items/buckets), and quality tooling (POST /evaluations/\{id\}/validate, POST /evaluations/\{id\}/preview, GET /evaluations/\{id\}/usage). Evaluation inventory supports richer filters/sort in list APIs (search, status, created-by owner facet, created/updated/title sorting) plus taxonomy-term list filters (terms_any / terms_all, optional include_descendants). Taxonomy term assignment is available via /api/v1/taxonomy/evaluations/\{id\}/terms. Saved-filter views (virtual folders) are now live via /api/v1/evaluations/views and /api/v1/evaluations/views/{viewId} with personal/shared visibility and canonical filter conventions (including preset keys + taxonomy descendants semantics). Bulk actions are now live via /api/v1/evaluations/bulk (archive, restore, taxonomyReplace, dryRun). Usage/where-used graph now includes dependency details on /api/v1/evaluations/\{id\}/usage (assignments, programme requirements, content pack items) in addition to in-use counts. Remaining gaps: granular saved-view sharing ACL (named user/group grants) and packs lineage/provenance expansion workstream. | authoring model + taxonomy foundation | evaluation-library-roadmap.md, content-library-approach.md, UX-AUTHORING.md |
| Content Packs (Published Revisions + Install) | Reusable bundles of approved evaluation versions | Partial | Partial | Deferred (by design) | K O E | N/A | Snapshot | Backend pack curation is live with keyed idempotent writes for create/update/detail/list + item add/update/delete/reorder + publish revision snapshot + install (GET/POST /content-packs, GET/PATCH /content-packs/\{id\}, POST /content-packs/\{id\}/items, PATCH/DELETE /content-packs/\{id\}/items/\{itemId\}, POST /content-packs/\{id\}/publish, POST /content-packs/\{id\}/revisions/\{revisionId\}/install). Packs provenance read surface is now live for revision lineage (GET /content-packs/\{id\}/revisions/\{revisionId\}/lineage) exposing revision->item->source version->install chain with submission snapshot linkage metrics (submissionCount, snapshotLinkedSubmissionCount). Smoke coverage in backend/tests/content_packs.sh (wired into backend/tests/test_authoring_all.sh) now exercises publish/install plus lineage retrieval; integration coverage includes content_packs_lineage_integration_test.go. Next packs workstream: workflow expansion on top of lineage read surfaces. | Versioning + lineage model | library roadmaps, content-library-approach.md, STATUS-AND-READINESS-CONTRACT.md |
| White-Labeling | Branding per tenant | Planned | Planned | Planned | N/A | N/A | N/A | Commercial feature | Tenant config + theming metadata | white-labeling-roadmap.md |
| Localisation | Multi-language support | Partial | Partial | Deferred (by design) | All | N/A | N/A | Question payloads support locales + defaultLocale; question read surfaces support ?lang= projection (GET /questions/\{id\}, GET /questions) with projected version.payload + resolved/fallback version.locale, validated as BCP-47. Passage create/update normalize plain JSON into canonical localized envelope (defaultLocale + locales, default en) and passage reads support ?lang= projection with resolved-locale fallback. Additional projections now support lang for submission/reporting/glass-box snapshots, submission write response snapshots, and evaluation preview passage content (GET /submissions/\{id\}, GET /session-attempts/{submissionId}, GET /session-attempts/{submissionId}/export, GET /glass-box/submissions/\{id\}, POST /evaluations/\{id\}/sessions/\{sessionId\}/submit, POST /evaluations/\{id\}/preview). Localized snapshot responses now include localeProjection metadata (requestedLocale, fallbackUsed, servedLocales) to make projection/fallback behavior explicit. CI guardrail scripts/check_openapi_localization.sh protects OpenAPI contract + shared LangQueryParam; smoke coverage consolidated via backend/tests/test_localisation_all.sh (questions_crud.sh, passages_crud.sh, localisation_projection.sh). Planned UX/runtime layer: Inlang Paraglide-JS message keys everywhere (no hardcoded strings) plus capability-gated text override mode with precedence org override -> tenant override -> product default and auditable publish/rollback. | Locale strategy + override resolver + localization capability model | Product docs, UX-FRONTEND-CONVENTIONS.md, UX-SHARED-COMPONENTS-CONTRACT.md |
| Accessibility | WCAG / ATAG compliance | N/A | N/A | Planned | All | N/A | N/A | Backend-neutral (no server-side blockers). UX standard is WCAG 2.2 AA with explicit task-tier/mobile policy for field-heavy usage (Tier A mobile-safe, Tier C desktop-optimized with handoff). ATAG scope is now explicit for authoring/admin surfaces: objective A (accessible authoring UI) and objective B (support/preserve accessible authored output, including validation checks where content types support them). Screen-level interface guardrails are now documented across authoring, runtime, operations, review, insights, glass box, claims/disputes, identity/access, compliance, packs, and audit explorer UX specs. Planned guardrails are CI-enforced accessibility lint/compile gates, shared-component a11y checks, critical-flow a11y E2E checks, and release keyboard/screen-reader smoke gates. | Frontend CI guardrails + shared component test harness + critical-flow a11y test plan + authoring accessibility validation contract | FOUNDATION.md, architecture, UX-ACCESSIBILITY-STANDARDS-AND-GUARDRAILS.md, UX-MOBILE-AND-TASK-TIER-POLICY.md, UX-AUTHORING.md, UX-CHECKLIST.md |
| Frontend Contract & Shared Primitives Foundation | Deterministic cross-surface client behavior and reusable UI contract building blocks | Implemented | Planned | Planned | All | N/A | N/A | Backend contract maturity is now sufficient to activate frontend contract layer + shared primitives as first build step (status mapping, idempotency/CSRF handling, canonical drawer/link/table/status-chip semantics). Tracked as prerequisite for every frontend surface to avoid per-page fetch/state drift. | Frontend contract module + shared shell implementation + readiness P0 gates | frontend-implementation-status-matrix.md, UX-FRONTEND-READINESS-CHECKLIST.md, UX-SHARED-COMPONENTS-CONTRACT.md |
| Candidate Delivery Field Resilience UX | Preserve safe completion in low-connectivity/unstable-runtime conditions | Partial | Planned | Planned | K O E | Scaffolding | Integrity, Verification | Runtime API baseline is implemented; explicit field resilience UX (autosave/reconcile/retry-safe submit, deterministic reconnect states, operator/candidate recovery guidance) is now tracked as a planned frontend differentiator and release gate before delivery rollout at scale. | Delivery runtime state model + offline/resilience policy + release device matrix | UX-RUNTIME-CANDIDATE-DELIVERY.md, UX-FRONTEND-READINESS-CHECKLIST.md, UX-MOBILE-AND-TASK-TIER-POLICY.md, offline-delivery-implementation.md |
| Defensibility Action Guidance | Convert readiness/KOE reason codes into explicit operator next actions | Partial | Partial | Planned | K O E | Projection | Snapshot, Context, Verification | Backend now emits stable reason-coded readiness/KOE blocks and triage queues; remaining gap is frontend/operator workflow guidance that maps reason codes to deterministic remediation actions without mutating execution truth. | Canonical reason taxonomy + readiness/exception surfaces + review/operations UX contracts | STATUS-AND-READINESS-CONTRACT.md, UX-INSIGHTS.md, UX-REVIEW-AND-APPROVAL.md, UX-OPERATIONS.md |
| Defensibility Exception Noise Controls | Keep high-volume exception queues actionable via triage hygiene and visibility controls | Partial | Partial | Planned | K O E | Projection | Snapshot, Context, Verification | Submission/engagement/programme exception queues and triage states are implemented (open, acknowledged, resolved, suppression windows, owner); planned frontend layer now tracks digest/SLA and suppression-hygiene UX so queues do not degrade into non-actionable noise. | Defensibility exception APIs + operations/insights queue UX + observability hooks | STATUS-AND-READINESS-CONTRACT.md, UX-OPERATIONS.md, UX-INSIGHTS.md, frontend-implementation-status-matrix.md |
| Translation Override Workspace | Capability-gated text override and publish workflow (org -> tenant -> product fallback) | Partial | Planned | Planned | All | N/A | N/A | Localization projection/fallback is live at API layer; explicit override workspace (edit/review/publish/rollback/audit trail) is now tracked as planned product capability so translations are editable without code deploys while preserving deterministic fallback behavior. | Localization resolver + capability model + auditable override store | UX-FRONTEND-CONVENTIONS.md, UX-SHARED-COMPONENTS-CONTRACT.md, UX-FRONTEND-READINESS-CHECKLIST.md, frontend-implementation-status-matrix.md |
🟦 Section D — Derived & Advanced Capabilities (Future)
These exist because the ledger exists.
| Capability | Description | Backend | Workflow | Frontend | K/O/E | WORM Scope | Defensibility Controls | Implementation Notes | Dependencies | Source Docs |
|---|---|---|---|---|---|---|---|---|---|---|
| Skills Inference | Derive skills from evidence | Planned (parked) | Planned (parked) | Planned (parked) | K O E | Derived | Traceability | Parked follow-ups after authoring hardening: persist skill outcome/provenance facts per submission (mapping_set_version_id, mapping_rule_id, source term IDs), add mapping binding resolution by tenant/org/programme/evaluation/version, expose explain APIs from persisted facts, and publish projection freshness/processing states so Insights can distinguish fresh/processing/stale/failed safely. | Ledger maturity + taxonomy mapping foundation | skills-and-competencies-TDD.md, taxonomy-engine-evolution-proposal.md, UX-INSIGHTS.md |
| Competency Profiles | Long-term capability views | Planned (parked) | Planned (parked) | Planned (parked) | All | Derived | Snapshot | UX target is clear (heatmap + evidence-basis explainability), but backend prerequisites are still outstanding: user-profile projection tables/read models, scope-chip metadata (mapping/eval/framework/run labels), recalculation job lifecycle surfaces, and deterministic explain payloads rooted in persisted skill evidence facts. | Skills inference + projection workers + explain contracts | skills-and-competencies.md, UX-INSIGHTS.md |
| State Hashing | Cryptographic state fingerprint | Implemented | Implemented | Deferred (by design) | All | Execution | Integrity | Engagement + submission state hash endpoints with ledger events | Engagements, Submissions | architecture |
| Ratification | Signed approval of state | Implemented | Implemented | Deferred (by design) | All | Execution | Step-Up | Engagement + submission + claim + dispute ratification append ratified ledger events with step-up + idempotency; smoke coverage includes backend/tests/engagements_ratification.sh, backend/tests/claims_disputes_ratification.sh, and backend/tests/test_hashing_all.sh | Hashing | architecture, glass-box-implementation.md |
| External LRS / xAPI | External evidence feeds | Planned | Planned | Planned | All | Projection | Snapshot | Future integration | Ledger | architecture |
🔒 WORM Scope Clarification (Explicit)
| Scope | Meaning |
|---|---|
| Execution | Append-only, permanent, defensible truth |
| Scaffolding | Mutable runtime or orchestration state |
| Derived | Computed from execution records |
| N/A | Does not store execution truth |
Only Execution-scoped data MUST follow WORM rules.
📌 Final Notes
-
This matrix is authoritative.
-
No feature may be implemented without being represented here.
-
No feature may violate Section A invariants.
-
Language remains intentionally broad; customer-specific terminology belongs in an alias layer, not core docs.
-
This file complements, but does not replace:
FOUNDATION.mdarchitectureroles-and-access-control.mdKOE-model.md