TerraWatt AI-native operating backbone

Trace every requirement to a response, an owner, and acceptance evidence.

This matrix is the evaluation companion to the technical and commercial proposal. It shows where every requested response element is answered, how Phase 1 acceptance is operationalized, and which submission inputs must still be finalized before delivery.

COVERED

Answered in the proposal

Architecture, scope, acceptance, security, models, commercials, maintenance, dependencies, and handoff.

CONFIRM

Joint discovery decision

Items that require TerraWatt evidence or a named authority before implementation.

GATE

Required before submission

Named allocation details and two qualifying references must not remain placeholders.

Evaluation rule: no item is treated as complete merely because it appears in prose. Each material claim resolves to a page, a delivery artifact, and a testable acceptance consequence.

Submission completeness

The proposal follows TerraWatt's requested response structure.

RFP requirement	Response location	Evidence supplied	Status
08.1 Architecture memo and model usage/run cost	Proposal pp. 5-6 and 14	Open ownership boundary, runtime architecture, model-selection policy, monthly run-cost band.	Covered
08.2 Fixed fee, milestones, and payment	Proposal pp. 11 and 16	90-day gates, milestone evidence, fixed Phase 1 fee, future-phase ROM.	Covered
08.3 Acceptance plan for Section 04	Proposal pp. 8-12; matrix pp. 3-4	Module criteria, test method, evidence bundle, correction and sign-off path.	Covered
08.4 Named team, bios, allocation, locations	Proposal p. 15	Delivery roles and accountability model are defined. Final names, allocation percentages, and locations require confirmation.	Submission gate
08.5 Two qualifying client references	Proposal p. 15	Reference format is reserved. Client approval and current contact details are required.	Submission gate
08.6 Live demonstration	Proposal pp. 4, 8-10 and decision session	BusinessOS operating proof with workspace modules, provenance, approvals, and governed artifacts.	Schedule
08.7 Assumptions, exclusions, dependencies	Proposal p. 17; workbook pp. 2-6	Access, authority, inventory, licensed data, policy, and decision dependencies.	Covered
08.8 Maintenance pricing and SLA	Proposal p. 18	Two support tiers, response targets, change boundaries, and ownership.	Covered
08.9 Phase 4 rough estimate	Proposal p. 16	Non-binding ROM with commercial revalidation gate.	Covered

Do not submit with placeholders: the technical response is complete enough for joint review, but Section 08.4 and 08.5 remain formal compliance risks until finalized.

Criteria become executable tests

The foundation is accepted through evidence, not feature presence.

Module	Acceptance obligation	Test method	Evidence bundle
M0 Command Intelligence	At least 95% verified cross-module answer accuracy; all gated actions surface; every Phase 1 module registers.	Run fixed question corpus by role; compare answers and citations; inject gated actions and unhealthy watcher states.	Corpus, scored results, citation trace, approval inbox log, module registry, exception report.
F0 Data Spine and Governance	Agreed active-deal inventory; at least 98% critical-date and dollar extraction; complete audit evidence; SSO and role controls.	Reconcile source inventory; blind-score labeled extraction corpus; replay access attempts; inspect provenance and audit chain.	Inventory manifest, corpus scores, access matrix, identity evidence, audit export, unresolved exceptions.
Cross-module operating contract	Every canonical object has type, source, owner, version, policy, and relationship semantics.	Trace representative deal from intake through meeting, document, decision, approval, and learned operating state.	Schema register, relationship map, lineage trace, policy record, acceptance ruling.
Security boundary	No agent or user acts beyond role, task, provider, or approval authority.	Run positive and negative permission tests; verify secret isolation; attempt prohibited writes and cross-workspace access.	Test report, access-denial logs, secret policy, approval receipts, remediation record.

CORRECTION LOOP

Failed evidence creates work

A failed criterion produces a named defect, owner, severity, corrective action, and rerun. It does not disappear into meeting notes.

SIGN-OFF

Acceptance is explicit

TerraWatt's named authority accepts, conditionally accepts, or rejects the evidence package with recorded reasons.

Real work in a controlled parallel run

Each module must survive representative TerraWatt work.

Module	Primary acceptance criteria	Test method and proof
M1 Deal State	60-day parallel run; zero missed critical dates; at least 95% verified deal-state accuracy; document-gap refresh within four hours.	Select representative active deals. Compare system state to authoritative sources and operating team judgments. Produce daily discrepancy report, date-alert evidence, and final reconciliation.
M2 Meeting Intelligence	Approved minutes within 30 minutes; at least 95% action capture; counsel-approved consent and no-consent fallback.	Run consent and fallback scenarios across approved channels. Blind-score decisions, owners, due dates, commitments, and source moments. Record human corrections.
M3 Data Room Operations	97% classification; at least 95% correct deal routing; zero lost documents; verified migration inventory; 24-hour room creation.	Use labeled historical corpus and controlled live batch. Reconcile every source item by identity and hash. Inject ambiguous documents and verify review queue, approval, filing, and receipt.
M17 Comp Intelligence	Benchmark corpus, source-rights boundary, geography, precision/recall thresholds, refresh cadence, and cost ceiling agreed at kickoff.	Audit the supplied schema and seed set. Establish labeled benchmark and duplicate-resolution rules. Test adapters, source lineage, confidence, conflicts, retractions, and human review before expansion.

M17 boundary: nationwide autonomous breadth is not represented as a day-one fixed outcome. Phase 1 funds the benchmarked intelligence track and the evidence required to authorize expansion.

Parallel-run principle: source systems remain authoritative until the acceptance authority signs the applicable cutover decision.

Close the formal gaps

Complete these actions before TerraWatt receives the final response.

DELIVERY TEAM

Confirm named contributors and accountable lead.
Add short bios relevant to this scope.
State allocation percentage and working location.
Confirm Fractal role and named architecture participation.
Approve the live-demo environment and script.

PROOF

Secure approval for two qualifying references.
Verify production agentic-system relevance.
Confirm current contact name, title, email, and phone.
Prepare one concise outcome and architecture summary per reference.
Remove all placeholders from the issued PDF.

TERRAWATT CONFIRMATION

Name executive sponsor and acceptance authorities.
Confirm Phase 1 users and operating boundary.
Confirm Azure, repository, Microsoft, and source-system owners.
Agree the M17 licensed-data and benchmark boundary.
Schedule the proposal review and live demonstration.

FINAL PACKAGE

Executive technical and commercial proposal.
RFP compliance and acceptance matrix.
Client requirements and kickoff workbook.
Live-demo access instructions.
Clean, matching HTML and PDF exports.

Issue gate: the package is ready for internal review now. It becomes submission-ready only after the named-team and client-reference requirements are complete and all assumptions are approved for issue.