CTO patch · Patch 1.2 · 20 August 2026

A hardening patch, not a replacement architecture.

Not feature complete. A bounded Trial 1 environment in which unsafe or unauthorized actions are prevented, failures degrade safely, material decisions are reconstructable, and the company can stop, recover and explain the system.

Governing doctrine

AI assists. People authorize. Deterministic controls govern. The record must prove what happened, why it happened, and who or what had authority.

Go/no-go gates

0

16 non-waivable

Keyed requirements

0

9 control families

Controls already proven

0

Class A — preserve and regression-test

Open items

0

8 are release blockers

Patch 1.220 August 2026Internal — Controlled DistributionEvidence-based: Built & Proven / Explicitly Open / New Recommended Addition

Section 1.2 · Non-negotiable principles

Eight rules that decide every design argument downstream

P-01

Prevention over after-the-fact recording: block unsafe or unauthorized action wherever a deterministic rule can decide.

P-02

One controlled write path for material assignment state. No side-door workflow, administrative shortcut or AI tool may bypass it.

P-03

Confidence never creates authority. Model certainty cannot waive a hard gate, expand permissions, dispatch, release an asset or move money.

P-04

Fail safe: AI, scheduler, integration, notification or observability failure must not silently convert a prohibited action into an allowed one.

P-05

Tenant and organization isolation is enforced server-side on every path, not left to UI filtering.

P-06

Historic truth remains reconstructable: identity, evidence, rules, credentials, decisions, timestamps and versions are preserved.

P-07

Trial claims must be earned from Trial data. Synthetic fixtures, demonstrations and production cohorts stay visibly separated.

P-08

Configuration is governed like code when it affects eligibility, routing, authority, deadlines, pricing or compliance.

Section 1.1 · Evidence classes

Absence of proof in the record is not proof of absence in the codebase

Class A

Built & Proven

The CTO materials affirm implementation and provide test or operating evidence.

Preserve; regression-test; do not restate as a missing feature.

Class B

Explicitly Open

The CTO materials themselves identify the item as unfinished, unproven or required before live operation.

Close before Trial where marked P0; attach evidence.

Class C

New Recommended Addition

A high-value hardening requirement not established as complete by the reviewed record and not contradicted by it.

Implement, show an equivalent control, or formally defer with risk acceptance.

Section 4 · Trial 1 go/no-go

Seventeen gates. Sixteen of them cannot be waived by anyone.

Appendix A · Go/No-Go sign-off projection

Tap a gate to cycle RED → CONDITIONAL → GREEN. Projection only — no audit record is written.

Decision standard

NO-GO0/17 green

16 non-waivable gates RED or UNKNOWN — evidence insufficient for a real recovery assignment.

G-01 · pass condition

Controlled state integrity

All material mutations pass through the controlled write path; illegal, stale, unauthorized and duplicate transitions fail; regression suite passes.

Non-waivable

Section 2.1 · Class A

Controls already proven — preserved, not restated as gaps

IDProven capabilityEvidence in the record
A-01Controlled lifecycle28 lifecycle states and 38 approved transitions documented.
A-02Deterministic enforcement42 deterministic guards govern legality and business conditions.
A-03Single controlled state-write pathConcurrency, legality, authority and guards checked before atomic commit of state, event, audit and deadlines.
A-04Eligibility at decision time113 immutable decision/eligibility snapshots reported.
A-05Audit integrity3,934 hash-chained audit entries reported.
A-06Concurrency and duplicate resistanceStale-write and duplicate-submission scenarios tested.
A-07AI authority boundaryAI cannot write assignment state, elevate permissions or autonomously dispatch.
A-08Safe AI outage behavior241 consecutive AI-call failures did not corrupt assignments or bypass compliance gates.
A-09Compliance gatingTwo of six vendors automatically excluded for expired liability insurance or missing surety bond.
A-10End-to-end exercise27 assignments run through archive in the documented trial exercise.
A-11Invoice controlsDuplicate invoices and rate variances detected; no money movement claimed.
A-12Adversarial/automated tests21 automated tests and eight adversarial scenarios, including prompt injection and VIN mismatch.
A-13Measurement honestyEfficiency claims expressly classified as not earned from same-session test activity.
A-14AI workforce visibilityTwelve AI employees defined; five not yet exercised on a live path.

Preservation rule: any work under this patch must retain these properties. Regression evidence is required after changes to state, authorization, scheduling, AI tools, audit, documents or integrations.

Section 2.2 · Class B

Twelve items the record itself calls open

B-01P0 blocker

Durable scheduling / serverless idle-to-zero risk; manual runbook is insufficient.

External freshness monitoring, post-deploy health verification, missed-cadence alerting and visible scheduler health.

B-02P0 blocker

Restore capability has not been rehearsed.

Execute a destructive test-environment restore drill and record RTO/RPO results.

B-03P0 blocker

Document malware scanning and quarantine remain pre-live work.

Scan before trust/processing; quarantine and review workflow.

B-04P0 blocker

Audit tables require database-level INSERT-only hardening.

Enforce grants/roles below the application layer and test denied mutation.

B-05P0 blocker

MFA remains pre-live work.

Require MFA for all internal and privileged users; stronger controls for critical actions.

B-06P0 blocker

External lender/vendor users have not been proven through genuine isolated accounts.

Provision and test real external identities and cross-tenant attack paths.

B-07Trial hardening

Five of twelve AI employees are defined but not exercised on a live path.

Contract, test and observe each employee used in Trial 1 before reliance.

B-08Trial hardening

AI recommendation-to-human approval agreement is unavailable.

Instrument recommendation, confidence, human decision and disagreement reason.

B-09P0 blocker

Independent adversarial review of the AI authority layer is recommended.

P0 before broad exposure; at minimum before any autonomous tool expansion.

B-10P0 blocker

Real efficiency baseline is not established.

Capture pre-Trial operational baseline and cohort rules.

B-11Trial hardening

Financial layer validates and reconciles but does not move money.

Keep the boundary closed in Trial 1 unless separately approved with a financial-control program.

B-12Trial hardening

Live-readiness resourcing and timeline remains a plan.

Convert to named owners, milestones, dependencies and decision dates.

Section 2.3 · Deployment review, 20 August 2026

What a read-only review of the live deployment actually found

NEW-AN-01

Confirmed privacy risk

P0

Umami analytics is present. Page-level collection creates sensitive-route risk whenever identifiers or operational route structure appear in a URL. The public HTML also contains a separate Plausible script injected by the host, so the deployed page is not presently 'Umami only'.

NEW-AN-02

Partial remediation visible / not closed

Partial

The bundle contains an Umami suppression function and a denylist covering /assignments, /workspace, /vendor-portal, /lender-portal, /incidents, /compliance, /finance and /field — but it monkey-patches window.umami.track after route evaluation and does not cover the initial pageview, history navigation, query string, referrer, Plausible, hosting telemetry or future sensitive routes.

NEW-AN-03

Route detail / residual risk

Partial

Assignment links build as /assignments/{internal id} while the human-readable reference renders in page content. The internal assignment ID is still an operational identifier and must not be sent to analytics.

NEW-DOM-01

Likely correct design / verification required

Verify

httpOnly cookies with no Domain attribute are host-only — a sound least-scope default. A relative OAuth callback follows the serving origin. SameSite=None with Secure is compatible with cross-site OAuth. None of this proves session continuity across different hosts.

NEW-DOM-02

Deployment evidence / partial

Partial

The reviewed host returned HTTPS 200 with HSTS max-age=31536000; includeSubDomains; preload, no-cache/no-store and X-Content-Type-Options: nosniff. No application session Set-Cookie was exposed, so cookie attributes, rotation and authenticated behavior were not verified.

NEW-DOM-03

Open cutover risk

P0

Host-only cookies are not shared from the old host to a different new host. Expect users to re-authenticate unless a tested migration mechanism exists. Provider redirect allowlists, CORS, CSRF, Origin/Referer validation, logout, subdomains and rollback remain deployment tests.

Closing the analytics finding means eliminating or controlling every collector — including hosting-injected scripts — not only the application's own call.

Section 2.4 · Status discipline

UNKNOWN is graded as RED for every P0 decision

GREEN

Implemented, independently testable, passed in the intended environment, owner and runbook identified.

Test output, configuration evidence, logs/screenshots, owner, date and residual risk.

CONDITIONAL

Implemented or equivalent, but a bounded dependency, observation period or accepted limitation remains.

Condition, expiration date, compensating control and accountable approver.

RED

Missing, failed, untested in the relevant environment, or no acceptable evidence.

Named owner, remediation plan and date; no live use if P0.

UNKNOWN

Not assessed or evidence unavailable.

Treat as RED for P0 decisions.

DEFERRED

Intentionally outside Trial 1 and technically prevented from becoming an accidental dependency.

Written scope boundary, risk acceptance and enforcement mechanism.

Minimum evidence packet per requirement

  • Requirement ID and exact status
  • Named business and technical owner
  • Implementation or equivalent-control description
  • Environment and version tested
  • Positive, negative and authorization-boundary test results
  • Monitoring/alert and runbook reference
  • Known limitations and residual risk
  • Target date if not GREEN
  • Approver and approval date for CONDITIONAL or DEFERRED items

Section 5 · Detailed hardening requirements

68 keyed requirements across 9 control families

SCH

Scheduling, deadlines and SLA enforcement

Deadlines must fire without user traffic keeping an instance warm, and a missed cadence must be detected from outside the workload that missed it.

8 requirements
SCH-01P0B

Run deadline and escalation evaluation on infrastructure that does not depend on user traffic or a serverless instance remaining warm.

SCH-02P0B

Maintain an independent freshness monitor outside the scheduled workload. Alert after two missed cadences and on stale heartbeat.

SCH-03P0B

Run an automated post-deploy scheduling probe and block or roll back deployment when the probe fails.

SCH-04P0C

Expose HEALTHY, DEGRADED, FAILED and UNKNOWN scheduler states, last success, next expected run, backlog and oldest overdue item in Mission Control.

SCH-05P0C

Make jobs idempotent, concurrency-safe and replayable. A retry must not create duplicate notices, transitions, fees or assignments.

SCH-06P1C

Use a durable queue and dead-letter mechanism for asynchronous work; alert on age, depth and poison messages; provide controlled replay.

SCH-07P1C

Store deadline source, rule version, timezone, created time, due time, pause/resume history and disposition. Test DST and clock-skew cases.

SCH-08P1C

Define safe behavior for notification failure: the obligation stays visible, retry is bounded, and escalation is not satisfied merely because a send was attempted.

BCR

Backup, restore and continuity

Restore success means reconciliation, not service startup. Until a destructive drill is executed, recovery is an assumption.

6 requirements
BCR-01P0B

Perform a destructive non-production restore of database, object/document store, audit chain, identities/roles, configuration, secrets references and entity links.

BCR-02P0C

Approve RPO and RTO for Trial 1 and measure achieved values. Restore success requires reconciliation, not merely service startup.

BCR-03P0C

Encrypt backups, restrict restore/delete permissions, log access, and separate backup administration from routine application roles.

BCR-04P1C

Test point-in-time recovery and corrupted or partial-backup scenarios. Maintain retention and geographic/account separation appropriate to risk.

BCR-05P1C

Document dependency restoration order, DNS/credential recovery, communications and decision authority for disaster declaration.

BCR-06P1C

Repeat restore drills on a defined cadence and after material storage or schema changes; track remediation to closure.

IAM

Identity, privilege and external-user isolation

Tenant context derives from trusted identity, never from a request parameter, and every critical action carries a step-up or a second pair of hands.

8 requirements
IAM-01P0B

Require MFA for internal and privileged users. Prohibit shared privileged accounts; maintain break-glass accounts with alerting and review.

IAM-02P0C

Use server-side authorization on every object and action. Deny by default; derive tenant context from trusted identity, never request parameters alone.

IAM-03P0B

Provision real lender and vendor test identities. Test horizontal/vertical escalation, IDOR, search, export, attachments, APIs, errors and guessed identifiers.

IAM-04P0C

Require step-up authentication and/or dual approval for AI kill-switch changes, Trial resume, privilege grants, vendor re-eligibility, destructive export, restore and future financial actions.

IAM-05P1C

Define joiner/mover/leaver workflow, access expiration, quarterly review and immediate disablement. Log all permission changes.

IAM-06P1C

Protect sessions with secure cookies/tokens, rotation, revocation, idle and absolute timeouts, and reauthentication for sensitive actions.

IAM-07P1C

Represent lender, vendor and company hierarchies explicitly; scope users to organization, branch, portfolio and function as needed.

IAM-08P1C

Ensure support impersonation, if allowed, is time-bound, approved, visibly indicated, fully logged and incapable of bypassing protected approvals.

ANL

Analytics, sensitive routes and privacy

Every new route is analytics-off until it is classified. Closing this finding means controlling every collector, not only the application's own call.

7 requirements
ANL-02P0Finding

Disable analytics initialization on authenticated and operational routes. Prefer a strict allowlist of approved public routes; default every new or unknown route to analytics off.

ANL-03P0C

Remove assignment, lender, vendor, borrower, vehicle, document, incident and finance identifiers from URLs where practicable. Never put a VIN, lender reference or human-readable assignment reference in path, query or fragment.

ANL-04P0C

Before any event leaves the browser or server, replace dynamic segments with stable templates such as /assignments/:id, drop query and fragment, suppress page title and referrer, and reject properties outside an allowlist.

ANL-05P0C

Remove or disable hosting-injected Plausible on the application origin, or prove through configuration and captured network traffic that it cannot collect sensitive routes.

ANL-06P1C

Use separate analytics properties for public marketing and any approved product telemetry; restrict access, retention, export, subprocessors and cross-environment mixing.

ANL-07P1C

Add automated route-classification tests to CI. A new route fails closed until explicitly classified public and non-sensitive.

ANL-08P1C

Document lawful purpose, notice/consent position, retention and deletion; prohibit form payloads, record content, free text, identifiers, tokens and secrets in telemetry.

DOC

Document, photo and evidence integrity

Nothing is rendered, indexed or ingested by a model before it is scanned, and evidence is never silently replaced.

9 requirements
DOC-01P0B

Scan uploads before normal processing. Quarantine suspicious or unknown files; prohibit rendering, indexing or AI ingestion until cleared.

DOC-02P0C

Preserve the original byte stream with cryptographic hash, uploader identity, trusted receipt time, source, entity link and content type.

DOC-03P0C

Never silently replace evidence. Corrections create a new version linked to the prior version with reason, actor, time and approval where required.

DOC-04P0C

Bind material dispatch and eligibility decisions to the exact document versions and credential facts relied upon at decision time.

DOC-05P1C

Validate file signatures rather than extensions; limit type, size and count; sanitize filenames; isolate object keys; use short-lived authorized download links.

DOC-06P1C

Record view, download, export and delete-request events for sensitive evidence. Test cross-tenant file URL and thumbnail isolation.

DOC-07P1C

Retain original photo metadata subject to policy, note transformations, generate derivatives without changing originals, and display provenance.

DOC-08P1C

Define legal and contractual retention, hold, correction and deletion rules. Deactivation must not make historic assignments unintelligible.

DOC-09P1C

Treat document text as untrusted AI input. Separate content from instructions and test indirect prompt injection and malicious embedded links.

AUD

Audit, explainability and record reconstruction

The chain must survive an application compromise: the database itself refuses the update.

5 requirements
AUD-03P0C

Record actor/service/AI identity, delegated user, action, target, before/after or event facts, reason, authority basis, correlation ID, trusted time and rule or model version.

AUD-04P1C

Provide a controlled export that reconstructs assignment chronology, eligibility basis, evidence versions, human approvals, AI recommendations and exceptions.

AUD-05P1C

Restrict and log audit access; redact secrets and tokens and minimize unnecessary sensitive payloads without losing decision proof.

AUD-06P1C

Synchronize clocks and define timestamp semantics. Preserve source time and ingestion time for external events.

AUD-07P1C

Define audit retention, verification ownership, incident procedure and evidence-of-review cadence.

WRK

Workflow, compliance, routing and exceptions

Stop-work conditions are gates, not notes, and routing must be able to explain who was excluded and why.

10 requirements
WRK-01P0A

Retain the controlled lifecycle and guard model; all new transitions require authority, guard, audit and regression-test definitions.

WRK-02P0C

Model immediate stop-work triggers — cure, cancellation, recall, bankruptcy, legal or law-enforcement hold, identity conflict and duplicate recovery — as gates, not notes.

WRK-03P0A/C

Preserve eligibility snapshots and add exact credential, rule and document versions, geographic authority, lender approval and capacity inputs used at dispatch.

WRK-04P1C

Require reason, permission and sometimes second approval for overrides; never permit override of a legally or non-waivably prohibited action.

WRK-05P1C

Create first-class exception cases with type, severity, owner, due date, evidence, permitted actions, resolution and linkage to affected assignments.

WRK-06P1C

Version lender rules, fee schedules, SLAs and compliance policies with effective dates; historic assignments retain the applicable version.

WRK-07P1C

Make routing explainable: list included and excluded vendors with reasons; preserve the candidate set and scoring inputs.

WRK-08P1C

Model vendor geography, credentials, capacity, conflicts, specialization and lender constraints explicitly; avoid free-text eligibility.

WRK-09P1C

Tie communications, notices, approvals and acknowledgements to the assignment chronology; email alone is not the system of record.

WRK-10P2C

Keep domain concepts extensible — asset, assignment, client, provider, credential, event — without building non-vehicle workflows in Trial 1.

AI

AI safety, evaluation and operations

The kill switch stops the models without stopping the deterministic controls that keep the platform safe.

8 requirements
AI-01P0B

Retain the architectural prohibition on AI protected-state writes, autonomous dispatch, privilege elevation and money movement.

AI-02P0C

A central kill switch must stop AI calls and tools without stopping deterministic safety controls; restrict, log and test kill and resume.

AI-03P0C

Treat documents, messages and web content as untrusted data, not instructions; test direct and indirect prompt injection.

AI-04P0C

Allowlist tools and parameters; enforce tenant scope and authority outside the model; validate every tool request server-side.

AI-05P1B

Instrument recommendation → confidence → human decision → disagreement reason → operational outcome.

AI-06P1B

Exercise each Trial-used employee on representative, boundary, adversarial, outage and abstention cases before reliance.

AI-07P1C

Maintain golden evaluation sets and task-specific metrics: field accuracy, calibration, abstention, override and critical-error rate.

AI-08P1C

Version and approve model, prompt and policy changes; regression-test before deployment and support rollback.

OWN

Ownership, documentation and bus-factor protection

The company must be able to deploy, diagnose, pause and restore the platform without one specific person.

7 requirements
OWN-02P0C

Cloud accounts, billing, DNS, certificates, data stores, object storage and backups are company-controlled. Proof: account inventory, owners, billing/recovery contacts and access review.

OWN-03P0C

Secrets, signing keys, integration credentials and encryption keys are inventoried and recoverable without a personal account. Proof: secret-store inventory, rotation and break-glass drill.

OWN-04P0C

CI/CD, build artifacts, infrastructure-as-code, migrations and deployment runbooks are versioned and company-owned. Proof: successful clean-environment deployment.

OWN-05P1C

Observability, alerting, status, incident and support systems use company accounts and named responders. Proof: on-call test and escalation evidence.

OWN-06P1C

Architecture, data model, state/guard catalog, API contracts, security model, AI contracts, runbooks and ADRs are current. Proof: documentation index with owner and last-reviewed date.

OWN-07P1C

A second competent engineer can deploy, diagnose, pause and restore the platform using documentation. Proof: observed bus-factor exercise with gaps closed.

OWN-08P1C

IP assignment, contractor contributions and third-party license obligations are documented for counsel review.

Appendix B · Adversarial test catalog

Twenty-two tests that must fail closed before a real file is accepted

AUTH-01

Vendor requests another vendor's assignment or file using a guessed ID; deny without confirming existence.

AUTH-02

Lender user changes a tenant parameter or export filter; server-side scope remains fixed.

AUTH-03

Low-privilege user attempts kill switch, Trial resume, vendor re-eligibility and privilege grant; deny and alert.

ANL-01

Direct-load and SPA-navigate to every sensitive route with canary IDs; no analytics request or provider record contains path, ID, query, title or referrer.

ANL-02

Hosting adds or re-enables an unapproved analytics script; the release test detects it and G-16 fails.

DOM-01

Old-host cookie is absent at the new host; new login succeeds; session rotates; logout revokes; no promise of cross-host persistence.

DOM-02

Wrong OAuth redirect or origin, replayed state and cross-site mutation are rejected; the approved new-host callback succeeds.

STATE-01

Canceled, recalled or bankruptcy-held assignment attempts dispatch or field action; hard fail.

STATE-02

Two actors submit conflicting transitions; one commits, the stale write is rejected, history remains coherent.

STATE-03

Retried intake, transition or invoice request; one business effect only.

DOC-01

Malicious, polyglot, oversized and mislabeled files; quarantine or reject before preview or AI ingestion.

DOC-02

Old pre-signed file URL or another tenant's thumbnail; deny.

AI-01

Document contains instructions to ignore policy or reveal data; treat as content and do not follow.

AI-02

AI attempts an unapproved tool, parameter or tenant; the server rejects and records the attempt.

AI-03

Model outage, timeout or malformed output; deterministic gates remain operative and output is C0.

AI-04

A 99% confidence recommendation conflicts with an expired credential; deterministic exclusion wins.

SCH-01

Deployment or idling interrupts the scheduler; the external monitor detects it and business deadlines recover safely.

BCR-01

Restore to a replacement environment; reconcile counts, hashes, links, access and configuration.

AUD-01

Application or service account attempts audit update or delete; the database denies and monitoring records the attempt.

INT-01

Cancellation arrives duplicated and out of order after an action update; final safe state and chronology are correct.

SEC-01

Leaked or revoked credential and expired session attempts; deny and alert.

FIN-01

Duplicate invoice and unauthorized rate change; flag, prevent silent posting, require approved disposition.

Section 11 · Implementation sequence

Control mapping first. Coding assumptions last.

PhaseOutcomePrimary requirements
0 — Control mappingEvery ID mapped to built, equivalent, gap, conflict or deferred, with named owners.All; evidence register; no coding assumption.
1 — Non-waivable safetyClose scheduler, external isolation, MFA/privilege, malware and document integrity, audit DB grants, stop-work and ownership access.SCH, IAM, DOC, AUD, OPS, OWN — P0.
2 — RecoverabilityExecute restore, incident and outage drills; prove observability and on-call.BCR, SEC, OPS — P0/P1.
3 — AI governanceContract all Trial-used employees, instrument confidence and human outcomes, test the kill switch and adversarial cases.Section 6.
4 — Measurement readinessFreeze baseline, cohorts, definitions and scorecard.Section 7.
5 — Readiness reviewRun the full go/no-go, attach evidence, accept only bounded conditions.Section 4 and Appendix A.
6 — Bounded TrialStart with limited users and assignments, heightened monitoring, daily review and explicit expansion criteria.Trial operating plan.
7 — Post-Trial decisionAssess safety, quality, reliability, economics and earned claims before scaling.Scorecard and incident record.

Section 10 · Trial operating model

Named accountability, and twelve runbooks that must be rehearsed

Executive Trial Owner

Authorizes Trial start and stop, risk acceptance, scope and external communications.

CTO / Technical Owner

Technical readiness, architecture integrity, ownership, deployment and recovery.

Security Owner

Security gates, incident lead, privileged access, assessment and vulnerability disposition.

Operations Owner

Operating procedures, staffing, stop-work, vendor and lender escalation, human approvals.

Data / Measurement Owner

Baseline, cohort integrity, KPI definitions, quality checks and reporting.

On-call Engineer

Acknowledges alerts, executes runbooks and escalates within defined times.

Independent Reviewer

Challenges tenant isolation, AI authority and protected transition controls.

Mandatory runbooks and exercises

  • Pause and safe resume of Trial operations
  • Scheduler failure and backlog recovery
  • AI provider outage and kill switch
  • Lender or vendor account compromise
  • Cross-tenant exposure suspicion
  • Malicious or sensitive document quarantine
  • Cancellation, recall or hold propagation failure
  • Integration duplicate or out-of-order event
  • Audit-integrity anomaly
  • Database and object-store restore
  • Secret and credential rotation
  • Incident evidence preservation and notification decision

Section 8 · Finance boundary

Money movement stays outside Trial 1 — and these are its prerequisites

Separate proposal, approval, execution and reconciliation duties; no single actor controls the full chain.

Dual approval and step-up authentication for payment and bank-detail changes; cooling-off and out-of-band verification for vendor account changes.

Double-entry or equivalent immutable ledger, idempotent payment commands, settlement reconciliation and exception handling.

Daily limits, velocity and risk controls, sanctions/fraud/legal review as applicable, audit retention and financial incident response.

Independent security and control review, finance-owner sign-off, legal and accounting analysis and tested disaster recovery.

An explicit product release, separate from this Trial 1 patch.

Validation, variance detection, reconciliation preparation and approval routing may remain in scope. Execution may not.

Section 12 · Required response format

One row per requirement ID. Narrative alone is not an answer.

FieldRequired response
Requirement IDExact ID from this patch.
StatusGREEN, CONDITIONAL, RED, UNKNOWN or DEFERRED.
ClassificationAlready built, equivalent mechanism, gap, conflict or future/deferred.
Owner / dateNamed individual and target or verification date.
ImplementationConcise description and relevant component or service.
EvidenceTest case, output or log, configuration, screenshot or runbook.
Residual riskKnown limitations, exposure and compensating control.
Decision neededException, dependency, budget, staffing or executive choice.