Skip to content

Addendum: what §5 changes, and the engine's answer to each

The parent assessment's fourteen verdicts stand. §5 changes five things and resolves one open question. The three residual ⟨TIM/JIMMY⟩ items are noted at the end; none blocks the input-path build.

A-1. R-2's bar is accepted: vocabulary, not accuracy

The engine accepts the bar as stated — a hand-raise is useful to the extent it names the failure in terms the client's regulator recognises — with the division of labour §5.2 itself specifies: the engine raises in triumvirate terms (requirement IDs, criterion IDs, source_refs into the instrument), and the adapter translates those raises into the regulator's vocabulary against the known-risk catalogue, which crosses as adapter-side content per B-4.

This is recorded as a drift-check pass worth naming: the client supplied the calibration corpus (ASQA's known-risk catalogues) and simultaneously kept it out of the gate. The engine's hand-raise taxonomy therefore needs to be complete and addressable — every raise carries the exact requirement it could not trace, at source_ref granularity — but never needs to speak ASQA. That is achievable by construction and is now a design input to R-2.

A-2. The two-lens rule is adopted as an engine-side output constraint

§5.1's distinction — principles of assessment govern the system's design; rules of evidence govern individual assessor judgements — becomes a standing constraint on everything the engine emits:

The engine operates at the first lens only. Its raises address material and tool design ("I cannot trace how this evidence item is assessable by any instrument in this job"), never a person, a judgement, or a learner's competence. No output field, phrase, or flag may be readable as a second-lens statement. This was already implied by never-sign (B-1 / FOUNDATION-01 §2); §5.1 sharpens it into a testable output rule, and the engine adopts it as such — it will appear in engine-side canon citing this crossing.

A-3. Q-C is answered; provenance renderability becomes contract surface

§5.4 supplies the acceptance test the parent assessment asked for: the Dec 2025 run bundle's provenance is sufficient iff the adapter can render it into Standard 1.3/1.5 evidence shapes (pre-use review records, contextualisation evidence, validation records) without engine fingerprints surfacing (B-3).

Consequence the engine accepts: the UCCO envelope's provenance schema is no longer an internal detail — it is contract surface, versioned with the API, complete enough for the adapter's rendering and stable enough to build evidence tooling against.

Question back (Q-A3): the adapter side's field-level requirements for those evidence shapes — what a rendered "pre-use review record" and "contextualisation evidence" artefact must contain, so the envelope's provenance schema can be verified complete against them before the contract freezes. The rendering is the adapter's; the engine only warrants the raw material is all there.

A-4. R-2 is recurring: accepted, with design consequences

§5.5's Standard 1.5 cadence (five-year floor, risk-triggered, whole scope of registration, outcomes feeding system changes) reframes diagnosis from a build-time gate to a standing service. The engine accepts, with three design consequences now binding on R-2's build:

  • Diagnosis reports are dated, versioned, and individually referenceable, so they can enter the client's validation evidence chain and be cited by later reports.
  • Re-diagnosis of the same material against the same triumvirate version is reproducible; against a newer triumvirate version it is diffable — "what changed since last validation" is the recurring workload's real question.
  • Volume assumptions shift from per-release to per-scope-per-cadence. That is a strategy-layer input (pricing, capacity) and is flagged across to STRATEGY-01, not resolved here.

One boundary note: §5.5's independent-validator requirement (TAE products) is a requirement on humans. The engine is not and cannot be a validator — it never signs — but its referenceable reports are inputs the independent human consumes. No engine change; recorded so no future session "helpfully" positions the engine as the validator.

A-5. The override economy is noted; one small requirement falls out

§5.2's point that a recorded override of a false alert is itself Standard 1.4 evidence strengthens the hand-raise model at zero engine cost. The one requirement it creates: every hand-raise carries a stable ID so the client's world-layer override records can point at exactly what was overridden. Adopted into R-2's design inputs.

A-6. Q-B4 resolved by relay ruling: conformer and gate, both sides

Ruled by Tim (relay, 2026-07-01, in-session): the sender conforms, the receiver verifies. The adapter/conformer lives client-side — holds all domain knowledge, translates, validates semantically, signs, and submits. The engine-side gate independently verifies conformance (structure, schema version, signature) before ingestion; malformed jobs bounce whole. Two independent checks of two different kinds, with the trust boundary exactly where the corporate boundary is (ADR-0003). Raw regulated corpus never leaves the client's jurisdiction; only the translated, hashed, signed triumvirate crosses.

Each side files its own record of this ruling citing this crossing, per FENCE-PROTOCOL-01 §4. One sub-question remains open at the relay: who authors and certifies adapter software (as distinct from who operates it) — a commercial term for the data-processing agreement, not a blocker for the input-path build.

Residual open items (⟨TIM/JIMMY⟩) — none blocking

  1. Hand-raise tolerance threshold — product calibration in the bench build; calibrates R-2's acceptance, not its design.
  2. Lived sign-off practice — colour on §5.3's instrument-anchored floor; no engine consequence expected (D-5 already stands).
  3. Performance-assessment experience — provider-side colour; informs the adapter's evidence rendering priorities, adapter-side when it lands.

Addendum complete. §5 changed five things; the engine accepted all five, adopted two as standing output rules, gained one question back (Q-A3), and the custody question closed by ruling. The parent's fourteen YESes stand. The crossing is answered.