TenantAtlas/specs/438-exchange-internal-render-model-slice-1/checklists/requirements.md

Requirements Quality Checklist: Spec 438 - Exchange Internal Render Model Slice 1

Purpose: Validate that Spec 438's requirements are complete, unambiguous, internally consistent, measurable, repo-grounded, and implementation-ready. This checklist tests the requirements writing, not the implementation. Created: 2026-07-10 Feature: spec.md

Candidate And Prerequisite Quality

• CHK001 Is the candidate source identified as directly user-provided rather than an invented queue item? [Traceability, Spec Preparation Selection Summary]
• CHK002 Is the Spec 437 prerequisite stated with merged PASS/merge-ready evidence and current HEAD? [Completeness, Spec Preparation Selection Summary]
• CHK003 Is the completed-spec guardrail explicit for Spec 422 and Specs 429-437? [Consistency, Spec Preparation Selection Summary]
• CHK004 Is the stale dev versus current platform-dev base decision disclosed? [Assumption, Spec Preparation Selection Summary]
• CHK005 Does the Candidate Check acknowledge zero current consumers and zero visible product outcome? [Clarity, Spec Spec Candidate Check]
• CHK006 Is a current-release operator workflow or real consumer demonstrated for this standalone layer? [BLOCKER: no; PROP-001, Spec Spec Candidate Check]
• CHK007 Can the topic be described as an independent current operator problem rather than a sub-operator implementation slice? [BLOCKER: no; Spec Approval Rubric Rule C, Spec Spec Candidate Check]
• CHK008 Does the candidate gate use the exact Defer classification, an evidence-based 5/12 score, and FAIL instead of allowing technical boundedness to override the constitution/rubric blocker? [Consistency, Spec Spec Candidate Check]

Scope And Proportionality Quality

• CHK009 Is exactly one local builder proposed and every broader abstraction explicitly forbidden? [Scope, Spec Proportionality Review]
• CHK010 Are the three supported resource types named exhaustively? [Completeness, Spec Functional Requirements]
• CHK011 Does the spec keep the proposal provider-owned rather than platform-core? [Consistency, Spec Provider Boundary / Platform Core Check]
• CHK012 Are persistence, enums/statuses, taxonomies, interfaces, registries, DTOs, consumers, and UI frameworks answered explicitly? [Completeness, Spec Proportionality Review]
• CHK013 Is the correct narrower path—folding the mapping into the first real consumer spec—documented? [Proportionality, Spec Spec Candidate Check]
• CHK014 Are hard stops objectively tied to scope-changing conditions? [Measurability, Spec Final Candidate Gate]

Input Contract Quality

• CHK015 Does the spec require the complete Spec 437 result envelope rather than the nested payload? [Clarity, Spec Input Contract]
• CHK016 Are all required top-level envelope fields, types, and success values enumerated? [Completeness, Spec Input Contract]
• CHK017 Are workload, nested type, shape version, compare-input marker, identity, redaction, provenance, and target sections enumerated at their exact paths? [Traceability, Spec Input Contract]
• CHK018 Is the exact comparable shape version fixed? [Clarity, Spec Input Contract]
• CHK019 Are Spec 437 comparable-hash recomputation and constant-time consistency comparison defined while explicitly stating that the unkeyed hash does not authenticate origin or provenance and requires trusted in-process composition? [Integrity, Spec Input Contract]
• CHK020 Is identity anchor validation defined without permitting anchor output? [Security, Spec Input Contract]
• CHK021 Are canonical remote-domain identity denylist rules and domain_name_is_identity=false explicit? [Security, Spec Input Contract]
• CHK022 Must inbound routing duplicates agree with canonical material values? [Consistency, Spec Input Contract]
• CHK023 Is invalid input exactly null, are recognized allowlisted fields distinguished from ignored unknown fields, and must every protected_values/sensitive_values entry pass exact marker-key-set validation without a new blocker/status taxonomy? [Clarity, Spec Input Contract]
• CHK024 Are Evidence, Resource, ResourceType, OperationRun, raw/normalized input, streams, provider response, and old-renderer fallbacks prohibited? [Coverage, Spec Forbidden Input And Fallbacks]

Output Contract Quality

• CHK025 Is the exact top-level output order and model version fixed? [Measurability, Spec Output Contract]
• CHK026 Are fixed boundary booleans distinguished from new persisted/status truth? [Clarity, Spec Output Contract]
• CHK027 Is identity presentation limited to the exact generic label and boolean? [Security, Spec Output Contract]
• CHK028 Are every target section's field names, labels, types, nullability, and order defined? [Completeness, Spec target mappings]
• CHK029 Does the spec forbid hidden metadata bags, generic pass-through, recursive output traversal, and stringification? [Completeness, Spec Functional Requirements]
• CHK030 Are identity anchors, hashes, source, and provenance validation-only and excluded from output? [Security, Spec Common Mapping Semantics]

Count, Marker, And Determinism Quality

• CHK031 Are configured-field, redacted-field, redacted-value, and presence semantics defined separately? [Clarity, Spec Common Mapping Semantics]
• CHK032 Are unknown-key counting and duplicate protected/sensitive-section counting prohibited? [Edge Case, Spec Common Mapping Semantics]
• CHK033 Is priority canonicalization defined with one output type? [Clarity, Spec Common Mapping Semantics]
• CHK034 Are safe-enum input type, canonicalization function, accepted upstream spellings, exact token-to-output map, and rejection behavior specified? [Measurability, Spec Common Mapping Semantics]
• CHK035 Is marker consistency fully defined across the exact key set, additional-key rejection, order independence, redacted, present, count, and state? [Completeness, Spec Common Mapping Semantics]
• CHK036 Are key-order, unknown-key, volatile-metadata, safe-change, and protected-change expectations measurable while preserving valid envelope hashes? [Coverage, Spec Success Criteria]

Target Mapping Quality

• CHK037 Are transportRule source sections, allowlists, safe scalars, labels, field order, and forbidden values exact? [Completeness, Spec transportRule Mapping]
• CHK038 Does the transport contract distinguish configured fields from protected value counts? [Clarity, Spec transportRule Mapping]
• CHK039 Are remoteDomain classification, all eight settings, groups, labels, field order, marker-only settings, and exact-domain exclusion specified? [Completeness, Spec remoteDomain Mapping]
• CHK040 Is auto_reply_enabled the only exact safe remote-domain setting? [Security, Spec remoteDomain Mapping]
• CHK041 Are inboundConnector material truth, routing keys, labels, field order, safe counts, and duplicate validation specified? [Completeness, Spec inboundConnector Mapping]
• CHK042 Does the connector contract exclude exact IP/domain/host/smart-host/certificate/comment/source/routing values? [Security, Spec inboundConnector Mapping]
• CHK043 Do all target mappings fail closed on malformed allowlisted data? [Edge Case, Spec Functional Requirements]

Truth, Surface, And Customer Boundary Quality

• CHK044 Is data ownership N/A because the builder accepts no record/model and performs no lookup? [Consistency, Spec Spec Scope Fields]
• CHK045 Are Evidence, Resource, ResourceType, and OperationRun immutability requirements explicit? [Completeness, Spec Evidence, Resource, And Coverage Immutability]
• CHK046 Is in-memory model availability separated from persisted CoverageLevel::Renderable? [Clarity, Spec Evidence, Resource, And Coverage Immutability]
• CHK047 Are ReadModel, old renderer, UI/routes, reports/Review Packs/PDF, CustomerOutputGate, certification, restore, and triggers out of scope? [Coverage, Spec Functional Requirements]
• CHK048 Is Product Surface Impact consistently N/A with browser and Human Product Sanity rationale? [Consistency, Spec Product Surface Impact]
• CHK049 Is OperationRun neither input, output, persistence, nor a new operation? [Consistency, Spec OperationRun UX Impact]
• CHK050 Are migration, environment, queue, scheduler, listener, storage, asset, permission, and external-call impacts all none? [Completeness, Spec Data And Migration Impact]

Test Governance And Acceptance Quality

• CHK051 Does the test classification follow proving purpose: Unit, focused Feature, Heavy-Governance/diff, Browser N/A? [Consistency, Spec Testing / Lane / Runtime Impact]
• CHK052 Are array fixtures the default and database fixtures opt-in? [Cost Control, Spec Testing / Lane / Runtime Impact]
• CHK053 Are Feature tests limited to concrete database row/attribute immutability while source, cache, filesystem, Review-Pack, report, PDF, and other side-effect absence remains explicit Heavy-Governance review? [Test Governance, tasks.md]
• CHK054 Does planned purity proof cover database, network, filesystem, logging, cache, session, events, and queues? [Coverage, tasks.md]
• CHK055 Are leakage, material-change, protected-value stability, and database immutability measurable? [Acceptance Quality, Spec Success Criteria]
• CHK056 Are regression filters, Pint, diff, changed-file, and status checks named? [Completeness, Spec Testing / Lane / Runtime Impact]
• CHK057 Are implementation-report fields and target/boundary matrices explicitly documented for this deferred close-out, with runtime work recorded as not executed in implementation-report.md? [Completeness, Spec Consumer-Owned Implementation Report Reference]
• CHK058 Are tasks explicitly reference-only and non-executable, requiring migration into a consumer-owning spec rather than reactivation through documentation or future evidence alone? [Safety, tasks.md]
• CHK059 Is there no product question blocking safe implementation? [BLOCKER: current operator workflow/consumer is unresolved; Spec Open Questions]

Review Outcome

• CHK060 Technical cross-artifact findings for approval class/score, gate-resolution wording, protected/sensitive marker validation, unknown-key semantics, hash-authentication limits, compositional protected-value wording, and Feature-vs-Heavy-Governance separation were corrected in preparation files only.
• CHK061 Review outcome is defer-or-merge-with-first-consumer, not implementation approval.
• CHK062 Any implementation-loop invocation is prohibited while the candidate/readiness gates remain FAIL.
• CHK063 No application code, test, migration, UI, route, or runtime behavior was changed during preparation.

Deferral Governance

• Candidate result recorded as FAIL / Defer / 5/12.
• Defer classification recorded in all active artifacts.
• Implementation prohibition recorded in all active artifacts (Implementation permitted: No).
• Missing runtime consumer and workflow owner documented.
• Reactivation criteria documented.
• No implementation confirmed.
• Dirty state and diff-safety recorded in implementation-report.md.
• Runtime scope and no-product-surface change confirmed.

Implementation Proof

• Implemented runtime/tests: not executed.
• Runtime implementation: not executed.
• Runtime tests: not executed.
• Browser checks: not run (no rendered UI surface changed).
• Deployment impact: none.
• Merge readiness: not merge-ready as implementation.

Preparation Result

Technical contract quality: PASS after preparation-artifact corrections. Requirements checklist: FAIL because CHK006, CHK007, and CHK059 are blocking product/constitution questions. Candidate Selection Gate: FAIL. Spec Readiness Gate: FAIL for implementation. Governance outcome: DEFERRED. Implementation outcome: NOT EXECUTED. Merge outcome: NOT APPLICABLE.

The smallest safe next action is to identify the first current internal operator consumer and fold this local transformation contract into that consumer-owning spec. No implementation behavior is proven by this checklist.