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
Architecture decision record · integrator API · fail-closed contract
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.
Customer and job
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
test_spec, list/detail identity, versionsPredictable before client code
test_spec versions from Content and every standard/mapping from CASE.content_kind=test_spec.POST /v1/blueprints→GET ./operations/{id}→GET /v1/blueprints/{content_test_spec_id}+GET …/coverageCertification index
Only active ITDs govern this table. Superseded ITDs remain below as linked audit history.
| Axis | Contract | Governing ITD | State |
|---|---|---|---|
| Write granularity | One customer create plus one reports-only immutable calibration successor; no update/delete; bulk has a threshold | ITD-006 · ITD-026 · ITD-045 | PINNED |
| Read shape | List, detail, coverage, operation, and calibration revision receipt; list is wire-faithful | ITD-037 · ITD-027 · ITD-044 · ITD-045 | PINNED |
| Query model | Verified filter subset, opaque cursor, upstream order | ITD-038 | PINNED |
| Concurrency | Immutable ready specs, exact-base ordered calibration successors, replacement by supersession, ETag reads | ITD-009 · ITD-045 | PINNED |
| Idempotency | Required tenant+route key; deterministic create and calibration-delta replay | ITD-010 · ITD-026 · ITD-045 · ITD-046 | PINNED |
| Auth shape | Verified JWT role maximum; authentication is request-scoped; a portable fail-fast two-slot bootstrap gates reviewer conformance evidence; reports-only calibration scope | ITD-028 · ITD-045 · ITD-047 · ITD-056 | PINNED |
| Eventing | Polling and modifiedSince; webhook trigger is explicit | ITD-012 | PINNED |
| Error envelope | Typed RFC 9457 problems with stable precedence | ITD-013 | PINNED |
| Tenant routing | Verified JWT tenant only; no caller-selected tenant | ITD-014 | PINNED |
| Conformance evidence | Real 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 release | ITD-015 · ITD-031 · ITD-035 · ITD-044 · ITD-045 · ITD-046 · ITD-054 · ITD-056 | PINNED |
| Privacy / retention | 30-day working evidence; upstream records remain upstream | ITD-016 | PINNED |
| List endpoints | One Content-backed collection; no remembered-id index | ITD-037 · ITD-038 | PINNED |
One selector, one lifecycle
mastery_gateRequires 1–50 immutable governed source assessment references, highest-rigor allocation, complete union coverage, and binary mastery criteria.
adaptive_diagnosticRemains 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.
formativeRequires a bounded unit standard set and immediate per-standard criteria through the same blueprint resource and operation lifecycle.
Audit-grade mechanism
source_key
content_test_spec_id + content_version_id
source CASE GUID + source DOK + item_count
target CASE GUID + association provenance
blueprint slot + required DOKFail 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
metric=equivalent_raw_score_percent, target_value=100, and relation=mastery_implies_at_least are mandatory.passing_rule owns the targets; detail and coverage reads project them without reinterpretation.POST /v1/blueprints/{id}/calibration-deltas is reports-service only, same-tenant, idempotent, and exact-base ordered.test_spec linked by supersedes; history is never mutated.Reports delta + native evidence→202 operation→new Content test_spec version→before/after revision receiptAutonomous 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
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 evidenceLifecycle integrity
008 → 034 → 038 wire-verified filters
011 → 047 complete customer plus reports-service authorization
017 → 039 → 041 → 043 full three-kind truth and non-circular adaptive gate
029 → 040 one-origin, mount-safe operation URLs
030 → 035 immutable Content identity
032 → 033 → 036 → 048 → 050 → 052 → 054 governed sources with an approved exhaustive public-row binding manifest
042 → 049 → 051 → 053 → 055 → 056 portable evaluator credentials with request-scoped auth and deterministic catalog readiness
Numbered decision corpus
Search by axis, endpoint, registry key, or contract phrase. Every record has a stable permalink, lifecycle provenance, rejected alternatives, and rationale.
No ITDs match this filter.
Platform3 Content test_spec is the blueprint of record; CASE is the standards authority; AlphaTest stores only tenant-scoped crosswalk work and evidence references.
One authoritative id removes translation glue and prevents drift while preserving AlphaTest's orchestration seam.
Registry key: blueprint_systems_of_record · Back to top
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.
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
A required test_kind selects mastery_gate, adaptive_diagnostic, or formative within one blueprint resource and one lifecycle.
One integration path preserves common provenance while kind-specific validation keeps each promise explicit.
Registry key: blueprint_test_kind_selector · Back to top
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.
“Superset” is a universal claim. A partial result cannot silently satisfy it.
Registry key: blueprint_fail_closed_superset · Back to top
Normalized request plus immutable CASE source revisions and policy version deterministically produce ordered blueprint slots, distributions, and criteria.
Audit replay and parallel-form equivalence need the same facts to yield the same plan.
Registry key: blueprint_deterministic_allocation · Back to top
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.
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
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.
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
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.
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
Ready blueprints are immutable; corrections create a new blueprint linked by supersedes; GET responses emit ETag and honor If-None-Match.
Evidence must continue to describe the exact blueprint used by a bank or attempt.
Registry key: blueprint_immutable_ready_specs · Back to top
Idempotency-Key is required on POST, scoped to tenant plus route, retained 24 hours, and rejects key reuse with a different canonical body.
Retries cannot commission duplicate expensive work, while mismatched reuse is visible.
Registry key: blueprint_idempotent_create · Back to top
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.
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
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.
Polling completes today’s one-afternoon integration; webhooks would add signing, retries, ordering, and endpoint administration.
Registry key: blueprint_poll_eventing · Back to top
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.
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
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.
A caller cannot ask to cross a tenant boundary, eliminating confused-deputy routing.
Registry key: blueprint_jwt_tenant_routing · Back to top
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.
The product’s value depends on real upstream composition, which identical local behavior cannot prove.
Registry key: blueprint_upstream_conformance · Back to top
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.
Thirty days supports replay and incident diagnosis without creating another durable standards store.
Registry key: blueprint_working_artifact_retention · Back to top
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.
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
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.
The bank needs executable constraints and the reviewer needs a row-level proof, not an aspiration.
Registry key: blueprint_executable_slots · Back to top
Public blueprint ids are Platform3 Content test_spec ids, standards are CASE GUIDs, and AlphaTest operation ids are opaque UUIDs used only for orchestration.
Native ids pass directly into downstream modules; opaque operation ids do not leak routing.
Registry key: blueprint_platform_native_ids · Back to top
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.
Path versions are visible in copied examples, while additive evolution avoids needless client churn.
Registry key: blueprint_path_versioning · Back to top
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.
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
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.
Operators can prove calls and diagnose latency without creating a secret or tenant-data exhaust.
Registry key: blueprint_safe_observability · Back to top
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
ready operation always dereferences to the Content-owned blueprint of record.Explicit release gates
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-054The 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-056Reopen when one registered integrator must atomically commission at least 25 blueprints in one job.
ITD-006Reopen when polling blocks a registered assignment workflow or exceeds a documented rate budget.
ITD-012Reopen on a reproducible erroneous request that remains nonterminal for more than five minutes.
ITD-023Reopen each field only after Content publishes it and live exact-value probes prove stable behavior.
ITD-038Reopen on independently observable exact-tenant CASE discovery, owner-typed KC, and dereference facts; then require 202 → ready → Content readback as release certification.
ITD-043After administrations exist, each reports delta requires native same-tenant Results and Analytics records under ITD-045.
ITD-045Reopen 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-054Provenance and references
commitments.json — Mode A registry sidecar; every Chosen paragraph is rendered verbatim from it.Decision set 21 · Created 2026-07-15 · Updated 2026-07-25 · Author alphatest-loop · 56 ITDs · 36 active · 20 superseded