AT AlphaTest / Blueprint

Architecture decision record · integrator API · fail-closed contract

Certify every release fact before you send the first request.

For the AcmeTest maintainer: the independently captured 2026-07-17 spec-owner promotion and 20 unique public-owner/Content/CASE locators bind all 9 public rows to all 20 positive Content cells with 20-cell and 52-item count preservation. The demo-tenant source catalog is ready; a conforming authenticated mastery-gate request returns 202 and proceeds through live Content and CASE proof.

12 / 12
standard axes pinned
56
numbered ITDs
36
active decisions
0
silent coverage gaps allowed

Customer and job

The person this contract serves

Who: the engineer maintaining AcmeTest, an Edulastic-shaped thin app on Platform3.

Job: submit “grade 5 TX math, 20 items, DOK 2–3,” receive an assignable native test id and coverage proof, then hand that id to the existing QTI/administration flow without authoring items or translating identities.

Status quo to beat: hand-curated QTI banks in the app repository, with slow coverage expansion and no independently auditable rigor.

Ownership boundary

Thin where Platform3 is authoritative

Platform3 owns

  • Content: blueprint-of-record test_spec, list/detail identity, versions
  • CASE: standards, KCs, and associations
  • QTI: items, delivery, response scoring
  • OneRoster: people and classes
  • Results / Analytics: durable outcomes and mastery

AlphaTest blueprint owns

  • Request normalization and deterministic slot allocation
  • Tenant-scoped, 30-day crosswalk working evidence
  • Fail-closed coverage verification and orchestration state
  • No copied standards, private blueprint catalog, or remembered-id list

Predictable before client code

Accept → resolve → calibrate → prove → persist → read

  1. 1Authenticate the request Verify signature, expiry, role, exact blueprint scopes, and tenant before reading catalog content; invalid credentials never become a catalog-state error.
  2. 2Accept only a released catalog Validate the exact tenant source match, catalog hash, policy target, and a version-pinned owner binding manifest.
  3. 3Resolve live Read immutable source test_spec versions from Content and every standard/mapping from CASE.
  4. 4Bind public rows without inference Require every governed public row and every positive Content KC×DOK cell in the owner-approved manifest; preserve cell cardinality and total counts.
  5. 5Calibrate and prove Derive one literal 100-percent policy target per source, map every cell exactly once at equal-or-higher DOK, and fail before writes on any gap.
  6. 6Persist once Only after every release gate passes, create one Content item with content_kind=test_spec.
  7. 7Return native identity The released request returns 202 with a relative operation reference; ready exposes the unchanged Content id.
POST /v1/blueprintsGET ./operations/{id}GET /v1/blueprints/{content_test_spec_id}+GET …/coverage

Certification index

Every standard API axis is pinned

Only active ITDs govern this table. Superseded ITDs remain below as linked audit history.

AxisContractGoverning ITDState
Write granularityOne customer create plus one reports-only immutable calibration successor; no update/delete; bulk has a thresholdITD-006 · ITD-026 · ITD-045PINNED
Read shapeList, detail, coverage, operation, and calibration revision receipt; list is wire-faithfulITD-037 · ITD-027 · ITD-044 · ITD-045PINNED
Query modelVerified filter subset, opaque cursor, upstream orderITD-038PINNED
ConcurrencyImmutable ready specs, exact-base ordered calibration successors, replacement by supersession, ETag readsITD-009 · ITD-045PINNED
IdempotencyRequired tenant+route key; deterministic create and calibration-delta replayITD-010 · ITD-026 · ITD-045 · ITD-046PINNED
Auth shapeVerified JWT role maximum; authentication is request-scoped; a portable fail-fast two-slot bootstrap gates reviewer conformance evidence; reports-only calibration scopeITD-028 · ITD-045 · ITD-047 · ITD-056PINNED
EventingPolling and modifiedSince; webhook trigger is explicitITD-012PINNED
Error envelopeTyped RFC 9457 problems with stable precedenceITD-013PINNED
Tenant routingVerified JWT tenant only; no caller-selected tenantITD-014PINNED
Conformance evidenceReal CASE/Content traces plus a dated external approval event and 20 unique public-owner/Content/CASE binding locators; Results/Analytics traces govern later empirical revisions; credential preflight, binding mutations, and replay suites; mocks cannot releaseITD-015 · ITD-031 · ITD-035 · ITD-044 · ITD-045 · ITD-046 · ITD-054 · ITD-056PINNED
Privacy / retention30-day working evidence; upstream records remain upstreamITD-016PINNED
List endpointsOne Content-backed collection; no remembered-id indexITD-037 · ITD-038PINNED

One selector, one lifecycle

Kind-specific truth without separate products

SHIP

mastery_gate

Requires 1–50 immutable governed source assessment references, highest-rigor allocation, complete union coverage, and binary mastery criteria.

DEFERRED release

adaptive_diagnostic

Remains the same request value. Creation fails typed 422 until exact-tenant CASE discovery, owner-typed KC, and dereference facts independently reopen implementation; 202 → ready → Content readback is the subsequent release certification.

SHIP

formative

Requires a bounded unit standard set and immediate per-standard criteria through the same blueprint resource and operation lifecycle.

Audit-grade mechanism

“Superset” is a machine-checkable invariant

Required evidence row

source_key
 content_test_spec_id + content_version_id
 source CASE GUID + source DOK + item_count
target CASE GUID + association provenance
blueprint slot + required DOK

Ready iff every invariant holds

  • Both bracketing Content item reads return the catalog-pinned immutable version.
  • Every source and target CASE item dereferences; non-identity mappings have a real CASE association.
  • Unique KC×DOK cardinality and total item count are unchanged.
  • Every source cell maps exactly once and target DOK ≥ source DOK.
  • Only after all checks pass may the Content create occur.

Fail closed: omitted, duplicated, stale, ambiguous, count-changing, unverifiable, or lower-DOK rows fail the operation with zero target test_spec writes. No percentage threshold and no warning-only result can satisfy mastery-gate readiness. Identity detail

Perfect-score contract

Every named source has a literal, versioned target

Creation

  • The six-field caller source reference stays unchanged.
  • AlphaTest derives exactly one governed target for each source/version.
  • metric=equivalent_raw_score_percent, target_value=100, and relation=mastery_implies_at_least are mandatory.
  • Content passing_rule owns the targets; detail and coverage reads project them without reinterpretation.
  • A missing, ambiguous, non-100, mismatched, or non-dereferenceable target fails before Content write.

ITD-044 · complete target schema and semantics

Reports → revision

  • POST /v1/blueprints/{id}/calibration-deltas is reports-service only, same-tenant, idempotent, and exact-base ordered.
  • Native Results/Analytics evidence is dereferenced; no outcome or external score is copied into AlphaTest.
  • Success creates a new immutable Content test_spec linked by supersedes; history is never mutated.
  • Stale/conflicting deltas fail closed; any revision must preserve exhaustive equal-or-higher-DOK coverage and every 100-percent target.

ITD-045 · wire protocol and state machine

Reports delta + native evidence202 operationnew Content test_spec versionbefore/after revision receipt

Autonomous proof: deployed conformance rejects missing or invalid targets, replays one delta deterministically, rejects stale and conflicting deltas with zero writes, reads the immutable successor back, and compares pre/post target, coverage, criteria, evidence, and Content hashes. ITD-046 · mutation suite · machine-readable contract

Current release state: READY FOR DEMO-TENANT MASTERY-GATE CREATION. The schema-v6 catalog publishes the operator-approved STAAR 2024 and Iowa Level 11 inventories, their literal 100-percent policy targets, and manifest alphatest-public-inventory-bindings-2026-07-24.v2: 9/9 public rows, 20/20 positive Content cells exactly once, 20 unique evidence locators, 20 cells before/after, and 52 items before/after. Approval comes from the captured 2026-07-17 spec-owner event triage://decisions/2026-07-17-033, not this run. Catalog payload hash 6e23e29f806a20a72e80bd266d2143e4df1ae8c6ae40bbba615fa410a4483450 is ready and the exact authenticated governed create contract is 202 with an operation reference. Authentication remains fail-closed per request; the short-lived two-token bootstrap is required for conformance and isolation evidence but cannot turn a conforming demo request into 503 reviewer-credential-preflight-required. ITD-054 · released manifest · ITD-056 · ready catalog and auth boundary · non-circular authority record · binding evidence · credential evidence

Lifecycle integrity

Supersession chains

007037 wire-faithful reads

008034038 wire-verified filters

011047 complete customer plus reports-service authorization

017039041043 full three-kind truth and non-circular adaptive gate

029040 one-origin, mount-safe operation URLs

030035 immutable Content identity

032033036048050052054 governed sources with an approved exhaustive public-row binding manifest

042049051053055056 portable evaluator credentials with request-scoped auth and deterministic catalog readiness

Numbered decision corpus

All 56 ITDs

Search by axis, endpoint, registry key, or contract phrase. Every record has a stable permalink, lifecycle provenance, rejected alternatives, and rationale.

ITD-001

Systems of record

active
Status
active
Disposition
SHIP
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

Platform3 Content test_spec is the blueprint of record; CASE is the standards authority; AlphaTest stores only tenant-scoped crosswalk work and evidence references.

Alternatives rejected

  • Private blueprint tables
  • copied standards
  • Content write only after bank generation.

Why

One authoritative id removes translation glue and prevents drift while preserving AlphaTest's orchestration seam.

Registry key: blueprint_systems_of_record · Back to top

ITD-002

Asynchronous creation lifecycle

active
Status
active
Disposition
SHIP
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

Blueprint creation is an asynchronous operation returning 202; operation state is queued, resolving, persisting, ready, or failed, and ready contains the native Content test_spec id.

Alternatives rejected

  • Long synchronous POST
  • client-orchestrated CASE calls
  • optimistic ready response
  • documented 424 placeholder as the product.

Why

Live crosswalk and Content writes can outlast HTTP budgets, while the operation gives one predictable success lifecycle. Release waits for the real upstream seam rather than shipping an impossible example.

Registry key: blueprint_async_creation · Back to top

ITD-003

Three test kinds, one request

active
Status
active
Disposition
SHIP
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

A required test_kind selects mastery_gate, adaptive_diagnostic, or formative within one blueprint resource and one lifecycle.

Alternatives rejected

  • Separate APIs
  • implicit inference from length
  • a generic kind with free-form policy.

Why

One integration path preserves common provenance while kind-specific validation keeps each promise explicit.

Registry key: blueprint_test_kind_selector · Back to top

ITD-004

Fail-closed superset proof

active
Status
active
Disposition
SHIP
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

A mastery_gate reaches ready only when every source standard is mapped to at least one blueprint slot at equal-or-higher DOK with provenance; any uncovered or unverifiable row fails the operation.

Alternatives rejected

  • Coverage percentage threshold
  • warning-only gaps
  • manual attestation.

Why

“Superset” is a universal claim. A partial result cannot silently satisfy it.

Registry key: blueprint_fail_closed_superset · Back to top

ITD-005

Deterministic slot allocation

active
Status
active
Disposition
SHIP
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

Normalized request plus immutable CASE source revisions and policy version deterministically produce ordered blueprint slots, distributions, and criteria.

Alternatives rejected

  • LLM-selected allocations
  • unordered requirements
  • mutable “latest” provenance only.

Why

Audit replay and parallel-form equivalence need the same facts to yield the same plan.

Registry key: blueprint_deterministic_allocation · Back to top

ITD-006

Write granularity

active
Status
active
Disposition
SHIP per-resource create; DEFERRED bulk create
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

Ship one-blueprint POST backed by one atomic Content test_spec create; do not expose client update or delete. Bulk create is DEFERRED until one registered integrator must atomically commission at least 25 blueprints in one job.

Alternatives rejected

  • Fabricated local write
  • bulk-only
  • PATCH of ready specs
  • permanent 424 placeholder.

Why

Per-resource create serves the current AcmeTest job with no partial-success model, and the release gate preserves Content as the system of record.

Registry key: blueprint_single_write_granularity · Back to top

ITD-007

Read shape and collections

superseded
Status
superseded
Disposition
SHIP
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
ITD-037

Chosen

Ship blueprint list, blueprint detail, coverage subresource, and operation detail. Slots, standards, distributions, and policy remain embedded; no extra collections or local remembered-id index exist.

Alternatives rejected

  • Invented local projection
  • write-and-remember ids
  • every nested type as a collection
  • detail-only API that cannot recover prior work.

Why

The four reads cover discovery, polling, inspection, and audit while every durable blueprint fact still comes from Content and CASE.

Registry key: blueprint_read_shape · Back to top

ITD-008

Query model

superseded
Status
superseded
Disposition
SHIP
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
ITD-034

Chosen

GET /v1/blueprints supports test_kind, subject, grade, status, modifiedSince, created_at descending order, opaque cursor pagination, and page_size 1–100 default 25, translated to one tenant-scoped Content test_spec list call.

Alternatives rejected

  • Local index of remembered ids
  • tenant-wide catalog scan
  • offset paging
  • arbitrary query DSL.

Why

A bounded filter model supports recovery and incremental sync without creating a second catalog or unstable query language.

Registry key: blueprint_query_model · Back to top

ITD-009

Concurrency and immutability

active
Status
active
Disposition
SHIP
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

Ready blueprints are immutable; corrections create a new blueprint linked by supersedes; GET responses emit ETag and honor If-None-Match.

Alternatives rejected

  • If-Match PATCH
  • last-write-wins
  • mutable Content record in place.

Why

Evidence must continue to describe the exact blueprint used by a bank or attempt.

Registry key: blueprint_immutable_ready_specs · Back to top

ITD-010

Idempotency

active
Status
active
Disposition
SHIP
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

Idempotency-Key is required on POST, scoped to tenant plus route, retained 24 hours, and rejects key reuse with a different canonical body.

Alternatives rejected

  • Optional key
  • body hash alone
  • unlimited retention.

Why

Retries cannot commission duplicate expensive work, while mismatched reuse is visible.

Registry key: blueprint_idempotent_create · Back to top

ITD-011

Authentication and authorization

superseded
Status
superseded
Disposition
SHIP
Date
2026-07-16
Author
alphatest-loop
supersedes
none
superseded_by
ITD-047

Chosen

Every endpoint requires a verified Bearer JWT with sub, role, tenantId, iat, and exp. Roles reviewer and integrator have implicit blueprint:read and blueprint:write because both must replay the documented create contract inside their own tenant; an optional scope claim can only narrow that role maximum. POST requires blueprint:write, every GET requires blueprint:read, and neither role grants any student, roster, QTI, Results, or cross-tenant permission.

Alternatives rejected

  • Read-only reviewer token that cannot run the published POST
  • mandatory scope claim incompatible with the deployment reviewer JWT
  • API keys
  • unbounded role-only access
  • anonymous reads.

Why

The bounded role matrix makes the operator-minted reviewer token an executable contract credential, while tenant routing and optional scope attenuation preserve least privilege in this student-data-free module.

Registry key: blueprint_scoped_jwt_auth · Back to top

ITD-012

Eventing

active
Status
active
Disposition
SHIP polling + modifiedSince; DEFERRED webhooks
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

v1 uses operation polling plus modifiedSince list synchronization; webhooks reopen when a registered integrator demonstrates polling prevents completion of an assignment workflow or exceeds a documented rate budget.

Alternatives rejected

  • Webhooks at launch
  • polling only without incremental sync
  • server-sent events.

Why

Polling completes today’s one-afternoon integration; webhooks would add signing, retries, ordering, and endpoint administration.

Registry key: blueprint_poll_eventing · Back to top

ITD-013

Error envelope and precedence

active
Status
active
Disposition
SHIP
Date
2026-07-16
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

All non-2xx responses use application/problem+json following RFC 9457, stable HTTPS type URIs, request_id, and field-level errors where applicable. Authentication and authorization resolve first; a syntactically valid tenant-scoped operation id absent from AlphaTest returns the catalogued 404 operation-not-found without consulting Content; 424 upstream-contract-mismatch is reserved for a required published upstream response that violates its pinned schema, while missing server credentials or unavailable upstreams return retryable 503 upstream-unavailable.

Alternatives rejected

  • Ad hoc JSON
  • message strings only
  • status-only errors
  • converting every read into 424 when an unrelated prerequisite is absent
  • exposing cross-tenant existence.

Why

Stable machine types and precedence let a cold client distinguish absence, validation, authorization, transient availability, and true contract drift without infrastructure state changing documented resource semantics.

Registry key: blueprint_problem_details · Back to top

ITD-014

Tenant routing

active
Status
active
Disposition
SHIP
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

tenantId comes only from the verified JWT; tenant selection in URL, query, body, or header is rejected and every working-artifact query is tenant scoped.

Alternatives rejected

  • Tenant header
  • tenant path segment
  • trusted body field.

Why

A caller cannot ask to cross a tenant boundary, eliminating confused-deputy routing.

Registry key: blueprint_jwt_tenant_routing · Back to top

ITD-015

Upstream conformance evidence

active
Status
active
Disposition
SHIP
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

Readiness requires trace evidence naming the configured CASE and Content hosts, request correlation ids, resource ids, and successful response classes; local mocks cannot satisfy deployed conformance.

Alternatives rejected

  • Behavioral tests only
  • mock-backed production demo
  • manual screenshot.

Why

The product’s value depends on real upstream composition, which identical local behavior cannot prove.

Registry key: blueprint_upstream_conformance · Back to top

ITD-016

Privacy and retention

active
Status
active
Disposition
SHIP
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

AlphaTest retains tenant-scoped crosswalk working artifacts for 30 days after terminal state, then deletes them; blueprint records and standards follow Content and CASE retention, and no student data enters this module.

Alternatives rejected

  • Permanent crosswalk cache
  • immediate deletion
  • copying upstream resources.

Why

Thirty days supports replay and incident diagnosis without creating another durable standards store.

Registry key: blueprint_working_artifact_retention · Back to top

ITD-017

Kind-specific rules

superseded
Status
superseded
Disposition
SHIP
Date
2026-07-16
Author
alphatest-loop
supersedes
none
superseded_by
ITD-039

Chosen

mastery_gate requires source_assessment_refs containing 1–50 unique immutable Platform3 Content test_spec ids and versions, complete union coverage from those records, highest-rigor policy, and binary mastery criteria; adaptive_diagnostic requires a CASE/KC pool target and stopping-policy reference; formative requires a bounded unit standard set and immediate per-standard criteria.

Alternatives rejected

  • Name, jurisdiction, and frameworkGuid metadata without an assessed-standard set
  • one permissive schema
  • infer kind from criteria
  • separate products.

Why

Conditional requirements prevent an input from selecting a label without earning its promise, and an immutable Content reference makes a named source assessment dereferenceable instead of treating a whole standards framework as tested content.

Registry key: blueprint_kind_specific_validation_superseded · Back to top

ITD-018

Rigor and interaction allocation

active
Status
active
Disposition
SHIP
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

Every slot carries CASE GUIDs, required minimum DOK, count, allowed QTI interaction types, and rationale; aggregate distributions must reconcile exactly to requested item count and time budget.

Alternatives rejected

  • Blueprint-level percentages only
  • free-text rigor
  • TEI mix decided by the bank.

Why

The bank needs executable constraints and the reviewer needs a row-level proof, not an aspiration.

Registry key: blueprint_executable_slots · Back to top

ITD-019

External identifiers

active
Status
active
Disposition
SHIP
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

Public blueprint ids are Platform3 Content test_spec ids, standards are CASE GUIDs, and AlphaTest operation ids are opaque UUIDs used only for orchestration.

Alternatives rejected

  • AlphaTest blueprint ids
  • short CASE aliases
  • composite ids encoding tenant.

Why

Native ids pass directly into downstream modules; opaque operation ids do not leak routing.

Registry key: blueprint_platform_native_ids · Back to top

ITD-020

Versioning and compatibility

active
Status
active
Disposition
SHIP
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

The API is path-versioned at /v1; additive fields may appear, enum expansion is announced, and removals or semantic changes require a new major path with a published overlap window.

Alternatives rejected

  • Header versioning
  • unversioned routes
  • date-based versions.

Why

Path versions are visible in copied examples, while additive evolution avoids needless client churn.

Registry key: blueprint_path_versioning · Back to top

ITD-021

Upstream failure and retry

active
Status
active
Disposition
SHIP
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

Retry transient CASE and Content failures with bounded exponential backoff; terminal operations expose upstream_unavailable without substituting cached or local data, and safe client retry uses the original idempotency key.

Alternatives rejected

  • Infinite retry
  • silent cache fallback
  • expose raw upstream bodies.

Why

Availability trouble remains distinguishable from a coverage defect and never converts stale data into a false proof.

Registry key: blueprint_upstream_failure_policy · Back to top

ITD-022

Observability and secrets

active
Status
active
Disposition
SHIP
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

Structured logs carry request_id, tenant-safe hashes, operation id, upstream host, latency, and status but never JWTs, source documents, student data, or upstream credentials; service credentials remain server-side.

Alternatives rejected

  • Full payload logging
  • client-side upstream calls
  • uncorrelated metrics.

Why

Operators can prove calls and diagnose latency without creating a secret or tenant-data exhaust.

Registry key: blueprint_safe_observability · Back to top

ITD-023

Cancellation and deletion

active
Status
active
Disposition
DEFERRED cancellation; deletion remains Content-owned
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

v1 exposes neither operation cancellation nor blueprint deletion; reopen cancellation when a registered integrator has a reproducible erroneous request that remains nonterminal for more than five minutes, and deletion remains governed by upstream Content policy.

Alternatives rejected

  • Best-effort cancel
  • AlphaTest delete proxy
  • delete of working artifacts by client.

Why

Cancellation races with upstream persistence and AlphaTest cannot independently erase the Content record of truth.

Registry key: blueprint_no_cancel_or_delete · Back to top

ITD-024

Traffic and payload bounds

active
Status
active
Disposition
SHIP
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

Enforce an exact deploy-wide limit of 120 reads per tenant per trailing 60 seconds through blueprint-owned Postgres table blueprint_rate_limit_events(tenant_id_hash, route_class, occurred_at, request_id), primary key request_id, and index (tenant_id_hash, route_class, occurred_at). A SECURITY DEFINER consume_blueprint_read_quota function takes a transaction-scoped advisory lock for tenant+route, deletes rows older than 120 seconds, counts the trailing 60 seconds, and atomically inserts or rejects. RLS is enabled; anon/authenticated grants are revoked; only the server service role executes it. The idempotent migration and execute grant are deployment prerequisites: startup must successfully probe consume_blueprint_read_quota before any blueprint read route is released. Limiter absence or failure returns 503, never fail-open. Rejection returns 429 with integer Retry-After computed from the oldest in-window event. Also limit each tenant to five nonterminal operations and reject JSON above 256 KiB.

Alternatives rejected

  • Per-instance memory
  • approximate fixed windows
  • external unowned limiter
  • fail-open on datastore error
  • one global quota
  • release before migration verification.

Why

One atomic database critical section coordinates every Vercel instance, enforces the stated rolling window exactly, stays tenant-scoped, and has bounded two-minute retention. A deployment probe turns a missing migration into a pre-release failure instead of a customer-visible 503.

Registry key: blueprint_traffic_bounds · Back to top

ITD-025

Consistency and time

active
Status
active
Disposition
SHIP
Date
2026-07-15
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

Operation reads are read-after-write consistent, blueprint detail becomes visible only after Content persistence succeeds, and every timestamp is an RFC 3339 UTC instant with millisecond precision.

Alternatives rejected

  • Eventually consistent operation state
  • local-ready before Content
  • local-time strings.

Why

A polling client never observes a success it cannot dereference and can compare modification cursors without timezone ambiguity.

Registry key: blueprint_consistency_and_time · Back to top

ITD-026

Platform3 Content create, list, and read binding

active
Status
active
Disposition
SHIP
Date
2026-07-16
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

Bind POST /v1/blueprints to POST /content/alpha/implementation/api/tenants/{tenantId}/alpha/content/items with content_kind=test_spec, Authorization, Content-Type, and Idempotency-Key; bind collection reads to GET that items route with content_kind=test_spec; and bind blueprint readback to GET /content/alpha/implementation/api/tenants/{tenantId}/alpha/content/items/{contentId}/blueprint. Map the Content response content_id/spec_id through unchanged. Content atomically owns the item, assessment_role=spec compatibility row, initial version, completed idempotency replay, and all seven native sidecar fields: kc_coverage, item_type_mix, difficulty_constraints, passing_rule, min_forms, max_item_overlap, and enemy_item_rule. Same-body replay must return the same id with Idempotency-Replayed=true; changed-body replay must return 409 content.idempotency_conflict. The descriptor is the discovery authority, but a stale derived boolean is not evidence that an explicitly enumerated route is absent.

Alternatives rejected

  • Wait for a dedicated /test-specs route
  • trust AlphaTest's obsolete route-name regex over the Content operation catalog
  • local shadow test_spec
  • remembered-id list
  • certify a permanently failing API.

Why

Platform3 #787 shipped and production-proved the generic-item test_spec seam; #880 repaired descriptor discovery and proved descriptor-only create → read → list. Binding the actual operation is simpler than inventing a duplicate resource while preserving Content as the record of truth.

Registry key: blueprint_content_write_seam · Back to top

ITD-027

Content blueprint plus crosswalk evidence projection

active
Status
active
Disposition
SHIP
Date
2026-07-16
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

Blueprint detail reads the native Content item and seven-field test_spec sidecar; kc_coverage is the Content-owned KC/cognitive-level allocation, item_type_mix and difficulty_constraints carry the requested distribution constraints, passing_rule carries kind-specific criteria, and the three form fields carry parallel-form policy. AlphaTest joins only the version-pinned source test_spec cells from ITD-030 to its tenant-scoped crosswalk working artifact, emitting source assessment id and version, source standard CASE GUID, source required DOK, source item count, target CASE GUID, mapping kind and provenance, blueprint slot, required DOK, and source Content version. It revalidates source and target through GET /ims/case/v1p1/CFItems/{id} and any non-identity mapping through GET /ims/case/v1p1/CFAssociations/{id}. Before any Content POST, the operation fails unless the source union's unique KC×DOK cell cardinality and total item count are preserved, every cell maps exactly once, and every assigned slot DOK is greater than or equal to source DOK. The working artifact is evidence for the Content blueprint, never a second blueprint record.

Alternatives rejected

  • Infer assessed standards from an entire CASE framework
  • accept caller-authored rows
  • demand fields Content does not own
  • copy the Content sidecar into AlphaTest
  • infer provenance from target kc_coverage
  • persist a partial Content test_spec.

Why

The referenced source test_spec supplies the assessment-specific facts CASE does not infer, CASE verifies the standard graph facts it owns, and Content remains the only blueprint record. The pre-write gate makes omission, count loss, and lower-DOK coverage unable to leak into a native test_spec.

Registry key: blueprint_content_detail_read_seam · Back to top

ITD-028

Platform3 static per-tenant service authentication

active
Status
active
Disposition
SHIP
Date
2026-07-16
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

Use the existing Platform3 static service-JWT format through the server-only PLATFORM3_TENANT_BINDINGS_JSON secret, keyed by exact verified AlphaTest tenantId. Each value is {version,notBefore,expiresAt,current,next}; current and optional next each contain separate contentReadJwt, contentAuthorJwt, and caseReadJwt values. Every JWT must decode to the key's tenantId, an unexpired exp, and exactly read:content, author:content, or case:read for its slot. Select only the binding keyed by the verified caller tenant, prefer next after its notBefore, require at least five minutes remaining, and never fall back to another tenant. Operators install next at least 24 hours before current expires, prove all three same-tenant calls, promote after at least 15 minutes of overlap, and retain still-valid current for rollback until promotion succeeds. Missing, malformed, expired, mismatched, or under-scoped bindings return one non-enumerating 503 tenant-binding-unavailable before any upstream call. AlphaTest never forwards the caller JWT, accepts upstream tokens from requests, calls a demo mint for a real tenant, logs a token or decoded claims, or holds one cross-tenant bearer. Release proves reviewer-blueprint and a second tenant independently, tenant A create/read/list plus CASE reads, bidirectional cross-tenant non-enumeration, wrong-slot least-privilege rejection, current-to-next rotation, expiry rejection, and zero token disclosure.

Alternatives rejected

  • An invented workload-token exchange absent from Platform3
  • one demo or cross-tenant bearer
  • caller-supplied credentials
  • forwarding AlphaTest JWTs
  • one broad token for read, author, and CASE
  • unversioned static secrets without overlap rotation.

Why

Platform3 already accepts these tenant-scoped service JWTs on the proven Content and CASE routes. Exact-tenant selection, separate least-privilege slots, and dual-version overlap are executable now and constrain static-credential risk without pretending an exchange endpoint exists.

Registry key: blueprint_content_service_auth · Back to top

ITD-029

Public composed docs-and-API origin

superseded
Status
superseded
Disposition
SHIP
Date
2026-07-16
Author
alphatest-loop
supersedes
none
superseded_by
ITD-040

Chosen

SHIP one driver-recorded public HTTPS module origin where unauthenticated GET / serves the customer website, GET /architecture serves this decision record, GET /reference serves the data dictionary, and authenticated /v1 routes serve the Blueprint API; every later deliverable bundle preserves all four route classes. Deployment smoke must fail on a Vercel SSO redirect, protected immutable URL, documentation 404, API-to-documentation rewrite collision, asset failure, or bytes that do not match the committed artifacts. When a master route is protected, the verified public module production alias is canonical.

Alternatives rejected

  • Protected immutable deployment as canonical
  • separate disposable docs and API aliases
  • later API deployment replacing root documentation
  • API and docs both claiming the same catch-all rewrite
  • mutable alias used only as reviewer fallback.

Why

A cold AcmeTest maintainer must discover the contract and run it without deployment-console access or origin translation. Requiring every later bundle to preserve explicit docs and API paths prevents implementation deployment from clobbering the approved specification.

Registry key: blueprint_public_composed_origin · Back to top

ITD-030

Authoritative source-assessment blueprint input

superseded
Status
superseded
Disposition
SHIP
Date
2026-07-16
Author
alphatest-loop
supersedes
none
superseded_by
ITD-035

Chosen

Each mastery_gate source_assessment_ref supplies content_test_spec_id and immutable content_version plus customer-facing name, jurisdiction, and assessment_version. AlphaTest reads GET /content/alpha/implementation/api/tenants/{tenantId}/alpha/content/items/{contentTestSpecId}/blueprint with the exact-tenant read:content credential and requires spec_id and version to match, assessment_role=spec, and kc_coverage to be the deployed nonempty JSON object keyed by source CASE GUID with values keyed only by dok1, dok2, dok3, and dok4 and positive integer item counts. Each positive {sourceCaseGuid,DOK,count} cell is one source requirement; the complete returned object is the exhaustive source-assessment manifest. AlphaTest reads each source and target at GET /ims/case/v1p1/CFItems/{id}. Mapping provenance is either identity with the same CASE GUID and item revision on both sides, or a real association read at GET /ims/case/v1p1/CFAssociations/{associationId} whose origin, destination, and revision match the working row; AlphaTest never fabricates an identity association. The union's unique-cell cardinality and total item count before mapping must equal those values after mapping, every cell must map exactly once, and every mapped slot's minimum DOK must be at least the source DOK. An omitted, duplicated, stale, unmapped, ambiguous, count-changing, or lower-DOK cell fails before any Content POST. Conformance fixtures include a complete source test_spec and mutations that omit one cell, lower one slot DOK, duplicate one mapping, or stale one CASE revision; each mutation asserts zero target test_spec writes.

Alternatives rejected

  • Treat every standard in frameworkGuid as tested
  • trust name, jurisdiction, version, or an unsigned upload
  • model kc_coverage as an array when the deployed Content wire returns an object
  • infer source DOK from the generated target
  • fabricate an identity CASE association.

Why

A version-pinned Content test_spec is the existing authoritative assessment blueprint, its deployed kc_coverage grid names the assessed standards, DOK cells, and counts, and CASE remains the standard and mapping authority. Cardinality, count, revision, and DOK invariants make the superset proof reproducible without creating a new source of truth.

Registry key: blueprint_authoritative_source_assessment_input · Back to top

ITD-031

Platform3 tenant credential provisioning gate

active
Status
active
Disposition
SHIP
Date
2026-07-17
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

Platform3 tenant onboarding owns minting the three exact-tenant service JWTs required by ITD-028. Before AlphaTest enables any blueprint route for a tenant, a Platform3 operator must deliver the current bundle through the approved server-secret channel, record issuer, tenantId, exact scope, issued-at, expiry, and rotation owner in a non-secret attestation, and pass automated probes for Content list/read, Content author create/readback, and CASE read using only the matching slot. AlphaTest operations installs the attested bundle into PLATFORM3_TENANT_BINDINGS_JSON, verifies the attestation hash against the installed JWT claims without logging tokens, and records gate status per tenant. The reviewer-blueprint tenant and one isolation tenant are mandatory release fixtures. If Platform3 cannot mint any required slot, AlphaTest files an upstream Platform3 issue naming the missing scope and probe, marks the tenant credential gate blocked, releases no success example for that tenant, and returns retryable 503 tenant-binding-unavailable; it does not mint, broaden, forward, or demo-remap a credential.

Alternatives rejected

  • AlphaTest self-minting Platform3 credentials
  • manual secret installation without claim attestation
  • one demo tenant standing in for production
  • a broad shared bearer
  • documenting 424 as a provisioning state.

Why

This assigns credential creation to the platform that verifies the tokens and gives AlphaTest a concrete, testable handoff. The gate converts the current missing credential from an ambiguous runtime failure into an owned provisioning task without fabricating an upstream capability.

Registry key: blueprint_tenant_credential_provisioning · Back to top

ITD-032

Governed source-assessment catalog onboarding

superseded
Status
superseded
Disposition
SHIP
Date
2026-07-17
Author
alphatest-loop
supersedes
none
superseded_by
ITD-033

Chosen

The AlphaTest testing director owns a version-controlled onboarding manifest that references, but never copies, governed Platform3 Content source-assessment test_specs for TX, FL, AZ, CA, MA, CCSS, NGSS, NAEP, C3, SAT, ISEE, AP, Core Knowledge, Stanford 10, and Iowa. Each manifest entry contains source_key, customer-facing name, jurisdiction or publisher, assessment_version, content_test_spec_id, immutable content_version, applicable subject and grade range, and approval provenance. Publication requires the exact-tenant Content read and CASE probes from ITD-030, a nonempty KC×DOK grid, immutable-version match, and testing-director approval; only approved entries may be accepted as source_assessment_refs. The first release fixture is a governed grade 5 TX mathematics source spec plus at least one independently governed comparison source. Missing coverage for a requested named source returns 422 source-assessment-not-onboarded before operation creation and names only the missing source_key; stale or unreadable approved entries fail the operation with 503 source-assessment-unavailable and zero target Content writes. If Platform3 lacks a source test_spec or cannot preserve its immutable version, AlphaTest files an upstream Content issue and keeps that source unapproved; it never synthesizes the source spec or infers it from CASE.

Alternatives rejected

  • Caller-supplied arbitrary Content ids
  • an AlphaTest copy of source coverage
  • treating every named framework as onboarded
  • unsigned spreadsheets
  • silently dropping a missing source
  • generating a substitute source assessment locally.

Why

The testing director can certify exactly which external assessments are usable while Content remains the record of truth. A governed reference catalog supplies discovery and approval provenance without duplicating standards or assessment blueprints.

Registry key: blueprint_governed_source_catalog_onboarding · Back to top

ITD-033

Executable governed-source release catalog

superseded
Status
superseded
Disposition
SHIP fail-closed catalog; DEFERRED grade-5 TX success
Date
2026-07-17
Author
alphatest-loop
supersedes
ITD-032
superseded_by
ITD-036

Chosen

Publish governed-source-release.json as the only executable source-assessment catalog. Its current release_state is blocked_missing_owner_records and source_assessments is empty because exact-tenant live Content inspection found no authoritative grade-5 TX mathematics source test_spec and no independently governed grade-5 comparison source test_spec; labels and the one-KC AlphaTest wire-certification draft are explicitly non-authoritative. Promotion to ready requires, in one reviewed change, two distinct owner-published Content test_specs with source_key, content_test_spec_id, immutable content_version, name, jurisdiction_or_publisher, assessment_version, subject, grade_range, applicability, approval, and evidence; evidence must record repeatable 200 Content readback, matching spec_id/version and assessment_role=spec, a nonempty exhaustive KC×DOK grid, and 200 CASE CFItem reads for every KC plus CFAssociation reads for every non-identity mapping. Until promotion, grade-5 TX mastery_gate examples are non-runnable and POST returns 422 source-assessment-not-onboarded before operation creation or any local/upstream write. After promotion, the deployed smoke must build its request from the exact two catalog entries and require 202, operation ready, Content detail/list readback, complete coverage, and live Content/CASE traces; a conditional smoke that treats the blocked 422 as customer success is forbidden.

Alternatives rejected

  • Relabel the one-KC wire fixture as STAAR or Iowa
  • publish labels without immutable ids
  • create source coverage from a whole CASE framework
  • accept caller-supplied arbitrary ids
  • advertise a 202 example while the catalog is blocked.

Why

A checked-in state machine makes the release claim machine-verifiable today and gives the testing director one atomic promotion path without AlphaTest fabricating an external assessment or silently treating prerequisite enforcement as customer success.

Registry key: blueprint_executable_governed_source_release · Back to top

ITD-034

Content-compatible list query

superseded
Status
superseded
Disposition
SHIP supported filters and cursor; DEFERRED explicit sort
Date
2026-07-17
Author
alphatest-loop
supersedes
ITD-008
superseded_by
ITD-038

Chosen

GET /v1/blueprints translates only to Content-published list parameters: content_kind=test_spec, limit, cursor, test_kind, subject_id, target_grade_id, status, and modifiedSince; it never sends sort because the live Content descriptor does not publish that parameter and rejects it. AlphaTest preserves Content's returned order and opaque cursor without local reordering or indexing. Client-selectable or forced created_at ordering is DEFERRED until the Content descriptor publishes a stable sort parameter and a live tenant-scoped probe returns 200 with cursor-stable ordering; unsupported AlphaTest query fields return 422 before the upstream call.

Alternatives rejected

  • Continue sending sort and translate Content 400 to 503
  • sort one page locally
  • build a remembered-id index
  • scan the tenant catalog
  • silently ignore client sort.

Why

The current customer needs a reachable collection read more than an ordering guarantee Content does not offer. Preserving native order and cursor keeps Content authoritative and prevents a documented 200 from becoming a permanent upstream error.

Registry key: blueprint_content_compatible_list_query · Back to top

ITD-035

Content item version identity

active
Status
active
Disposition
SHIP
Date
2026-07-17
Author
alphatest-loop
supersedes
ITD-030
superseded_by
none

Chosen

Each mastery_gate source_assessment_ref supplies source_key, content_test_spec_id, content_version, name, jurisdiction, and assessment_version exactly matching the caller-tenant entry in governed-source-release.json. The catalog additionally pins content_version_id to the immutable latest_version_id returned by GET /content/alpha/implementation/api/tenants/{tenantId}/alpha/content/items/{contentTestSpecId}; AlphaTest requires the item content_id and latest_version_id to match those pins, then separately requires the blueprint sidecar spec_id to match, assessment_role=spec, and kc_coverage to be a nonempty object of positive dok1–dok4 counts. The sidecar is not required to repeat a version field it does not own. AlphaTest re-reads the item after the sidecar and fails 503 source-assessment-unavailable with zero target Content writes if latest_version_id changed, so the two reads bracket one immutable coverage snapshot. It then verifies every source and target at GET /ims/case/v1p1/CFItems/{id}, every non-identity mapping at GET /ims/case/v1p1/CFAssociations/{associationId}, preserves unique KC×DOK cardinality and total item count, maps every cell exactly once, and requires target DOK greater than or equal to source DOK.

Alternatives rejected

  • Require an absent sidecar version field
  • trust the catalog's display version without an owner-issued version id
  • treat updated_at as immutable identity
  • copy the sidecar locally
  • accept latest-version drift between item and coverage reads.

Why

Content already exposes immutable version identity on its authoritative item route and coverage on its blueprint route. Bracketing the sidecar with matching item-version reads composes those owner-published facts without demanding a duplicate field or creating an AlphaTest version store.

Registry key: blueprint_content_item_version_identity · Back to top

ITD-036

Tenant-scoped governed-source promotion

superseded
Status
superseded
Disposition
SHIP demo tenant source pair; DEFERRED other-tenant availability
Date
2026-07-17
Author
alphatest-triage+2026-07-17-033
supersedes
ITD-033
superseded_by
ITD-048

Chosen

governed-source-release.json remains the only executable catalog and is promoted to release_state ready for tenant demo with the operator-approved staar-math-g5-v2024 and iowa-math-g5-l11 entries from alphatest#45. Each entry pins tenant_id, the six public reference fields, content_version_id, subject and grade applicability, approval provenance, and dated Content/CASE evidence. Production reads this checked-in catalog in every NODE_ENV; GOVERNED_SOURCE_CATALOG_JSON is only a byte-equivalent deployment mirror and cannot override it. A request is approved only when its exact six-field reference matches an entry whose tenant_id equals the verified JWT tenant and whose ITD-035 wire checks pass. The demo release smoke must build the exact two-entry request and require 202, ready, Content detail/list readback, complete equal-or-higher-DOK coverage, and Content/CASE traces; 422 is never success for that fixture. Other tenants return 422 source-assessment-not-onboarded with zero writes until Platform3 Content publishes the same governed source records in that exact tenant and a reviewed catalog change records their distinct version ids and evidence. Reopen global catalog portability only when Content publishes an owner-defined cross-tenant source reference or replication contract and two tenant probes resolve one governed source without AlphaTest copying it.

Alternatives rejected

  • Keep the now-false empty catalog
  • trust an environment-only catalog in production
  • silently remap reviewer-blueprint to demo
  • treat demo Content ids as globally readable
  • accept a blocked 422 as deployed-smoke success
  • copy source test_specs into AlphaTest.

Why

The checked-in oracle now reflects the live owner records and the accepted promotion decision, while exact-tenant matching preserves isolation and truthfully exposes the remaining tenant-publication boundary instead of inventing global Content identity.

Registry key: blueprint_tenant_scoped_governed_source_promotion · Back to top

ITD-037

Wire-faithful read projections

active
Status
active
Disposition
SHIP
Date
2026-07-17
Author
alphatest-loop
supersedes
ITD-007
superseded_by
none

Chosen

GET /v1/blueprints returns a BlueprintPage of wire-faithful BlueprintSummary records projected only from each Content list item: content_test_spec_id, title, subject, grade, status, latest_version_id, updated_at, and links, plus Content's opaque next_cursor. It never requires detail-only test_kind, scope, item_count, time_budget_minutes, rigor_policy, slots, distributions, policy_version, or supersedes fields and never returns 424 merely because those fields are absent from the collection response. GET /v1/blueprints/{id} composes the Content item and seven-field test_spec sidecar into BlueprintDetail; test_kind and kind-specific criteria must be encoded inside Content-owned passing_rule at create time, KC allocation comes from kc_coverage, interaction and rigor constraints come from item_type_mix and difficulty_constraints, and parallel-form policy comes from min_forms, max_item_overlap, and enemy_item_rule. GET /coverage joins that Content-owned detail to AlphaTest's permitted tenant-scoped crosswalk evidence while retained. Fields with no owner-published source are absent rather than synthesized. A published Content response that omits a field this projection actually requires is 424 upstream-contract-mismatch.

Alternatives rejected

  • Demand the full detail schema from list rows
  • return deterministic 424 for every valid collection read
  • shadow the original request
  • remember ids locally
  • fabricate absent fields
  • scan detail for every list row.

Why

A recovery list and a rich detail representation have different jobs. Matching each response to the facts Content actually publishes keeps list usable, prevents N+1 calls, and preserves Content as the blueprint record without weakening detail or coverage evidence.

Registry key: blueprint_wire_faithful_read_projections · Back to top

ITD-038

Wire-verified list filters

active
Status
active
Disposition
SHIP verified filters; DEFERRED test_kind, status, and sort filters
Date
2026-07-17
Author
alphatest-loop
supersedes
ITD-034
superseded_by
none

Chosen

GET /v1/blueprints accepts only limit, cursor, subject_id, target_grade_id, and modifiedSince. It sends content_kind=test_spec, passes limit, cursor, subject_id, and target_grade_id unchanged, and passes the camelCase modifiedSince name through verbatim in one tenant-scoped Content call. The live endpoint-list-content-items descriptor publishes subject_id, target_grade_id, modifiedSince, test_type, and is_mastery_gate; dated exact-tenant probes returned 200 for subject_id, target_grade_id, modifiedSince, and is_mastery_gate=true, but returned 400 for test_kind, status, test_type, modified_since, and sort. AlphaTest therefore DEFERs public test_kind and status list filters rather than scan, synthesize, or expose mastery_gate-only semantics for a three-kind field. Reopen test_kind only when Content supports all three AlphaTest values in one published parameter and live probes return 200 for mastery_gate, adaptive_diagnostic, and formative; reopen status only when Content publishes it and live probes return 200 for every documented status. Explicit sort remains DEFERRED until Content publishes a stable sort parameter and a live probe proves cursor-stable ordering. Any unsupported AlphaTest query field returns 422 before Content; any published filter later rejected on the wire returns non-retryable 424 upstream-contract-mismatch, records the failing probe, files an upstream issue, and blocks release.

Alternatives rejected

  • Keep the false test_kind and status contract
  • map only mastery_gate to is_mastery_gate and leave two selector values impossible
  • use test_type despite its live 400
  • translate modifiedSince to modified_since
  • scan all Content rows and filter locally
  • retry a deterministic 400 as 503
  • silently ignore unsupported fields.

Why

The AcmeTest maintainer gets a list contract every documented value can actually execute. The narrower public surface preserves Content as the catalog, keeps the one-field test_kind resource lifecycle intact, and turns future upstream drift into an explicit contract failure rather than a misleading transient outage.

Registry key: blueprint_wire_verified_list_filters · Back to top

ITD-039

Three-kind validation and adaptive diagnostic upstream release gate

superseded
Status
superseded
Disposition
SHIP mastery_gate and formative; DEFERRED adaptive_diagnostic release
Date
2026-07-18
Author
alphatest-loop
supersedes
ITD-017
superseded_by
ITD-041

Chosen

mastery_gate requires source_assessment_refs containing 1–50 unique immutable Platform3 Content test_spec ids and versions, complete union coverage from those records, highest-rigor policy, and binary mastery criteria. formative requires a bounded unit standard set and immediate per-standard criteria. Keep adaptive_diagnostic as one value of the same required test_kind field and require its CASE/KC pool target plus stopping-policy reference, but DEFER adaptive_diagnostic creation, runnable success examples, and release certification because the dated exact-tenant CASE probe returned 200 with 100 CFItems and zero items typed Knowledge Component, GET /ims/case/v1p1/CFPackages?limit=100 returned 405, and the known Grade 5 package detail returned Standards without a package identity. Until the release trigger occurs, POST with test_kind=adaptive_diagnostic fails before operation creation or any Content write with typed 422 adaptive-kc-corpus-not-onboarded, retryable=false, and a link to Platform3 issue #1138; AlphaTest never relabels Standards as KCs, copies a CASE corpus, or fabricates a ready response. Reopen only when Platform3 CASE publishes an exact-tenant framework or package containing at least one owner-typed adaptive-eligible Knowledge Component, a documented collection or detail request returns 200 with stable framework/package and CFItem identities, every returned KC dereferences through GET /ims/case/v1p1/CFItems/{id}, and the exact documented AlphaTest request reaches 202, ready, and native Content test_spec readback with sanitized CASE and Content traces.

Alternatives rejected

  • Keep only the adaptive replacement clause and orphan the mastery_gate/formative rules
  • keep the implicit adaptive SHIP decision
  • treat Standard items as Knowledge Components
  • use placeholder GUIDs
  • return generic 424 for an unreleased corpus
  • create a local KC table
  • claim success from validation-only tests
  • split adaptive diagnostics into a separate API.

Why

Full replacement text keeps all three kinds formally pinned in one active decision while making the adaptive upstream non-decision explicit and falsifiable. The customer can certify mastery_gate and formative inputs now, distinguish an unavailable owner corpus from a malformed adaptive request, and know the adaptive release cannot turn green until the real Platform3 CASE and Content journey exists on the wire.

Registry key: blueprint_kind_specific_validation · Back to top

ITD-040

Product-origin routing and mount-safe operation references

active
Status
active
Disposition
SHIP
Date
2026-07-20
Author
alphatest-loop
supersedes
ITD-029
superseded_by
none

Chosen

The canonical customer origin is the one-product master origin. It serves the architecture, data dictionary, and customer website at their driver-recorded cell paths and mounts each deployed Blueprint API at /blueprint/integrator_api/implementation@{test_kind}/api; the immutable module deployment serves an API landing page at / and authenticated API routes at /v1 but does not duplicate or claim /architecture or /reference. POST /v1/blueprints returns 202 with Location: ./operations/{operationId} and an identical relative reference in operation.href. Both references are resolved against the effective POST URL, so they produce /v1/operations/{operationId} at the module origin and remain under /blueprint/integrator_api/implementation@{test_kind}/api/v1/operations/{operationId} at the path-mounted canonical origin. Clients follow the returned reference and must not construct a root-absolute /v1 URL. Deployment smoke must exercise POST then follow Location at both origins, require the documented operation response rather than a platform 404, verify the three master-origin documentation cell URLs return byte-matched committed artifacts, verify the module origin /architecture and /reference return 404, and fail on SSO, cross-kind rewrite collision, or an escaped mount.

Alternatives rejected

  • A shared root /v1 gateway whose ownership collides across modules
  • root-absolute Location: /v1/operations/{id}
  • copying architecture and reference bundles into every implementation deployment
  • reconstructing poll URLs from a deployment-specific base
  • relying on the browser Referer header or Vercel-only rewrite behavior.

Why

A standards-valid relative Location preserves the complete async contract under both deployment shapes without creating a second gateway or coupling clients to Vercel. Keeping specifications at stable master-origin cell URLs prevents stale duplicate docs, while explicit two-origin smoke checks make the routing contract independently certifiable.

Registry key: blueprint_product_origin_mount_safe_operations · Back to top

ITD-041

Adaptive deferred-window contract and release certification

superseded
Status
superseded
Disposition
SHIP deferred-window contract; DEFERRED adaptive_diagnostic release
Date
2026-07-20
Author
alphatest-loop
supersedes
ITD-039
superseded_by
ITD-043

Chosen

Keep adaptive_diagnostic as one value of the required test_kind field and keep its CASE/KC pool target plus stopping-policy validation, but DEFER successful adaptive creation while the verified JWT tenant lacks a discoverable, owner-typed CASE knowledge-component corpus. During this deferred window, POST /v1/blueprints with test_kind=adaptive_diagnostic must return typed 422 adaptive-kc-corpus-not-onboarded, retryable=false, before operation creation, idempotency receipt, CASE request, Content write, or local working state; authenticated list/detail reads remain live Content-backed, anonymous and cross-tenant requests fail closed, and the public release-status surface links Platform3 issue #1138 and the dated adaptive-release-evidence.json. This deferred-window behavior is the complete certifiable contract for implementation@adaptive_diagnostic and is not a successful diagnostic release. Reopen implementation when independently observable upstream facts all hold for one exact tenant: CASE publishes a documented framework/package discovery or detail route returning 200 with stable identities, the corpus contains owner-typed adaptive-eligible Knowledge Components, and every selected KC dereferences at GET /ims/case/v1p1/CFItems/{id}. After reopening, but before declaring release, a separate certification must prove the exact documented AlphaTest POST returns 202, its relative Location reaches ready, the returned native Content test_spec carries the stopping_policy passing rule, the coverage route returns coverage-not-applicable, and sanitized CASE and Content traces prove real upstream calls. Failed post-reopen certification returns the cell to changes_requested; it does not make the reopen trigger circular. AlphaTest never relabels Standards as KCs, copies a CASE corpus, or fabricates a ready response.

Alternatives rejected

  • Keep 202-to-ready as a precondition for lifting the gate that prevents 202
  • treat the deferred 422 as a successful adaptive diagnostic
  • require the downstream customer eval to pass an impossible success journey during the deferred window
  • promote the demo tenant from a single known package containing one KC without a discoverable corpus contract
  • treat Standard items as Knowledge Components
  • copy or synthesize a local KC corpus
  • split adaptive diagnostics into a separate API.

Why

Separating upstream-observable reopen facts from post-reopen end-to-end certification removes the circular gate while preserving the honest D5 boundary. The AcmeTest maintainer can certify exactly what the deferred deployment guarantees today, and the academics lead gets a successful diagnostic only after real CASE discovery, dereference, Content persistence, and wire evidence all pass in sequence.

Registry key: blueprint_adaptive_deferred_window_and_release_certification · Back to top

ITD-042

Out-of-band demo release reviewer credential

superseded
Status
superseded
Disposition
SHIP secure evaluator credential for the demo release fixture
Date
2026-07-20
Author
alphatest-loop
supersedes
none
superseded_by
ITD-049

Chosen

For the governed mastery_gate release fixture, AlphaTest operations issues a short-lived reviewer JWT out of band for tenant demo and places that token in the verification profile's mandated BLUEPRINT_PROD_REVIEWER_JWT environment variable, so the autonomous evaluator's existing credential path executes the exact ITD-036 demo release POST without tenant remapping. A separate BLUEPRINT_ISOLATION_REVIEWER_JWT is issued for tenant reviewer-blueprint and is used only for normal-tenant 422 behavior and bidirectional cross-tenant isolation probes. Both tokens have role reviewer, explicit blueprint:read and blueprint:write scopes, a maximum 15-minute lifetime, and no student, roster, QTI, Results, administrative, or cross-tenant authority. The operator-side mint uses PLATFORM_JWT_SIGNING_SECRET in the bounded driver or CI trust boundary; the secret and tokens are never exposed by an HTTP endpoint, committed, logged, embedded in evidence, or copied into the public site. Sanitized evaluator output records only issuer, tenantId, scopes, expiry, credential purpose, and credential_source=operator_out_of_band. The release fixture must return 202 with the demo credential; the isolation credential must return 422 source-assessment-not-onboarded with zero writes for the same source refs, and neither credential may read the other's working artifacts. Missing, expired, wrong-tenant, or over-scoped credentials fail the release cell; they never authorize tenant remapping, a public mint route, copied source records, or acceptance of 422 as release success.

Alternatives rejected

  • Silently remap the reviewer-blueprint tenant to demo
  • publish a demo-token mint endpoint
  • reuse a long-lived shared demo bearer
  • copy the governed source test_specs into reviewer-blueprint
  • weaken ITD-036 so 422 counts as successful release evidence
  • log or commit the short-lived token for reviewer convenience.

Why

Putting the operator-issued demo credential in the verification profile's existing required variable makes the established autonomous evaluator executable without changing its credential lookup. A separately purposed reviewer-blueprint token preserves meaningful negative-path and cross-tenant verification without pretending demo Content ids exist in another tenant.

Registry key: blueprint_demo_release_reviewer_credential · Back to top

ITD-043

Three-kind validation and adaptive release contract

active
Status
active
Disposition
SHIP mastery_gate and formative; SHIP adaptive deferred-window contract; DEFERRED adaptive_diagnostic release
Date
2026-07-20
Author
alphatest-loop
supersedes
ITD-041
superseded_by
none

Chosen

mastery_gate requires source_assessment_refs containing 1–50 unique immutable Platform3 Content test_spec ids and versions, complete union coverage from those records, highest-rigor policy, and binary mastery criteria. formative requires a bounded unit standard set and immediate per-standard criteria. adaptive_diagnostic remains one value of the same required test_kind field and requires a CASE/KC pool target plus stopping-policy reference, but successful adaptive creation is DEFERRED while the verified JWT tenant lacks a discoverable, owner-typed CASE knowledge-component corpus. During that deferred window, adaptive POST returns typed 422 adaptive-kc-corpus-not-onboarded, retryable=false, before operation creation, idempotency receipt, CASE request, Content write, or local working state; authenticated list/detail reads remain live Content-backed, anonymous and cross-tenant requests fail closed, and the release-status surface links Platform3 issue #1138 and the dated evidence. Reopen adaptive implementation only when independently observable upstream facts all hold for one exact tenant: CASE publishes a documented framework/package discovery or detail route returning 200 with stable identities, the corpus contains owner-typed adaptive-eligible Knowledge Components, and every selected KC dereferences at GET /ims/case/v1p1/CFItems/{id}. After reopening, a separate release certification must prove the documented POST returns 202, its relative Location reaches ready, the native Content test_spec carries the stopping_policy passing rule, coverage returns coverage-not-applicable, and sanitized CASE and Content traces prove real upstream calls. Failed post-reopen certification returns the cell to changes_requested and never relabels Standards as KCs, copies a CASE corpus, or fabricates success. All three kinds use the same blueprint resource and operation lifecycle; no kind is a separate product.

Alternatives rejected

  • Keep ITD-041 as a partial replacement that leaves mastery_gate and formative rules only in superseded records
  • split adaptive diagnostics into a separate API
  • keep 202-to-ready as a precondition for lifting the gate that prevents 202
  • treat the deferred 422 as a successful adaptive diagnostic
  • treat Standard items as Knowledge Components
  • copy or synthesize a local KC corpus
  • drop kind-specific criteria in favor of one generic validation rule.

Why

A full replacement preserves the complete three-kind contract while retaining the non-circular adaptive release sequence. Every selector value again has active validation and criteria rules, and downstream cells can certify either the honest deferred window or the real upstream-backed success path without relying on superseded text.

Registry key: blueprint_three_kind_validation_and_adaptive_release · Back to top

ITD-044

Per-source perfect-score calibration target

active
Status
active
Disposition
SHIP
Date
2026-07-24
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

For every mastery_gate source_assessment_ref, AlphaTest derives exactly one SourceCalibrationTarget from the exact-tenant governed source catalog; callers continue to supply only the approved six-field source reference and cannot assert or override calibration. The target has stable calibration_target_id cal:{source_key}:{assessment_version}:{calibration_policy_version}, source_key, source content_test_spec_id and content_version_id, metric equivalent_raw_score_percent, target_value 100, relation mastery_implies_at_least, calibration_policy_version, scoring_policy_ref, evidence_refs, approved_at, and approved_by. The semantics are literal: a student satisfying the resulting blueprint's complete coverage and mastery criteria is calibrated to earn 100 percent of available raw-score points under the named source assessment's version-pinned scoring policy; a percentile, projected pass, confidence-only threshold, or less-than-100 target is invalid. Evidence refs are native, tenant-scoped Results result_record or Analytics artifact references plus the version-pinned scoring-policy evidence; AlphaTest dereferences them at generation time and stores no score, attempt, or mastery fact. Content remains the record of truth: passing_rule stores minimumPercent, requiredStandardPercent, calibrationPolicyVersion, and sourceCalibrationTargets; each target is projected unchanged as criteria.sourceCalibrationTargets on BlueprintDetail and as calibration.target plus calibration.status on the matching coverage source. Creation fails before any Content write with typed 422 calibration-target-missing, calibration-target-ambiguous, calibration-target-invalid, or calibration-evidence-invalid when the source-reference set and target set do not have exact one-to-one source/version identity, a target is not 100 with the literal relation, or an evidence reference is absent/not found. A published upstream schema mismatch returns 424 upstream-contract-mismatch; unavailable Results, Analytics, Content, or CASE returns retryable 503 calibration-evidence-unavailable. No failure may write Content, and the final DOK and mastery criteria must satisfy both the target and the fail-closed superset invariant.

Alternatives rejected

  • Add calibration fields to the six-field caller source reference
  • let the caller claim a perfect-score target
  • store calibration in an AlphaTest blueprint table
  • encode only a projected-pass probability
  • accept a target below 100 percent
  • publish targets only in transient coverage evidence
  • allow a warning when one source lacks a target.

Why

A governed, version-pinned target per named source makes the perfect-score promise explicit and auditable without trusting client assertions or creating another system of record. Content-owned passing_rule keeps the target attached to the immutable blueprint criteria that downstream scoring and reporting already read.

Registry key: blueprint_per_source_perfect_score_calibration · Back to top

ITD-045

Reports calibration-delta revision protocol

active
Status
active
Disposition
SHIP
Date
2026-07-24
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

Reports submits calibration feedback to POST /v1/blueprints/{contentTestSpecId}/calibration-deltas with a required Idempotency-Key and a signed, unexpired same-tenant service JWT carrying role reports_service and blueprint:calibration:write; integrator and reviewer roles cannot call it. This is the single service-command exception to the customer-role matrix superseded by ITD-047. The body contains delta_id, calibration_target_id, source_key, base_content_version_id, sequence, generated_at, analytics_artifact_ref, result_record_refs, external_score_evidence_refs, analysis_policy_version, reason_codes, and proposed_changes containing only minimumPercent, requiredStandardPercent, or minimum_dok_by_case_guid. AlphaTest first dereferences the native Results/Analytics evidence under least-privilege server credentials, verifies every reference and source/tenant/version binding, then acquires a tenant+blueprint revision lock and requires base_content_version_id to equal the current immutable version and sequence to be exactly the next value for that blueprint/source. The same idempotency key plus canonical body replays the same operation and successor; key reuse with a different body or delta_id with different content returns 409 calibration-delta-conflict, and an old base or sequence returns 409 calibration-delta-stale with current_version_id and next_sequence but no cross-tenant fact. Deterministic application may raise or lower a proposed threshold only when the resulting criteria still satisfy every per-source perfect-score target and the exhaustive equal-or-higher-DOK coverage invariant; otherwise it returns 422 calibration-delta-would-weaken-proof with zero Content writes. Success returns 202 and an operation that creates a new immutable Content test_spec identity and version through the existing Content create seam, copies no attempt data, links supersedes to the prior blueprint, records applied_delta_id and before/after criteria plus evidence references in Content passing_rule, and leaves the prior record unchanged. Ready returns predecessor and successor Content ids/versions, calibration target id, applied sequence, before/after criteria hashes, coverage proof hash, evidence refs, Content trace id, and replay status so Reports can retain the revision receipt. AlphaTest keeps only the normal bounded idempotency/revision working metadata and 30-day audit composition; Results and Analytics remain the durable owners of outcome and calibration evidence.

Alternatives rejected

  • Allow Reports to PATCH the existing Content record
  • accept unsigned callbacks
  • let callers select tenant in the body
  • apply deltas without dereferencing Results and Analytics
  • last-write-wins ordering
  • store external scores in AlphaTest
  • silently rebase stale deltas
  • weaken coverage to satisfy a calibration recommendation.

Why

A narrow service-to-service command closes the improvement loop while immutable successor records preserve every historical gate. Exact-base ordering, idempotent replay, upstream evidence dereference, and fail-closed proof revalidation make concurrent or stale analytics unable to rewrite a released standard silently.

Registry key: blueprint_reports_calibration_delta_revision · Back to top

ITD-046

Calibration acceptance and non-regression proof

active
Status
active
Disposition
SHIP
Date
2026-07-24
Author
alphatest-loop
supersedes
none
superseded_by
none

Chosen

Release conformance includes an autonomous two-source calibration fixture and mutation suite. The positive fixture creates a mastery_gate whose governed source references each resolve to one 100-percent SourceCalibrationTarget, reaches ready, reads the Content item and passing_rule back, and proves exact source/version/target cardinality plus public BlueprintDetail and coverage projection parity. Negative creation mutations remove one target, duplicate one source target, change source or version identity, set target_value to 99.99, change the literal relation, or make an evidence ref non-dereferenceable; each must return the catalogued 422 and assert zero target Content writes. The delta fixture snapshots predecessor Content id/version, criteria, per-source targets, union KC×DOK cells, item counts, and coverage hash; applies one reports-signed delta; follows 202 to ready; and asserts a distinct immutable successor linked by supersedes, unchanged predecessor, preserved exhaustive source-cell cardinality and item counts, every mapping exactly once at target DOK greater than or equal to source DOK, all sources still at target 100, and before/after criteria, target, evidence, delta, and coverage hashes visible to Reports and public reads. Replaying the same Idempotency-Key, body, and delta_id must return the same successor with replay=true and no extra Content write; changed-body key reuse and changed-content delta reuse must return conflict, while stale base and skipped or repeated sequence must return stale, all with zero writes. The suite records sanitized Content, CASE, Results, and Analytics hosts, methods, statuses, native ids, trace ids, and timestamps; mocks or local fixtures cannot satisfy deployed conformance.

Alternatives rejected

  • Check only that a calibration field exists
  • manually inspect a generated JSON response
  • test delta arithmetic without Content readback
  • accept a new version without comparing coverage
  • omit deterministic replay and conflict probes
  • use local Results or Analytics fixtures as production evidence.

Why

The acceptance suite proves presence, application, determinism, immutability, provenance, and non-regression of the superset invariant as one deployed contract. It converts the perfect-score and improvement-loop claims into falsifiable release gates rather than documentation assertions.

Registry key: blueprint_calibration_conformance_proof · Back to top

ITD-047

Customer and reports-service authorization

active
Status
active
Disposition
SHIP
Date
2026-07-24
Author
alphatest-loop
supersedes
ITD-011
superseded_by
none

Chosen

Every endpoint requires a verified Bearer JWT with sub, role, tenantId, iat, and exp, and tenantId remains the only tenant-routing source. Customer endpoints retain the bounded role matrix: reviewer and integrator have implicit blueprint:read and blueprint:write so both can replay the documented create contract in their own tenant; an optional scope claim can only narrow that role maximum; customer POST /v1/blueprints requires blueprint:write and customer GET routes require blueprint:read. POST /v1/blueprints/{contentTestSpecId}/calibration-deltas is the only reports service command: it requires role reports_service and explicit blueprint:calibration:write, grants no customer create/read right by implication, and rejects reviewer, integrator, missing-scope, wrong-tenant, expired, or anonymous tokens before idempotency or upstream access. No role grants student, roster, QTI, Results-record read, administrative, or cross-tenant permission through this API; the server uses separately held least-privilege upstream credentials to dereference only the evidence refs carried by an authorized delta.

Alternatives rejected

  • Leave ITD-011's every-endpoint customer-role text active beside a contradictory service endpoint
  • grant calibration writes to integrator or reviewer
  • let reports_service inherit all blueprint reads and writes
  • accept a shared callback secret
  • route tenant from the delta body
  • forward the caller service JWT to Results or Analytics.

Why

One complete replacement preserves the executable cold-integrator credential contract while making the reports improvement loop a narrow machine authority. Authentication and tenant rejection happen before side effects, and upstream evidence access remains separately least-privileged.

Registry key: blueprint_customer_and_reports_service_auth · Back to top

ITD-048

Calibration evidence release gate

superseded
Status
superseded
Disposition
SHIP complete catalog schema; DEFERRED demo mastery_gate release until 4/4 source-bound evidence receipts
Date
2026-07-24
Author
alphatest-loop
supersedes
ITD-036
superseded_by
ITD-050

Chosen

governed-source-release.json schema version 3 is the executable source-and-calibration catalog. Each source entry contains the immutable tenant/source/Content identity plus exactly one owner-approved calibration object with calibration_target_id, literal equivalent_raw_score_percent target 100, relation mastery_implies_at_least, immutable calibration_policy_version, version-pinned scoring_policy_ref, approval principal and instant, and evidence bindings. Each binding names its native owner, immutable reference id, exact tenant-scoped dereference method and route, least-privilege server credential slot, expected source_key/content_test_spec_id/content_version_id/calibration_target_id tuple, and a sanitized 2xx receipt reference. Results uses GET ${PLATFORM3_RESULTS_BASE_URL}/alpha/results/v1/result-records/{resultRecordId} with PLATFORM3_RESULTS_CALIBRATION_READER_JWT; Analytics requires GET ${PLATFORM3_ANALYTICS_BASE_URL}/alpha/analytics/v1/calibration-artifacts/{artifactId} with PLATFORM3_ANALYTICS_CALIBRATION_READER_JWT. The current Analytics contract does not publish that calibration-artifact detail route, and neither source has an owner-approved native Results record or Analytics artifact bound to its exact source/version/target tuple. Therefore both entries are blocked_missing_source_bound_evidence and the catalog release_state is blocked_missing_calibration_evidence; POST for either formerly promoted fixture fails before operation creation or any local or Content write with 422 calibration-evidence-not-onboarded. Generic Results/Analytics 2xx rows, sandbox fixtures, public scoring pages, Content/CASE governance receipts, null ids, and route templates never satisfy a binding. Promotion to ready is atomic and occurs only after every required binding has a non-null native id, the owner route is published, an owner-approved policy record exists, and a fresh same-tenant probe returns 2xx whose response binds the exact four-part identity; the sanitized receipt records host, method, path template, status, native id, trace id, observed_at, response schema/version, binding fields and hashes, but no credential or learning fact. Exactly one target must derive for each source/version and zero targets may derive while any binding is incomplete. Reopen the demo mastery_gate quickstart and its 202-to-ready release claim only when all four source-owner pairs (STAAR×Results, STAAR×Analytics, Iowa×Results, Iowa×Analytics) pass that rule in one catalog revision and the deployed release smoke proves the exact catalog bytes were loaded.

Alternatives rejected

  • Keep release_state ready while calibration inputs are absent
  • invent Results record ids or Analytics artifact ids
  • treat unrelated 2xx rows as source-bound evidence
  • treat Content and CASE coverage receipts as calibration evidence
  • permit a caller to supply calibration ownership fields
  • release with only one evidence owner or one source proven
  • store copied Results or Analytics payloads in AlphaTest
  • publish an Analytics route that the upstream contract does not implement.

Why

A complete but blocked owner record gives downstream code an executable schema without manufacturing upstream facts. Atomic four-binding promotion makes the perfect-score claim falsifiable, preserves Platform3 ownership, and tells the AcmeTest maintainer exactly why the former quickstart is closed and what observable evidence reopens it.

Registry key: blueprint_calibration_evidence_release_gate · Back to top

ITD-049

Pending-release reviewer credential

superseded
Status
superseded
Disposition
SHIP reserved out-of-band credential slots; DEFERRED 202 smoke until ITD-048 promotion
Date
2026-07-24
Author
alphatest-loop
supersedes
ITD-042
superseded_by
ITD-051

Chosen

The verification profile's BLUEPRINT_PROD_REVIEWER_JWT and BLUEPRINT_ISOLATION_REVIEWER_JWT slots remain the only permitted out-of-band reviewer credential paths, with the same 15-minute maximum lifetime, least-privilege blueprint scopes, secret-handling rules, and tenant isolation requirements formerly pinned by ITD-042. They are reserved inputs, not evidence that the mastery-gate quickstart is released. While ITD-048 reports blocked_missing_calibration_evidence, release certification must assert the exact governed create request returns 422 calibration-evidence-not-onboarded before operation or writes for both credentials as applicable; no evaluator may require, accept, document, or regression-test 202-to-ready. The positive demo credential is minted and the 202-to-ready smoke is enabled only in the same deployment revision that loads a catalog with 4/4 approved source-owner bindings and after a preflight proves the exact deployed catalog hash and release_state=ready. The isolation credential then proves the unchanged wrong-tenant 422 and bidirectional non-enumeration. Missing credentials make only credential-dependent isolation evidence inconclusive; they cannot change catalog state or authorize a public mint route, tenant remap, copied source record, or fabricated release.

Alternatives rejected

  • Keep ITD-042 active with an unconditional 202 requirement
  • treat possession of a reviewer JWT as release evidence
  • let tests accept either 202 or 422
  • publish a token mint route while release is blocked
  • skip the deployed catalog hash preflight
  • remap the isolation tenant to the demo tenant.

Why

Separating credential availability from capability release removes the last false-success promise. The same secure automation path remains ready for promotion, while current docs and tests must assert the honest fail-closed response until owner evidence opens the gate.

Registry key: blueprint_pending_release_reviewer_credential · Back to top

ITD-050

Two-stage calibration and governed-source release

superseded
Status
superseded
Disposition
SHIP two-stage calibration and demo mastery_gate release; DEFERRED empirical revision until outcomes exist
Date
2026-07-24
Author
alphatest-triage+2026-07-17-033
supersedes
ITD-048
superseded_by
ITD-052

Chosen

governed-source-release.json schema version 4 separates initial policy calibration from post-administration empirical calibration. Initial mastery-gate creation requires, per exact tenant/source/Content version, an operator-approved and version-pinned public source/scoring-policy record, a literal equivalent_raw_score_percent target_value 100 with relation mastery_implies_at_least, the ITD-035 Content/CASE wire evidence, and an exhaustive published tested-standard inventory whose every row has a stable source code, reporting category or domain, evidence locator, DOK value or the literal value unstated, and runtime mapping disposition. Unstated source DOK is never guessed: the generated coverage row remains visibly sourceDok=unstated and can pass only when the target slot uses the highest supported DOK and the coverage proof records policy=max_supported_due_to_unstated_source_dok. Results result_record and Analytics calibration-artifact bindings are not creation prerequisites because those facts arise only after administration; requiring them before the first blueprint is circular. They remain mandatory inputs to ITD-045 calibration-delta revisions, which dereference native records and create an immutable Content successor without copying outcomes. The operator-approved STAAR Grade 5 Mathematics 2024 and Iowa Mathematics Level 11 records therefore release atomically for tenant demo when the checked-in catalog, its public-source evidence, and the dated Content/CASE evidence all validate; POST of their exact six-field references returns 202, reaches ready only after exhaustive equal-or-higher-DOK proof, and persists the literal targets in Content passing_rule. A missing inventory row, evidence locator, Content/CASE identity, target, or mapping disposition fails closed before Content write. Reopen empirical release gating for initial creation only if a published source owner makes a pre-administration calibration artifact an explicit prerequisite and two independent source programs supply it before any administration.

Alternatives rejected

  • Require Results and Analytics evidence produced by administrations before allowing the first administration
  • drop the perfect-score target until empirical data exists
  • invent native Results or Analytics ids
  • infer DOK where the public source does not state one
  • treat public documents as a replacement for Content and CASE runtime checks
  • release a catalog entry without an exhaustive tested-standard inventory
  • copy outcomes or external scores into AlphaTest

Why

The testing director can commission the first auditable gate from owner-published specifications and live Content/CASE truth, while Results and Analytics improve later immutable revisions at the point those systems actually have evidence. This removes a lifecycle deadlock without weakening the literal target, coverage proof, upstream ownership, or fail-closed behavior.

Registry key: blueprint_two_stage_calibration_release · Back to top

ITD-051

Released demo reviewer credential and proof

superseded
Status
superseded
Disposition
SHIP exact-credential 202-to-ready release proof and tenant-isolation proof
Date
2026-07-24
Author
alphatest-loop
supersedes
ITD-049
superseded_by
ITD-053

Chosen

The verification profile's BLUEPRINT_PROD_REVIEWER_JWT and BLUEPRINT_ISOLATION_REVIEWER_JWT slots are the only permitted out-of-band reviewer credential paths, each with a maximum 15-minute lifetime, least-privilege blueprint scopes, and verified tenant claims. In the same deployment revision that loads the byte-verified schema-v4 ready catalog, the demo credential must execute the exact two-source grade-5 TX mastery_gate request and require 202, follow the relative Location to ready, read back the native Content test_spec, and require a coverage row for every catalog tested-standard entry including each sourceDok=unstated row and its max-supported-DOK disposition. The isolation credential must prove wrong-tenant 422 and bidirectional non-enumeration. A missing credential makes only credential-dependent deployed evidence inconclusive; it cannot authorize a public mint route, tenant remap, environment override, copied source record, or a conditional test that accepts both 202 and 422. Any catalog hash mismatch, missing standard row, upstream failure, or proof failure blocks ready and records zero target Content writes.

Alternatives rejected

  • keep testing the superseded 422 deadlock as customer success
  • accept either 202 or 422 for the promoted fixture
  • publish a token mint route
  • remap the evaluator tenant silently
  • trust an environment catalog over the checked-in oracle
  • omit unstated-DOK coverage rows from certification

Why

The proof metric now exercises the released customer journey with the operator-supplied credential while preserving strict tenant isolation and catalog byte identity. It makes the promotion observable without letting test setup redefine product truth.

Registry key: blueprint_released_demo_reviewer_credential · Back to top

ITD-052

Authoritative public-inventory-to-Content-cell binding gate

superseded
Status
superseded
Disposition
SHIP governed inventories and fail-closed binding contract; DEFERRED 202 until 9 rows and 20 cells have owner-approved bindings
Date
2026-07-24
Author
alphatest-loop
supersedes
ITD-050
superseded_by
ITD-054

Chosen

governed-source-release.json schema version 5 keeps the operator-approved STAAR Grade 5 Mathematics 2024 and Iowa Mathematics Level 11 public inventories but blocks creation until their nine public rows are authoritatively and exhaustively bound to the positive Content source KC×DOK cells. Each PublicInventoryCellBinding is owner-approved and version-pinned and contains source_key, public_row_code, source content_test_spec_id and content_version_id, source_case_guid, source_dok, source_cell_count, binding_authority, binding_authority_version, approved_by, approved_at, and evidence_ref. The authority must be either an explicit association returned by a pinned owner endpoint/query or a testing-director-approved binding manifest; labels, reporting-category similarity, CASE item text, Content kc_coverage alone, and inferred domain alignment are forbidden. Validation proves every governed public row appears at least once, every positive Content KC×DOK cell appears exactly once, no binding names an absent row or cell, each bound count equals the Content cell count, and the pre-binding and post-binding unique-cell cardinality and total item count are identical. Positive conformance uses the exact published manifest; mutation cases remove a public row, duplicate a cell, alter a count, change a CASE GUID or DOK, add an unknown row, and change the pinned Content version, and every mutation must return typed 503 public-inventory-binding-unavailable before operation creation, local working state, or Content write. The current catalog contains zero owner-approved bindings because neither approved Content KC coverage nor CASE CFItem detail publishes the public reporting-category/domain association and no owner binding manifest has been supplied; therefore release_state is blocked_missing_public_inventory_bindings and the formerly advertised 202 quickstart is withdrawn. Reopen atomically only when all nine rows and all twenty positive Content cells pass the count-preserving manifest check in one catalog revision, then require deployed positive and mutation evidence before restoring 202.

Alternatives rejected

  • Infer public reporting categories or domains from CASE labels
  • Treat Content kc_coverage as if it contained public-row associations
  • Publish generic resolve_exhaustively_from_content_case as a completed binding
  • Map every public row to every Content cell
  • Release with only row coverage or only cell coverage
  • Accept duplicate cells when total counts happen to match
  • Keep release_state ready while the authoritative manifest is empty

Why

The public inventory and the live Content cell manifest are different owner facts. A version-pinned, count-preserving binding manifest is the smallest auditable seam that joins them without inference; blocking until it exists makes the superset claim falsifiable and prevents a target Content write from laundering an unproved crosswalk.

Registry key: blueprint_public_inventory_binding_release_gate · Back to top

ITD-053

Evaluator credential bootstrap release gate

superseded
Status
superseded
Disposition
SHIP exact credential preflight; DEFERRED credential-dependent success proof until both evaluator slots conform
Date
2026-07-24
Author
alphatest-loop
supersedes
ITD-051
superseded_by
ITD-055

Chosen

The bounded driver or CI bootstrap must populate BLUEPRINT_PROD_REVIEWER_JWT with an operator-signed JWT whose exact claims are tenantId=demo, role=reviewer, scopes equal to blueprint:read and blueprint:write with no extras, and exp-iat between 1 and 900 seconds; it must separately populate BLUEPRINT_ISOLATION_REVIEWER_JWT with tenantId=reviewer-blueprint, the same exact role/scopes/lifetime bounds, and a distinct jti or token hash. Before doer, deployed smoke, customer eval, or rubric eval starts, a credential preflight decodes both tokens without logging them, validates signature, issuer, audience, sub, role, tenant, exact scopes, iat, exp, distinctness, and current validity, and writes only a sanitized receipt with claims, lifetime, credential purpose, and pass/fail. Failure stops credential-dependent success evaluation and keeps release_state blocked; the API never remaps tenants, broadens roles, accepts the generic year-long reviewer token, mints through HTTP, or substitutes an internal smoke-only token for the environment value the independent evaluator reads. The observed 2026-07-24 environment fails this gate: BLUEPRINT_PROD_REVIEWER_JWT has tenantId=reviewer-blueprint, no scopes, and a 31,536,000-second lifetime, while BLUEPRINT_ISOLATION_REVIEWER_JWT is absent. Reopen the reviewer proof only after one bootstrap run supplies both conforming tokens before all four consumers and the sanitized receipt plus bidirectional anonymous/cross-tenant probes pass in the same deployment revision.

Alternatives rejected

  • Remap reviewer-blueprint to demo inside the API
  • Mint a different compliant token only inside deployed smoke
  • Allow a one-year reviewer token
  • Treat absent scopes as equivalent to the exact two-scope set
  • Reuse one token for positive and isolation probes
  • Expose a public demo mint endpoint
  • Let a missing isolation credential be silently inconclusive

Why

The independent evaluator consumes the environment slot directly, so bootstrap correctness is part of the released contract rather than test setup trivia. A fail-fast sanitized preflight makes the exact credential pair observable without exposing secrets and prevents internal tests from masking a broken customer-visible path.

Registry key: blueprint_reviewer_credential_bootstrap_release_gate · Back to top

ITD-054

Owner-approved public-inventory binding manifest

active
Status
active
Disposition
SHIP externally approved 9/9-row and 20/20-cell manifest with 20 unique evidence locators
Date
2026-07-24
Author
alphatest-triage+2026-07-17-033
supersedes
ITD-052
superseded_by
none

Chosen

governed-source-release.json schema version 6 publishes manifest alphatest-public-inventory-bindings-2026-07-24.v2, authorized by the independently captured alphatest-spec-owner promotion event triage decision 2026-07-17-033 (GitHub Issue 45, created 2026-07-17T13:09:14Z), not by this build run. It binds all four STAAR public reporting-category rows to all twelve positive STAAR Content KC×DOK cells and all five Iowa public-domain rows to all eight positive Iowa Content KC×DOK cells. Each of the twenty bindings has a unique binding-authority-record.json locator that names the public owner URL and page/category locator, the exact Content test_spec and immutable version, and a dated 200 Platform3 CASE read with CASE GUID, human coding scheme, full statement, owner last-change instant, source DOK, and positive cell count; every cited public-owner document also has a dated HTTP 200 application/pdf retrieval receipt with byte length and SHA-256, and the release-build verifier refetches each live URL and blocks catalog publication on dead, non-PDF, length-drifted, or hash-drifted evidence. The manifest never cites itself as evidence. Request-time validation requires 9/9 public rows, 20/20 positive cells exactly once, 20 unique external evidence locators, 20/20 binding identities live-read from Content and CASE, unique-cell cardinality 20 before and after, and total source item count 52 before and after. Missing-row, duplicate-cell, stale-version, unknown-row, count-drift, circular-or-missing evidence, inferred authority, and lower-target-DOK catalog mutations each fail with typed 503 public-inventory-binding-unavailable before operation creation, local working state, or target Content write. This decision supersedes ITD-052's empty-manifest state; the manifest gate is ready, but the catalog remains blocked_pending_reviewer_credential_preflight until the separate ITD-055 evaluator-visible credential gate passes in the same release revision.

Alternatives rejected

  • Infer category or domain membership at request time from labels
  • Accept an unversioned spreadsheet or environment-only mapping
  • Bind only the nine public rows and ignore positive Content cells
  • Bind every public row to every Content cell
  • Count duplicate bindings as coverage
  • Promote the whole release before the independent evaluator receives both bounded credentials

Why

The dated external approval event, live hash-verified public-owner receipts, and twenty independently dereferenceable Content and CASE locators remove both circular self-approval and bare-URL drift while keeping the crosswalk finite, versioned, count-preserving, and machine-checkable. The credential prerequisite remains independent and fail-closed.

Registry key: blueprint_owner_approved_public_inventory_bindings · Back to top

ITD-055

Portable evaluator credential bootstrap

superseded
Status
superseded
Disposition
SHIP portable two-token conformance bootstrap
Date
2026-07-24
Author
alphatest-loop
supersedes
ITD-053
superseded_by
ITD-056

Chosen

The repository publishes a bounded operator bootstrap and preflight contract that atomically mints BLUEPRINT_PROD_REVIEWER_JWT for tenant demo and BLUEPRINT_ISOLATION_REVIEWER_JWT for tenant reviewer-blueprint from the server-only PLATFORM_JWT_SIGNING_SECRET. Each JWT has iss=alphatest-loop, aud=alphatest-blueprint-reviewer, a nonempty sub, role=reviewer, scopes exactly [blueprint:read, blueprint:write], a unique jti, iat at mint time, and exp=iat+600 seconds. The preflight verifies both signatures and exact claims, current validity, lifetime between 1 and 900 seconds, distinct jti and token hashes, and writes only a sanitized receipt. The bootstrap is successful only when it exports both values to the same bounded driver environment before doer, deploy smoke, customer eval, and rubric eval; minting inside one smoke process or writing tokens to an artifact is failure. The release catalog advances from blocked_pending_reviewer_credential_preflight to ready only when that evaluator-visible preflight and the ITD-054 20/20 manifest validation pass against the identical catalog hash in one deployment revision.

Alternatives rejected

  • Reuse the generic year-long module reviewer token
  • Mint only the demo token
  • Mint replacement tokens inside deployed smoke
  • Write JWTs or signing secrets into evidence or the hosted site
  • Use one token for both tenants
  • Relax tenant or scope validation in the API
  • Expose an HTTP token-mint endpoint

Why

A portable, fail-fast bootstrap closes the gap between the credential contract and every independent consumer of it without weakening tenant isolation or leaking reusable credentials.

Registry key: blueprint_portable_reviewer_credential_bootstrap · Back to top

ITD-056

Ready catalog with request-scoped authentication

active
Status
active
Disposition
SHIP ready demo mastery-gate catalog and 202 create; keep auth request-scoped
Date
2026-07-25
Author
alphatest-loop
supersedes
ITD-055
superseded_by
none

Chosen

governed-source-release.json schema version 6 is ready for tenant demo because the independently approved ITD-054 manifest passes all catalog-content gates against revision 6e23e29f806a20a72e80bd266d2143e4df1ae8c6ae40bbba615fa410a4483450: 2/2 governed sources, 9/9 public inventory rows, 20/20 positive Content KC×DOK cells exactly once, 20 unique external evidence locators, 20 cells before and after, and 52 items before and after. The exact authenticated grade-5 TX mathematics mastery_gate POST therefore returns 202 and creates an operation; ready still requires live exact-version Content reads, CASE dereferences, exhaustive equal-or-higher-DOK coverage (including visible sourceDok=unstated rows using max_supported_due_to_unstated_source_dok), and one target_value=100 calibration target per source. This decision supersedes ITD-055 only where it made ephemeral evaluator credential availability a property of the immutable catalog: authentication is evaluated per request, so an invalid, expired, under-scoped, or wrong-tenant JWT fails at the normal auth boundary, while a conforming JWT may not receive reviewer-credential-preflight-required. The ITD-055 bootstrap remains the required conformance harness for fresh demo and isolation tokens before deployed smoke and both reviewer halves, and a missing isolation token makes isolation evidence inconclusive or fails the release evaluation; it does not rewrite a valid source catalog to blocked or make a valid demo request return 503. Promotion is supported by triage decision 2026-07-17-033, the operator-approved source records, the ITD-054 binding receipts, and the implementation-review observation that a conforming operator-supplied demo JWT reached the obsolete release guard and received 503 before operation creation.

Alternatives rejected

  • Keep catalog readiness coupled to whether one evaluator process currently holds unexpired short-lived tokens
  • Return reviewer-credential-preflight-required to a caller whose JWT already passed authentication and authorization
  • Remove or weaken the two-token conformance and tenant-isolation harness
  • Accept both 202 and 503 for the same ready catalog revision
  • Copy credentials or token hashes into the governed-source oracle
  • Promote without the ITD-054 9-row and 20-cell content proof

Why

Catalog content and request credentials have different lifecycles. Pinning source readiness to the immutable, operator-approved manifest while evaluating JWTs at the request boundary makes the 202 contract deterministic, preserves fail-closed authentication and tenant isolation, and prevents a passing source release from flipping to 503 merely because an evaluator token expired.

Registry key: blueprint_ready_catalog_request_scoped_auth · Back to top

Non-negotiable invariants

What downstream implementations may not reinterpret

Explicit release gates

Deferred does not mean vague

Public row bindings: satisfied

Manifest v2 is authorized by a captured event predating this run and covers 9/9 public rows and 20/20 positive Content cells with 20 unique evidence locators, preserving 20 cells and 52 items; ten mutation classes fail closed.

ITD-054

Reviewer credentials: conformance fixture

The parent driver must mint both exact, distinct short-lived tokens before deployed smoke and reviewer halves. Missing credentials fail or make that evidence inconclusive, but do not alter the ready catalog or the normal auth response.

ITD-056

Bulk create

Reopen when one registered integrator must atomically commission at least 25 blueprints in one job.

ITD-006

Webhooks

Reopen when polling blocks a registered assignment workflow or exceeds a documented rate budget.

ITD-012

Cancellation

Reopen on a reproducible erroneous request that remains nonterminal for more than five minutes.

ITD-023

List filters and sort

Reopen each field only after Content publishes it and live exact-value probes prove stable behavior.

ITD-038

Adaptive release

Reopen on independently observable exact-tenant CASE discovery, owner-typed KC, and dereference facts; then require 202 → ready → Content readback as release certification.

ITD-043

Empirical calibration revision

After administrations exist, each reports delta requires native same-tenant Results and Analytics records under ITD-045.

ITD-045

Other-tenant source release

Reopen only when that exact tenant has owner-published Content versions, CASE evidence, public inventory approval, and a reviewed binding manifest; no remapping or copying.

ITD-054

Provenance and references

Evidence-grounded, not memory-grounded

Decision set 21 · Created 2026-07-15 · Updated 2026-07-25 · Author alphatest-loop · 56 ITDs · 36 active · 20 superseded