# TerraWatt AI-Native Operating Backbone ## Internal RFP Analysis and Response Strategy **Source:** `TerraWatt_AI_Backbone_Scope_v2_2.pdf` **Issued:** July 20, 2026 **Received by email:** July 27, 2026 **Response instruction:** Due within ten business days of receipt **Internal submission target:** August 7, 2026 **Deadline control:** Confirm whether TerraWatt interprets the formal deadline as August 7 or August 10 during the clarification call. **Prepared for:** MIOSA + Fractal internal review **Status:** Decision brief, not a client proposal ## What Royden's Email Changes Royden's transmittal email does not change the technical verdict. It improves our procedural position in five ways. 1. TerraWatt explicitly describes the attached document as the full RFP and directs respondents to Section 08. 2. TerraWatt explicitly permits alternatives to bracketed assumptions when the respondent explains why the alternative is better. 3. TerraWatt offers a 30-minute clarification meeting before the response is finalized. 4. The response clock is tied to the July 27 receipt email rather than only to the July 20 issue date printed in the RFP. 5. Royden signs the email under Acquisitions, which means procurement authority, operating sponsorship, and final acceptance authority should not be assumed to belong to the same person. The email strengthens the qualified-response strategy. We should not treat the invitation to propose alternatives as permission to ignore mandatory requirements. We should use it to propose evidence-based changes to bracketed volumes, timing, sequencing, thresholds, staffing assumptions, and acceptance design. The clarification meeting should be treated as a formal requirements session. MIOSA should send a short prioritized question list before the meeting, record the answers, and cite those answers as proposal assumptions where relevant. ## The Plain-Language Answer TerraWatt described one immediate operational problem in the July 17 meeting. The RFP then expanded that problem into a long-term company operating model. Those must be understood separately. ### What Royden originally asked us to solve Royden was explicit about the immediate job. TerraWatt has roughly 200 data rooms, from a few files to thousands of files per room. Royden and one administrator currently maintain those rooms. Royden receives roughly 200 emails per day, with approximately 75 containing documents that may need to be filed. He wants a system that: 1. Standardizes the structure and naming conventions across TerraWatt's existing data rooms. 2. Lets a user place an email or document into a known intake path. 3. Identifies the correct deal and document class. 4. Renames the document according to TerraWatt's convention. 5. Proposes where it should be filed. 6. Lets a human approve or correct the proposal. 7. Files or copies the approved document into the correct OneDrive location. 8. Updates the applicable internal and counterparty data-room trackers. 9. Preserves a complete record of what happened. 10. Never loses, silently deletes, or misroutes a source document. Royden specifically said TerraWatt is not asking us to improve site sourcing. He knows how to find sites. The present pain is data-room hygiene, document handling, tracker maintenance, and the administrative burden that prevents him from focusing on deals. ### What Royden described as the next layer After the document estate becomes structured and trustworthy, Royden wants the system to understand: - the stage of every deal; - which documents are present; - which documents are missing; - which agreement creates each deadline; - how much time remains; - who is responsible; - what changed; - what requires a human decision. This is the deal-state and diligence intelligence layer. It depends on the first data-room loop being correct. It cannot be trusted if the document taxonomy, deal identity, extraction, provenance, and review process are unreliable. ### What Royden clarified on July 22 before sending the RFP The short July 22 call was an NDA and procurement transition call, but Royden also supplied important executive intent. He said the original data-room concept had become approximately 20 percent of the first of four conceptual modules. That statement describes the scale of the expansion at that moment. It should not be treated as the final module architecture because the later written RFP defines a more detailed foundation and M0 through M17 roadmap. Royden described TerraWatt's desired operating model as: - AI-native from the ground up; - a lean company of approximately 15 people capable of operating at very large enterprise scale; - minimal middle-management overhead; - founders focused on judgment and high-value problem solving; - deterministic administrative work delegated to governed systems; - overarching agents coordinating bounded sub-agents; - model and tool replaceability as better capabilities become available; - accountable delivery by a team that understands architecture, permissions, data safety, and execution. He also made the procurement status clear: - TerraWatt was preparing a formal competitive RFP; - multiple groups would be invited to respond; - he preferred the alignment with our team but had not awarded the engagement; - the NDA had to be executed before TerraWatt shared the expanded scope; - the next substantive meeting would occur after our team reviewed the RFP. The strongest buying signal was not interest in a particular model or interface. It was Royden's desire for an accountable implementation partner who could build the system correctly and prevent the expensive failure modes he associated with inexperienced AI development. ### What the formal RFP now asks for The RFP is substantially broader than the original meeting. It asks for an AI-native operating backbone across acquisition, development, leasing, finance, meetings, reporting, bookkeeping, market intelligence, construction, and public affairs. It combines five platform-level capabilities: 1. An authoritative PostgreSQL-backed operating record for deals, sites, parcels, entities, contacts, documents, obligations, critical dates, tasks, and financial items. 2. Governed ingestion from Outlook, Teams, SharePoint, and OneDrive through Microsoft Graph, including OCR, classification, extraction, and source citations. 3. Versioned company playbooks that agents can execute. 4. A governed agent fleet with identity, permissions, approval gates, audit history, and replaceable models. 5. One executive command surface for questions, approvals, alerts, summaries, and institutional memory. It then defines a roadmap of foundation capabilities and modules M0 through M17. That is not merely a data-room automation. It is a company operating model expressed as software. ## Annotated RFP Walkthrough This section follows TerraWatt's v2.2 document from top to bottom. It translates each section into four internal questions: 1. What are they saying? 2. What does it mean operationally? 3. What should MIOSA and Fractal accept, qualify, or reject? 4. What must be resolved before a binding SOW? ### Cover and procurement instructions **What they say:** TerraWatt is buying a phased, fixed-fee AI-native operating backbone. The response must follow Section 08. Bracketed assumptions A1 through A10 may be challenged with a priced alternative and rationale. The program is phase-gated and is not intended to become an open-ended platform engagement. **Our interpretation:** This is a competitive procurement document, not a final implementation specification. We must answer their requested format completely while using paid discovery to convert assumptions into evidence. **Our response:** Accept the phase-gated commercial structure. Provide a fixed discovery fee, a non-binding implementation range, explicit variance rules, and a method for creating the binding Phase 1 SOW. **Clarify:** Confirm whether the response deadline is August 7 or August 10, 2026. ### Section 00 - Purpose and use of the document **What they say:** The selected vendor will design, build, and transfer the company operating system. All code, prompts, schemas, and documentation are described as TerraWatt property from day one. Vendor independence is mandatory, and vendor-proprietary dependencies are disallowed. **Our interpretation:** TerraWatt wants control, portability, continuity, and protection from delivery-vendor lock-in. The language currently combines TerraWatt-funded custom work, open-source components, paid platform services, partner technology, and third-party services as though they were one ownership category. **Our response:** Accept TerraWatt ownership of its data and expressly commissioned TerraWatt-specific work. Preserve the published licenses of BusinessOS and Optimal Engine. Preserve MIOSA and Fractal ownership of pre-existing technology, generic infrastructure, reusable methods, and separately licensed products. Give TerraWatt documented export, transition, repository, configuration, and operational continuity rights. **Clarify:** Agree an intellectual-property schedule before the binding SOW. ### Section 01 - Company context **What they say:** TerraWatt is a lean, well-capitalized data-center developer operating across multiple states. It wants agents to become the default doer while humans retain judgment, relationships, signatures, and capital decisions. Current systems are primarily Microsoft 365, Claude, landID, and spreadsheets. **Our interpretation:** The business objective is operating leverage. TerraWatt wants a small principal team to control a large development portfolio without building a proportionally large administrative organization. **Our response:** Design the system around named decision owners, governed delegation, and evidence-backed automation. Reduce coordination overhead without removing accountable human authority. **Clarify:** Obtain the actual organization chart, deal portfolio, user roster, external advisor map, and current system inventory. ### Section 02 - Operating principles | TerraWatt principle | Internal translation | MIOSA + Fractal response | |---|---|---| | Agent-default, human-approve | Automate preparation and execution while reserving consequential judgment | Accept, but define action classes and named approvers | | One data spine | Email, chat, and spreadsheets cannot remain competing sources of truth | Accept PostgreSQL as transactional truth, with documents and evidence linked rather than duplicated blindly | | Playbooks as code | Company standards must be versioned, executable, and reusable | Accept through governed playbooks, policies, examples, and acceptance tests | | Gated autonomy | External actions require approval | Accept and enforce through policy, identity, and execution receipts | | Least privilege, full audit | Every agent and connector receives bounded access and produces evidence | Accept as a foundation requirement | | Speed to production | Working value must ship in 90-day cycles | Accept the cycle, but narrow the first release to a feasible operating loop | **Clarify:** Define which internal state changes may post automatically and which require approval. ### Section 03 - Target architecture | RFP layer | What they intend | Proposed implementation | |---|---|---| | System of record | Authoritative structured company state | PostgreSQL schemas for deals, sites, entities, documents, obligations, dates, tasks, approvals, and financial records | | Ingestion | Microsoft 365 content becomes governed records | Microsoft Graph intake, immutable originals, OCR, parsing, classification, claims, citations, and review | | Playbook and memory | Durable company standards and institutional knowledge | Optimal Engine plus versioned playbooks, accepted facts, decisions, and context packages | | Agent fleet | Specialized agents execute bounded company work | Governed tools and agents registered to roles, policies, workspaces, and acceptance tests | | Governance | Identity, permissions, approvals, audit, and injection resistance | Entra ID, scoped credentials, policy gates, append-only receipts, and isolated execution | | Interfaces | One front door plus dashboards, alerts, and digests | BusinessOS modules, M0 command surface, approval inbox, portfolio views, and notifications | **Our interpretation:** Their six-layer model is directionally compatible with BusinessOS, Optimal Engine, MIOSA, and Fractal. The architecture memo must show clear authoritative-store boundaries and must not imply that a language model, vector index, or memory store is the transactional source of truth. **Clarify:** Confirm Azure ownership, network restrictions, tenant structure, identity administration, residency, backup boundary, and permitted external services. ### Section 04 - Module specifications #### Phase 1 modules | Module | What TerraWatt is asking for | Our annotation | |---|---|---| | M0 Command Intelligence | One conversational interface across all modules, approvals, briefs, and institutional memory | Build a minimal M0 over accepted Phase 1 records first. Its accuracy cannot exceed the quality of the underlying data | | F0 Foundation | Schema, ingestion, identity, governance, approvals, alerts, and migration of all active deals | Required foundation. Binding price and schedule require a discovered inventory, taxonomy, permission model, and migration band | | M1 Deal State | Lifecycle, onboarding, critical dates, closing conditions, missing documents, history, answers, and digests | High-value second layer. Start with one representative deal type after F0 and M3 become reliable | | M2 Meeting Intelligence | Consent-aware recording, transcription, minutes, action items, and deal updates | Useful but legally dependent. Launch only after counsel approves the consent and no-recording fallback policy | | M3 Data Room Operations | Migrate, classify, route, index, restructure, synchronize, and track internal and counterparty rooms | This is the closest match to Royden's original request and should be the first complete production workflow | | M17 Comp Intelligence | Nationwide parcel and data-center comp monitoring with autonomous correction | Treat as a separate data-product proof. Source rights, source coverage, denominators, locality, and correction policy are not yet known | **Phase 1 conclusion:** F0, M3 core, bounded M1, and minimal M0 form one coherent first release. M2 should be conditional on legal policy. M17 should have its own feasibility and source-coverage gate. #### Phase 2 modules | Module | What TerraWatt is asking for | Our annotation | |---|---|---| | M4 Acquisitions and Contracts | Clause extraction, comparison, drafting, redlines, and closing support | Counsel-supervised assistance only. Build against approved templates and a legal benchmark corpus | | M5 Preliminary Zoning | Automated jurisdiction research and initial zoning conclusions | Position as a cited pre-screen, not an authoritative legal determination | | M6 Preliminary Utility Verification | Initial power, gas, water, and telecommunications research | Position as preliminary evidence assembly. Public records do not prove capacity or a service commitment | | M7 Site Intelligence Production | Branded reports assembled rapidly from upstream findings | Strong after M5 and M6 sources and review standards are accepted | | M8 Contact Intelligence | Contact and ownership data with human-initiated outreach | Requires TerraWatt-funded compliant data sources, provenance, and outreach policy | | M10 Monitoring Mesh | Watch projects, markets, filings, competitors, and risks | Requires a source registry, watcher-health controls, coverage denominators, and seeded tests | | M13 Deal, Lease, and Capital Models | Repeatable financial models based on company templates | Use deterministic calculations, formula tests, versioned assumptions, and cited inputs | **Phase 2 conclusion:** These are separate operating loops, not simple features added to Phase 1. Each needs a named owner, source inventory, acceptance corpus, and module-specific SOW. #### Phase 3 modules | Module | What TerraWatt is asking for | Our annotation | |---|---|---| | M9 Pre-Development and Entitlement | Entitlement workflow, document assembly, schedules, and risk tracking | Support the workflow and evidence. Do not automate legal or professional conclusions | | M11 Admin and Communications | Inbox, scheduling, drafting, prioritization, and internal coordination | Strong fit with restricted permissions, prompt-injection controls, and draft-only external communications | | M12 Leasing and Capital Reporting | Obligation-aware reporting and investor deliverables | Build only after executed agreements and obligations are reliably modeled | | M14 Accounting and Bookkeeping | Categorization, ledgers, reconciliation, and close packages | Accountant-supervised. Exclude payment authority, tax conclusions, filing authority, and bank credentials | #### Phase 4 modules | Module | What TerraWatt is asking for | Our annotation | |---|---|---| | M15 Development Operating System | Procurement, schedule risk, RFIs, pay applications, and commissioning | A separate construction-domain program requiring its own discovery, integrations, references, and SOW | | M16 Public Affairs and Narrative | Monitoring, content production, rapid response, stakeholder support, and measurement | Feasible with strict sourcing, attribution, platform compliance, reputational controls, and human publication approval | ### Section 05 - Phasing and milestones **What they say:** Phase 1 runs from day 0 to day 90. Phase 2 begins at day 60, while Phase 1 is still underway. Later phases add the remaining modules, and TerraWatt may re-sequence modules at gates. **Our interpretation:** The schedule conflicts with its own kill-or-continue gate. M1's required 60-day parallel run inside a 90-day phase also creates an unstated production-readiness deadline around day 30. **Our response:** Propose discovery, Phase 1A foundation and data-room loop, Phase 1B deal-state expansion, and a separately gated M17 proof. Overlap occurs only through written authorization when dependencies and acceptance responsibilities are understood. **Clarify:** Define whether re-sequencing can change price, staffing, dependencies, and acceptance effort. ### Section 06 - Non-functional requirements | Requirement group | What it means | Our response | |---|---|---| | Security and privacy | SSO, MFA, RBAC, encryption, scoped credentials, immutable audit, DPA, and no model training | Accept, with a formal threat model and responsibility matrix | | Excluded actions | No wire, banking, payment, or signature authority | Accept without exception | | Archive-only lifecycle | Agents cannot delete, and superseded state remains recoverable | Accept the intent, but also control update, move, overwrite, synchronization, and retention behavior | | Isolated immutable backup | The recovery estate must be unreachable by normal runtime credentials | Accept, and add an explicit recovery-time objective and restore ownership | | Hosting and compliance | Azure default and future SOC 2 readiness | Accept Azure as the default subject to discovery | | Reliability | No silent failures and graceful human fallback | Accept with watcher-of-watchers, durable operations, retries, dead letters, and service evidence | | Upgradeability | Models and modules must be replaceable through a permanent evaluation harness | Accept, but require interface contracts, fixtures, migration tests, rollback, and behavioral equivalence | | Learning loops | Human corrections update owned playbooks and examples rather than hidden model weights | Strong alignment with Optimal Engine's source, claim, fact, memory, and observation lifecycle | | Ownership and transfer | TerraWatt wants repositories, documentation, handoff, and independence | Accept for TerraWatt-specific work and data, subject to the ownership classification schedule | | Enablement | The team must use the system as the default way of working | Include training, operating procedures, adoption metrics, and standing ruling sessions | ### Section 07 - Commercial terms **What they say:** Every phase is fixed-fee, milestone-based, acceptance-tested, transferable, documented, and terminable at the gate. They require a named team, maintenance pricing, data protection, full transfer, and no open-ended pricing. **Our response:** Accept fixed-fee delivery after paid discovery establishes the inputs, migration band, dependencies, acceptance corpus, and client responsibilities. Present MIOSA and Fractal as the joint named delivery team. Attach a background-technology and licensing schedule. Price support and quarterly capability reviews separately from implementation milestones. **Clarify:** Define payment timing, acceptance review windows, deemed acceptance, dependency delays, change control, warranty, liability, and termination assistance. ### Section 08 - Vendor response requirements Our submission must contain all nine requested items: 1. Architecture memo against Section 03, including model usage and projected run costs. 2. Fixed fee by phase, milestone schedule, and payment terms. 3. Acceptance plan responding to every Section 04 criterion. 4. Named MIOSA and Fractal team with biographies, allocation percentages, locations, and responsibilities. 5. Two qualifying production references from organizations with fewer than 100 employees. 6. A live demonstration of a shipped agentic system. 7. Assumptions, exclusions, and dependencies. 8. Maintenance retainer pricing and service levels. 9. Non-binding Phase 4 estimate for M15 and M16. **Our interpretation:** Missing one item can remove us from consideration. The initial submission should remain non-binding where their own process says paid discovery produces the binding Phase 1 SOW. ### Section 09 - Assumptions and open items | Assumption | TerraWatt's working position | Our response | |---|---|---| | A1 | Scope covers acquisition through development, leasing, finance, bookkeeping, and public affairs; HR excluded | Accept as roadmap boundary, not one immediate implementation scope | | A2 | Systems inventory is provisional | Require final inventory and access validation during discovery | | A3 | Every external communication is draft-for-approval | Accept and encode as policy | | A4 | Six internal launch users plus designated external read access | Validate identities, roles, external users, and separation of duties | | A5 | Counterparty rooms enter scope in Phase 2 | Accept after internal M3 core is proven | | A6 | TerraWatt will license contact and ownership data | Accept subject to source rights, coverage, and compliance | | A7 | Phase 1 includes deal core plus M17 | Propose a separate M17 proof and gate | | A8 | Zero missed critical dates and accurate deal-state answers are primary metrics | Accept only with defined denominators, source boundaries, client duties, and incident rules | | A9 | Azure default and SOC 2 readiness in year two | Accept subject to a jointly approved control roadmap | | A10 | Phase 1 live within 90 days | Propose a bounded release that can actually complete acceptance inside 90 days | ### Appendix A - Working systems inventory **What they say:** Microsoft 365, Claude, landID, spreadsheets, OneDrive data rooms, and Teams form the present environment. E-signature is unknown. Accounting is not yet established. **Our interpretation:** The inventory is incomplete and cannot support binding integration or migration commitments. **Our response:** Discovery must produce a verified system register with owners, contracts, APIs, credentials, data volumes, retention rules, source quality, export rights, and known failure modes. **Clarify:** Identify every spreadsheet, OneDrive room, SharePoint site, mailbox, Teams environment, external data source, advisor-controlled system, e-signature service, and future accounting platform. ## What TerraWatt Actually Needs TerraWatt does not need us to begin by building every module in the RFP. It needs a controlled path from one painful workflow to a dependable company backbone. ### 1. A discovery process that models the real work Before implementation, TerraWatt must show us: - the current folder structures; - representative data rooms at different deal stages; - naming rules and exceptions; - the current data-room trackers; - counterparty room indexes; - representative inbound emails and attachments; - the required final outputs; - the people who perform, review, and approve the work; - the source documents that create deadlines and obligations; - the errors that are unacceptable; - the systems and credentials involved. We then work backward from the approved output to the inputs and process. This is not generic consulting overhead. It is how we encode TerraWatt's actual operating method instead of guessing it. ### 2. One complete production loop The first implementation should prove: ```text Outlook or OneDrive source -> immutable intake record -> deal and workspace resolution -> document classification -> extraction with source evidence -> human review -> approved filing -> tracker update -> audit receipt -> searchable deal context ``` The pilot should cover one representative deal type and a small set of real data rooms. It should run in parallel with the current process before any broad migration. ### 3. A governed operating model, not an autonomous black box Most of the workflow should be deterministic. Identity matching, naming, routing, versioning, tracker updates, permission checks, and audit receipts should use code, rules, and state machines. Models should help with bounded classification, extraction, summarization, and ambiguous cases. Low-confidence or consequential actions must go to a human. This matches Royden's stated preference to review where a document will go before the system commits the action. The July 22 goal of reducing middle-management overhead should be implemented as better operating leverage, not as the literal removal of human accountability. The system still needs named decision owners, escalation paths, approval authorities, exception handling, and separation of duties. The target is fewer coordination layers and less administrative work, not an organization governed by unsupervised agents. ### 4. A staged expansion path After the first loop is accepted: 1. Expand the taxonomy and migration coverage. 2. Build deal-state and critical-date intelligence. 3. Add portfolio views, digests, and executive questions. 4. Add meeting intelligence only after consent and legal policy are approved. 5. Evaluate M17 as a separate national data product. 6. Add later departmental modules only when their source systems, owners, and acceptance tests are known. ## Executive Verdict The target is technically achievable as a staged program. The RFP is ambitious, not delusional. The requested Phase 1 is not responsibly deliverable exactly as written in 90 days under an unconditional fixed fee. The right answer is a qualified yes: 1. Accept the operating vision and security principles. 2. Use TerraWatt's authorized paid discovery sprint to model the real operating system and create the binding SOW. 3. Narrow the first production release to F0, M3, a bounded M1, and a minimal M0. 4. Treat M17 as a separate data-product workstream with a source-coverage and feasibility gate. 5. Separate open-source software, paid MIOSA platform services, Fractal's joint delivery role, any separately licensed Fractal technology, third-party services, and TerraWatt-specific implementation. 6. Give TerraWatt ownership and control of its data, taxonomy, playbooks, configurations, mappings, acceptance corpus, and expressly commissioned client-specific work. 7. Price the requested program as a multi-phase enterprise implementation rather than a small automation build. The core problem is not feasibility. The core problem is sequencing and contractual precision. The RFP compresses a multi-phase operating transformation into acceptance language that assumes the taxonomy, source rights, benchmarks, security design, and operational truth are already known. They are not. ## How Far The Scope Expanded The original working problem was focused: - approximately 200 data rooms; - approximately 20 GB of documents; - high-volume Outlook attachments; - inconsistent filing and naming; - spreadsheet trackers; - missing-document detection; - deadline and deal-state visibility; - human approval before consequential action. The RFP now includes: - company-wide deal intelligence; - meeting recording and consent management; - nationwide transaction intelligence; - contract drafting and redline analysis; - zoning and utility research; - site report production; - contact intelligence; - legislative and regulatory monitoring; - acquisition, lease, and capital models; - entitlement operations; - executive inbox and calendar assistance; - investor reporting; - bookkeeping; - construction operations; - public affairs and narrative response. That is a legitimate roadmap. It is not one first-phase application. ## Fit With The MIOSA Stack ### BusinessOS BusinessOS should be the open-source human operating surface that is customized for TerraWatt. It should provide: - command and search; - deal and portfolio views; - approval inbox; - document review queue; - critical-date ledger; - data-room completeness; - module-specific work surfaces; - administration and policy controls; - operational evidence and health. BusinessOS must not become a second source of truth. It projects governed records from the Optimal Engine and the authoritative transactional spine. TerraWatt is not being asked to purchase ownership of BusinessOS. It can use and modify the published open-source layer under its applicable release license. The proposal must attach the exact BusinessOS license and identify any premium MIOSA-only features separately. ### Optimal Engine Optimal Engine should be the governed context and memory plane. It should manage: - organization, workspace, node, role, person, project, process, and task scope; - source packages; - signals; - claims; - reviewed facts; - decisions; - memory objects; - context packages; - retrieval and citations; - policy-aware context assembly; - observations and pending claims; - learning from human corrections. It is the right layer for M0 cross-module context and durable institutional memory. It is not the only database and should not replace PostgreSQL, OneDrive, or the audit ledger. Optimal Engine is verified in the current codebase as MIT-licensed open-source software. TerraWatt can run it in TerraWatt-controlled infrastructure, inspect it, modify it, and retain its data without transferring MIOSA ownership. ### MIOSA platform and deployment control MIOSA can provide: - isolated runtimes; - immutable application releases; - exact promotion and rollback; - secret and connector bindings; - execution receipts; - deployment evidence; - local, customer-cloud, or managed placement; - customer-specific applications and modules. For this RFP, the default design should place the TerraWatt production environment inside TerraWatt-controlled Azure infrastructure. MIOSA is the paid platform and operating service around the open-source foundation. The commercial relationship is analogous to using a deployment platform such as Vercel: - TerraWatt pays to use MIOSA capabilities and support; - TerraWatt retains its data and client-specific work product; - open-source components keep their upstream licenses; - MIOSA platform source, control-plane code, generic deployment infrastructure, and service operations are not assigned to TerraWatt; - TerraWatt must have an export and transition path for its applications, configurations, data, and repositories. MIOSA can deploy and operate TerraWatt's application in TerraWatt-controlled Azure or another approved placement. The response should satisfy TerraWatt's anti-lock-in goal through portability, documented interfaces, exportability, and customer-controlled accounts rather than pretending no paid platform service exists. ### Fractal Fractal is part of the joint delivery team for the TerraWatt program. MIOSA and Fractal should be presented as collaborating partners with explicit responsibilities, shared delivery governance, and one coordinated plan. Fractal's people and enterprise architecture expertise are part of the engagement even if the first production loop does not require every Fractal technology capability. At TerraWatt's current size, approximately 20 GB and six launch users do not independently justify making a specialized distributed data product mandatory on day one. Fractal becomes especially valuable as the program expands into: - national monitoring and comp intelligence; - high-volume event and assertion graphs; - large cross-source digital twins; - data locality requirements; - customer-controlled distributed compute; - regulated or very large enterprise deployments; - significant analytical workloads across many deals and external datasets. The responsible position is: > MIOSA and Fractal jointly deliver the TerraWatt program. Discovery assigns concrete ownership across application, data, infrastructure, governance, and operations. Any separately licensed Fractal technology is activated only where the approved architecture requires it. ### The commercial layers must remain separate | Layer | What TerraWatt receives | Commercial treatment | |---|---|---| | BusinessOS | Open-source user interface and application foundation, configured for TerraWatt | Upstream license, no IP sale | | Optimal Engine | Open-source context, memory, and retrieval engine | MIT license, no IP sale | | MIOSA | Deployment, runtime, release, secrets, environment, evidence, support, and platform operations | Paid platform subscription and services | | Fractal | Joint architecture and delivery participation, plus any selected Fractal technology | Delivery role included in the team structure; specific product licenses disclosed separately when applicable | | TerraWatt implementation | Taxonomy, workflows, modules, mappings, acceptance tests, infrastructure definitions, and client-specific application behavior | Fixed-fee commissioned work under the SOW | | TerraWatt data | Source documents, records, feedback, operational history, and outputs | TerraWatt-owned | | Third-party services | Microsoft, Azure, Claude, data providers, OCR, and other approved dependencies | TerraWatt or project account under vendor terms | ## What Exists Already And What Must Be Built TerraWatt is not paying us to invent an operating-system foundation from zero. It is paying us to apply, configure, extend, and operate an existing foundation against TerraWatt's real company. | Capability | Existing foundation | TerraWatt-specific work | |---|---|---| | User interface | BusinessOS modules, workspace model, command surfaces, review patterns | TerraWatt deal, data-room, approval, portfolio, and administration modules | | Context and memory | Optimal Engine organizations, workspaces, nodes, sources, signals, claims, facts, decisions, memories, and context packages | TerraWatt ontology, taxonomy, playbooks, relationships, policies, and accepted facts | | Deployment and operations | MIOSA environments, releases, rollback, secrets, runtimes, receipts, and health evidence | TerraWatt environments, Azure placement, connectors, service levels, and operating runbooks | | Transactional state | Standard PostgreSQL patterns and migration tooling | TerraWatt deal, site, parcel, entity, obligation, critical-date, task, and approval schemas | | Document handling | Intake, parsing, retrieval, evidence, and review primitives | TerraWatt naming rules, data-room structures, tracker mappings, exceptions, and migration | | Agent execution | Governed model and tool orchestration patterns | TerraWatt-specific tools, permissions, prompts, rules, approval gates, and acceptance tests | | Scale or locality | Standard local and cloud placement options plus Fractal architecture expertise | Fractal designs the scale and data boundary with MIOSA; any separately licensed Fractal capability is tied to a validated requirement | The valuable custom work is the last mile. That last mile is substantial because it encodes TerraWatt's organization, language, documents, decisions, permissions, workflows, acceptance rules, and operating interfaces. The open-source foundation reduces reinvention. It does not remove the need for discovery or custom implementation. ## Recommended Topology ```mermaid flowchart TD subgraph AZ["TerraWatt Azure tenant"] I["Entra ID, MFA, RBAC"] O["OneDrive and SharePoint document estate"] G["Microsoft Graph"] Q["Service Bus and durable workers"] D["Document intake pipeline"] C["Claims, citations, confidence"] R{"Policy decision"} RA["Accepted deterministic fact"] RR["Review required"] P["PostgreSQL operating spine"] E["Dedicated Optimal Engine"] B["BusinessOS"] H["Named human approvals"] X["Approved external actions"] A["Immutable audit and backup boundary"] I --> Q O --> G G --> Q Q --> D D --> C C --> R R --> RA RA --> P R --> RR RR --> B P --> E E --> B B --> H H --> X X --> A end F["Fractal delivery and data architecture"] --> P F --> E L["Separately licensed Fractal capability"] -.-> F ``` ## Workspace and Node Model The production hierarchy should be: ```text TerraWatt Organization Company Context Workspace Executive policy and portfolio state Data Room Operations Workspace Deal node Site node Counterparty nodes Data-room context Document assertions Obligations and dates Tasks and approvals Deal node ... ``` TerraWatt should not receive one top-level workspace per data room. A workspace is a durable organizational and policy boundary. A deal, project, site, data room, obligation, document, task, and approval belongs in the governed node tree within that boundary. The first production environment should use a dedicated Optimal Engine workspace such as `terawatt-data-room-ops`. ## The Correct Data Architecture ### Authoritative stores | Store | Authority | Contents | |---|---|---| | PostgreSQL | Operational truth | Deals, sites, entities, obligations, dates, statuses, approvals, assertions, task state | | OneDrive and SharePoint | Document truth | Original files, versions, archive folders, counterparty rooms | | Append-only audit ledger | Action truth | Agent actions, user actions, policy decisions, approvals, connector calls | | Optimal Engine | Context truth | Sources, signals, claims, facts, memory, relationships, decisions, context packages | | Object storage | Binary and immutable evidence | OCR derivatives, exports, snapshots, signed reports, backup manifests | ### Derived stores | Store | Purpose | |---|---| | Full-text index | Exact phrase and metadata search | | Vector index | Semantic retrieval | | Graph index | Relationships among deals, people, entities, documents, obligations, and precedent | | Cache | Bounded acceleration only | | Metrics store | Accuracy, latency, cost, workflow health, edit rate, acceptance results | Derived stores must be reproducible from authoritative records. They must never silently become the source of truth. ## Document Intake Harness The data-room work should run through a deterministic harness. ```mermaid flowchart TD A["Graph event or delta"] --> B["Fetch with scoped identity"] B --> C["Malware scan, hash, and dedupe"] C --> D["Preserve original and metadata"] D --> E["OCR and structural parse"] E --> F["Document classification"] F --> G["Field assertions with page citations"] G --> H["Confidence and policy evaluation"] H --> HA["Approved deterministic path"] HA --> I["Canonical write"] H --> J["Uncertain or consequential"] J --> JR["Human review queue"] JR --> I I --> K["Tracker, deadlines, and context refresh"] K --> L["Audit receipt and health evidence"] ``` Every step requires: - an idempotency key; - a source identity; - content hash; - model and prompt version; - execution timestamp; - confidence and policy result; - retry state; - dead-letter path; - audit receipt. ## Module Feasibility | Module | Fit | Main concern | Recommendation | |---|---|---|---| | F0 Foundation | Strong | Schema and governance are not yet discovered | Build first after discovery | | M3 Data Room core | Strong | Taxonomy, source permissions, exceptions, and migration volume | First production workflow | | M1 Deal State | Strong with limits | Depends on reliable F0 and M3 records | Start with one deal type and critical dates | | M0 Command Intelligence | Strong after data quality | Accuracy cannot exceed underlying record quality | Minimal command layer in pilot, expand after evidence | | M2 Meeting Intelligence | Moderate | Recording consent and cross-platform capture | Counsel-approved policy and optional launch scope | | M17 Comp Intelligence | High risk | Nationwide source fragmentation, licensing, coverage proof | Separate data-product workstream | | M4 Contracts | Moderate | Legal accuracy and counsel workflow | Phase 2 with seeded benchmark | | M5 Zoning | Moderate to high risk | Jurisdiction variance and source quality | Bounded-state pilot before broad SLA | | M6 Utilities | Moderate to high risk | Public-data incompleteness and response dependence | Memo assistant, not authoritative feasibility | | M7 Reports | Strong after M5/M6 | Quality inherits upstream uncertainty | Build after validated research sources | | M8 Contacts | Moderate | Licensed data and compliance | Client-funded sources and human outreach only | | M10 Monitoring | Moderate to high risk | Source coverage, watcher health, and precision | Define explicit source registry and test corpus | | M13 Models | Strong with controls | "To the dollar" depends on supplied templates and correct inputs | Deterministic calculation service plus cited inputs | | M9 Entitlement | Moderate | Counsel and consultant judgment | Workflow and assembly support, not legal conclusion | | M11 Admin | Strong | Email prompt injection and prioritization tuning | Narrow permissions and draft-only external actions | | M12 Reporting | Strong after data maturity | Completeness depends on executed agreements | Build on verified obligation ledger | | M14 Bookkeeping | Moderate | Accounting policy and reconciliation responsibility | Accountant-supervised, no payment authority | | M15 Construction OS | Separate program | Major domain and integration expansion | New discovery and SOW | | M16 Public Affairs | Moderate | Reputational and policy risk | Human approval and strict provenance | ## Critical Problems In The RFP ### 1. Phase 1 is overloaded Phase 1 combines foundation, migration, deal state, meeting capture, executive command, and a nationwide intelligence product. Those workstreams have different data, legal, operational, and acceptance risks. They should not share one unconditional 90-day gate. ### 2. M17 is a separate product M17 requires continuous nationwide monitoring across SEC filings, county records, transfer-tax records, utility filings, interconnection queues, bankruptcy, auctions, trade press, and press releases. County availability, licensing, anti-automation controls, record latency, and document formats vary by jurisdiction. The stated 90% capture within 48 hours cannot be priced responsibly until the source universe and benchmark denominator are defined. ### 3. Acceptance denominators are missing "95% accurate" is not a test plan. The SOW must define: - the benchmark corpus; - sample size; - stratification; - critical and noncritical fields; - source-of-truth adjudicator; - treatment of missing or contradictory sources; - tolerance; - confidence threshold; - retest rules; - failure attribution; - acceptance window. ### 4. Zero-miss guarantees need boundaries "Zero missed critical dates" is acceptable only for: - documents successfully ingested; - dates represented in the agreed schema; - configured source systems; - functioning connectors; - defined monitoring windows; - client-approved records. It cannot cover missing documents, inaccessible systems, incorrect client data, or facts never supplied. ### 5. Their ownership language mixes unlike categories The RFP says all code, prompts, schemas, configurations, and documentation become TerraWatt property from day one. That language is understandable for TerraWatt-funded custom work. It cannot change the license of upstream open-source software, assign third-party services, or transfer MIOSA's paid platform infrastructure. This is a classification problem, not a reason to fight over ownership. The response must distinguish: - TerraWatt data and source documents; - TerraWatt-specific taxonomy, playbooks, mappings, configurations, acceptance tests, and bespoke modules; - BusinessOS and Optimal Engine open-source components under their applicable licenses; - MIOSA paid platform services and pre-existing platform code; - Fractal's joint delivery contribution and any separately licensed Fractal capabilities; - third-party software and cloud services; - generic delivery methods and reusable know-how; - export, transition, documentation, and handoff rights. ### 6. "No proprietary dependency" really means no unmanageable lock-in TerraWatt already requires Microsoft 365, Azure, Claude, landID, and future licensed data sources. The practical requirement cannot mean that every dependency is open source. It should mean: 1. TerraWatt controls its cloud accounts, data, and client repositories. 2. BusinessOS and Optimal Engine can continue under their open-source licenses. 3. TerraWatt-specific modules can be handed over and operated without losing its data. 4. MIOSA platform services are documented as paid services with clear export and transition procedures. 5. Fractal's delivery role is explicit, and any separately licensed Fractal capability is disclosed before activation and governed by its applicable license. 6. Every model, connector, and service boundary is replaceable through a documented interface and acceptance harness. That satisfies the business purpose of the clause without misrepresenting the technology stack. ### 7. Archive-only can conflict with deletion duties The RFP correctly reserves true deletion for a human administrator. The implementation still needs: - retention classes; - legal holds; - privacy deletion procedure; - backup expiry behavior; - deletion propagation; - data minimization; - record of authorized deletion. ### 8. Phase overlap contradicts the gate model Phase 2 begins on day 60 while Phase 1 ends on day 90. That permits Phase 2 work before Phase 1 acceptance even though the RFP says no phase proceeds without prior acceptance. The response should require written authorization for any overlap and separate payment risk. ### 9. Meeting recording compliance is not a software-only guarantee The system can implement disclosure, consent capture, and typed-note fallback. TerraWatt counsel must define and approve the operating policy. The vendor should not warrant that product behavior alone establishes compliance in every jurisdiction. ### 10. "Provenance on every field" needs a claim model Literal provenance columns on every business table will become brittle. The better structure is: - canonical entity and field; - source assertion; - evidence location; - effective and observed time; - confidence; - reviewer; - supersession relationship; - accepted fact projection. This preserves field-level provenance without contaminating every application table with custom history logic. ## Second-Pass Contract and Delivery Audit The deeper review changes the severity of several conclusions. The scope is not merely aggressive. Several acceptance obligations are temporally or logically impossible to price as written because the prerequisite data, benchmark, third-party access, and client decisions do not yet exist. ### The 90-day schedule contains a hidden day-30 deadline M1 requires a 60-day parallel run with zero missed critical dates. Phase 1 ends on day 90. That means the M1 production workflow, relevant migration, critical-date ledger, alerting, monitoring, acceptance instrumentation, and client operating procedure would need to be ready by approximately day 30. That is incompatible with simultaneously delivering F0, M0, M2, M3 migration, and M17 from an unconfirmed systems inventory. Our proposal must either: 1. start the 60-day parallel run after production readiness and allow Phase 1 acceptance to occur later than day 90; 2. shorten the contractual parallel run for the first gate; 3. restrict the parallel run to a small named pilot corpus; or 4. split build acceptance from operational validation. ### Phase sequencing contradicts the gate language The operating principles say no phase proceeds without acceptance of the prior phase. The schedule starts Phase 2 on day 60 while Phase 1 runs through day 90. Section 05 also allows Phase 2 modules to be re-sequenced at the Phase 1 gate without repricing individual modules. Those terms create three risks: - Phase 2 could begin before Phase 1 acceptance. - Module dependencies could change without price adjustment. - TerraWatt could substitute sequencing in a way that creates rework while preserving the original fixed fee. The proposal should state that overlap requires separate written authorization and that repricing applies when sequencing changes dependencies, environments, integrations, or acceptance effort. ### Paid discovery is already authorized Section 08 says selected finalists proceed to a paid discovery sprint that produces the binding fixed-fee Phase 1 SOW. This is important. We do not need to convince TerraWatt that discovery should exist. We need to win finalist status, then make discovery rigorous enough that the fixed-fee SOW is based on evidence rather than assumptions. The initial response should therefore provide: - a fixed discovery fee; - a non-binding Phase 1 ROM; - module-level pricing assumptions; - a method for converting discovery outputs into binding milestones; - explicit variance rules for unresolved assumptions. It should not provide an unconditional binding Phase 1 fee before the paid discovery that their own RFP anticipates. ### Their open-technology requirement is internally inconsistent The RFP disqualifies proprietary dependencies while requiring or assuming: - Microsoft 365; - Microsoft Graph; - Microsoft Azure; - OneDrive; - SharePoint; - Microsoft Teams; - Claude API; - Claude Agent SDK; - landID; - future licensed contact and ownership sources. The practical requirement is not zero proprietary dependencies. It is zero dependency on an irreplaceable delivery-vendor platform. Our response should define portability through: - TerraWatt-controlled cloud accounts and repositories; - open data exports; - documented interfaces; - replaceable model and connector adapters; - versioned schemas; - infrastructure as code; - evaluation-based component substitution; - source access or transition rights for MIOSA-delivered components. This framing is more coherent than claiming the system has no proprietary dependencies. ### Work-for-hire must be limited to the commissioned TerraWatt layer The ownership clause includes all code, prompts, schemas, configurations, and documentation from day one. A complete implementation will necessarily contain: - MIOSA platform services and pre-existing platform technology; - BusinessOS open-source components; - Optimal Engine MIT-licensed components; - Fractal delivery methods and any separately licensed Fractal technology; - open-source packages; - cloud-provider services; - model-provider SDKs; - generic deployment tooling; - reusable adapters and testing methods. The proposal needs an intellectual-property schedule before work begins: | Category | Recommended ownership | |---|---| | TerraWatt data and source documents | TerraWatt | | TerraWatt-specific taxonomy, playbooks, prompts, schemas, mappings, and acceptance corpus | TerraWatt | | Bespoke TerraWatt application modules funded under the SOW | TerraWatt, subject to background components | | BusinessOS | Applicable published open-source license | | Optimal Engine | MIT license | | MIOSA platform and existing delivery infrastructure | MIOSA | | Fractal pre-existing technology and separately licensed products | Fractal or applicable licensor | | Generic improvements and reusable know-how | Existing owner, with no TerraWatt confidential information | | Open-source and third-party dependencies | Applicable upstream licenses | Counsel must convert that schedule into the final agreement. ### “All active deals” is an unknown migration obligation F0 acceptance requires the schema to be populated for all active deals. The RFP does not state: - the number of active deals; - the number of entities, parcels, obligations, and documents; - the condition of current spreadsheets; - duplicate rates; - scanned-document quality; - missing-document rates; - inaccessible or externally controlled rooms; - historical versions; - the number of exceptions requiring human adjudication. The fixed fee must be tied to a discovered migration inventory or a stated volume and quality band. Anything beyond that band requires a change order or a separately priced migration unit. ### Several acceptance tests depend on TerraWatt or third parties Examples include: - counsel approval of the recording-consent workflow; - TerraWatt supplying model templates and source data; - client personnel attending onboarding and ruling sessions; - Microsoft administrator consent; - external source and data-provider availability; - counterparty indexes; - human approval turnaround; - licensed contact-data access; - source systems exposing usable APIs; - accountants and counsel adjudicating ground truth. Client-caused and third-party delays need schedule relief. Acceptance clocks must pause when a required dependency is unavailable. ### Archive-only does not automatically prevent destructive change Removing the delete verb is insufficient. An update, move, synchronization error, retention rule, or connector action can still make information unavailable or overwrite state. The implementation needs: - append-only source assertions; - versioned canonical records; - content-addressed originals; - copy-verify-archive migration; - immutable evidence manifests; - soft deletion in application views; - privileged human deletion outside model-facing tools; - legal-hold precedence; - restore testing; - reconciliation between source and destination inventories. ### Backup requirements omit recovery time The RFP specifies a recovery-point target of 24 hours or better but does not define a recovery-time objective. The proposal should define: - recovery point by system; - recovery time by system; - maximum tolerable business interruption; - restoration order; - credential recovery; - dependency recovery; - failover communication; - quarterly evidence requirements. A 24-hour recovery point may also be too weak for active critical-date and approval records. ### Model abstraction is not enough for replaceability A single model gateway does not by itself make modules replaceable. Replaceability requires: - typed input and output contracts; - versioned capability manifests; - deterministic tool boundaries; - policy interfaces; - fixtures and evaluation datasets; - compatibility tests; - migration contracts; - state ownership rules; - rollback behavior; - performance and cost baselines. This is where MIOSA's release receipts, exact promotion, rollback, policy gates, and evaluation evidence are strategically useful. ### M17 conflicts with the program’s normal human-control model M17 is explicitly fully autonomous and has no human gate. It may add transactions and complete blank fields but may not modify or delete existing entries. This creates a subtle risk. An incorrect autonomous addition becomes a durable record that the agent cannot correct. The design therefore needs: - a pending assertion state before canonical publication; - a certainty policy implemented as code; - deterministic duplicate and entity resolution; - source retraction handling; - a human correction workflow; - supersession rather than mutation; - origin labels; - correction metrics separate from capture metrics. The RFP's add-only rule should apply to the evidence ledger, not force incorrect canonical records to remain current. ## Requirement Traceability and Response Position This matrix should become the backbone of the formal compliance response. | RFP requirement | Current response | Contract position | |---|---|---| | One PostgreSQL-backed data spine | Accept | PostgreSQL stores canonical operational records and assertions, not every binary document | | Provenance and versioning on every field | Accept through assertion model | Define evidence, observed time, effective time, reviewer, confidence, and supersession | | Microsoft Graph ingestion | Accept | Subject to tenant consent, selected permissions, API behavior, and discovered source topology | | OCR and cited extraction | Accept | Benchmark by document class and scan quality | | Durable institutional memory | Accept | Optimal Engine provides governed memory and context packages | | Claude API and Agent SDK | Accept as default | Route through model gateway and preserve replacement path | | M0 cross-module command interface | Accept in stages | Pilot only covers modules and records accepted into the spine | | 95% M0 answer accuracy | Qualify | Define corpus, sample size, criticality, adjudication, and citation correctness | | 100% approval actions visible | Accept with SLO | Define creation-to-visibility latency, uptime, duplicates, and outage behavior | | Populate all active deals | Qualify | Fixed fee applies to discovered inventory and quality band | | 98% critical-date and dollar extraction | Accept with benchmark | Stratify by document type and require a blind holdout set | | M1 60-day parallel run | Reject inside current 90-day structure | Start after production-readiness gate or use a named pilot corpus | | Zero missed critical dates | Qualify | Limited to configured, successfully ingested, client-approved sources and records | | Meeting consent compliance | Shared responsibility | TerraWatt counsel approves policy; system enforces approved behavior | | M3 migration with zero loss | Accept with inventory protocol | Copy, hash, verify, reconcile, approve, then archive | | 97% M3 classification | Accept with taxonomy benchmark | Define classes, ambiguity rules, and low-confidence treatment | | 95% email auto-filing | Accept with known-counterparty benchmark | Exclude inaccessible, encrypted, malformed, or unsupported content from denominator | | Counterparty room in 24 hours | Qualify | Applies to supplied machine-readable index and already-ingested approved documents | | M17 90% nationwide capture in 48 hours | Reject before source discovery | Separate proof, source registry, selected jurisdictions, rights review, and measured denominator | | M17 100% factual populated fields | Accept as objective | Define source hierarchy, conflicting sources, corrections, and sampling method | | M4 legal drafting | Accept as counsel-supervised assistance | No legal conclusion or circulation without counsel approval | | M5 zoning determination | Qualify as pre-screen | Human analyst and source verification remain required | | M6 utility determination | Qualify as preliminary signal | Public records do not establish capacity or service commitment | | M7 48-hour branded report | Accept after M5/M6 | SLA begins only when required inputs are complete | | M8 contact intelligence | Accept | TerraWatt funds compliant sources; no autonomous outreach | | M10 90% monitoring detection | Qualify | Define source registry, watcher health, seeded and live-event tests | | M13 models matching to the dollar | Accept on supplied formats | Deterministic calculation engine, formula tests, and cited source inputs | | M9 counsel-confirmed completeness | Shared acceptance | Counsel availability and review time are client dependencies | | M11 send-ready drafts at 70% | Accept after tuning | Define edit-distance or adjudication rubric | | M12 reports without misses | Qualify | Limited to modeled obligations and functioning source systems | | M14 bookkeeping accuracy | Accept under accountant supervision | No payment, filing, tax conclusion, or bank credential access | | M16 monitoring and response | Qualify | Subject to licensed platform access and human publication approval | | No agent deletion | Accept | Implement append-only evidence, versioning, archive, and privileged human deletion | | Immutable isolated backups | Accept | Add RTO, restoration order, credential recovery, and quarterly proof | | Model replaceability | Accept | Requires capability contracts and regression harness, not only an API wrapper | | Complete open-format export | Accept | Define formats, export time, history, binaries, metadata, and verification | | All repositories TerraWatt-controlled | Accept for client-specific work | Open-source upstreams, MIOSA platform repositories, and optional licensed technology remain separate | | Full IP assignment | Qualify by category | Assign expressly commissioned TerraWatt work while preserving upstream licenses, MIOSA platform ownership, and third-party terms | | Fixed fee by phase | Accept after paid discovery | Initial response provides discovery fee and ROM, then discovery produces binding Phase 1 price | | Termination at each gate | Accept | Payments due and licenses survive for accepted work; transition obligations are priced | | Key-person provision | Accept carefully | Name roles, define availability, and allow reasonable equivalent substitutions | | Quarterly uplift and simplification | Accept under retainer | Define included regression work, change threshold, and excluded module redesign | ## Acceptance Harness Design The evaluation harness must exist before the model-driven workflows can be contractually accepted. It should contain: 1. A frozen benchmark corpus with representative source documents. 2. A blind holdout corpus controlled by TerraWatt or a neutral reviewer. 3. Field-level ground truth with adjudicator identity. 4. Document-quality and document-type strata. 5. Critical and noncritical field labels. 6. Precision, recall, exact-match, citation, latency, and loss metrics. 7. Negative examples, duplicates, conflicting sources, scans, malformed files, and prompt-injection fixtures. 8. Workflow tests for approvals, retries, dead letters, recovery, export, rollback, and access denial. 9. Cost and latency baselines by model and task. 10. Signed acceptance receipts tied to code, prompt, model, policy, schema, and dataset versions. Weekly spot checks are operational monitoring. They are not a substitute for a stable contractual benchmark. ## Mandatory Ten-Day Response Checklist TerraWatt says incomplete submissions are set aside without review. The internal deadline is August 7, 2026. This avoids relying on the more generous interpretation that ten business days after July 27 ends on August 10. The clarification call should confirm TerraWatt's official deadline, but the internal production schedule should not move unless TerraWatt gives a later date in writing. The response owner should track these as hard gates: - architecture memo against all six layers; - model usage and run-cost forecast; - fixed fee or clearly qualified ROM for every phase; - milestone and payment schedule; - every Section 04 acceptance criterion addressed; - named people, biographies, allocation percentages, and locations; - two qualifying references from organizations under 100 employees; - one live shipped agentic-system demonstration; - assumptions; - exclusions; - dependencies; - maintenance retainer and response-time SLA; - Phase 4 M15 and M16 ROM; - software, service, license, third-party, and custom-work ownership schedule; - paid discovery scope and fee; - response delivered within ten business days. The references and live demonstration are potential disqualification items. Do not invent or stretch them. If exact reference criteria cannot be met, disclose the closest truthful evidence and explain the relevance. ## Security Model ### Microsoft permissions Use a dedicated Entra application and selected SharePoint or OneDrive scopes wherever supported. Do not grant tenant-wide file access by default. Use separate identities for: - ingestion; - meeting capture; - approved outbound actions; - reporting; - administration; - backup. ### Prompt-injection controls Inbound email, documents, websites, and tool results are untrusted data. The implementation should: - isolate untrusted content from system instructions; - screen content before privileged action; - minimize tool permissions; - use allowlisted tools per workflow; - require human approval for consequential operations; - prevent secrets from entering model context; - log model, prompt, tool, source, and policy versions; - red-team indirect prompt injection in the permanent evaluation harness. ### Durable execution The workflow layer must assume duplicate delivery and partial failure. Use: - deterministic business identifiers; - idempotent consumers; - duplicate detection; - dead-letter queues; - per-deal ordering where required; - outbox writes for transactional state changes; - health alerts for stalled watchers; - replay with preserved evidence. ### Backup Use a separate Azure security boundary with immutable Blob Storage policies. Database backups alone are not enough. The restoration plan must cover: - PostgreSQL; - OneDrive and SharePoint content and versions; - object storage; - application repositories; - configuration; - playbooks; - secrets references; - audit records; - model and prompt manifests; - infrastructure definitions. Quarterly restore testing should produce an evidence packet, not only a successful job status. ## Responsible Delivery Sequence ### Phase 0 - Paid discovery and acceptance design **Duration:** 3 to 5 weeks, finalized after the clarification meeting **Outputs:** - final system inventory; - org, role, and approval map; - one complete workflow from source to accepted output; - sample corpus and data profile; - OneDrive and SharePoint topology; - document taxonomy and glossary; - deal-state ontology; - source and connector registry; - Azure landing-zone design; - threat model; - open-source, paid-platform, optional-license, and custom-work boundary; - acceptance corpus and scoring rules; - module backlog; - run-cost model; - binding Phase 1 SOW. ### Phase 1A - Foundation and one production data-room loop **Duration:** 6 to 8 weeks **Scope:** - F0 core schemas; - SSO, MFA, RBAC; - Graph ingestion for approved sources; - document intake harness; - one deal type; - one or two pilot data rooms; - classification, extraction, review, filing, tracker update; - approval inbox; - immutable audit receipts; - minimal M0 retrieval with citations. ### Phase 1B - Deal state and portfolio expansion **Duration:** 6 to 8 weeks **Scope:** - M1 lifecycle and critical dates; - existing room migration; - all active deals in the agreed class; - data-room completeness; - daily and weekly briefs; - bounded M2 integration if counsel policy is ready; - operational parallel run. ### Phase 1C - M17 proof and source benchmark **Duration:** 6 to 10 weeks, separate commercial gate **Scope:** - supplied v7 schema and 1,160-row seed audit; - explicit qualifying-transaction definition; - selected source classes and jurisdictions; - source-rights review; - benchmark dataset; - precision and recall measurement; - daily export; - correction and source-retraction behavior; - national expansion ROM. ### Later phases Only begin later modules after the data spine and acceptance harness prove reliable. The recommended dependency order is: ```text F0 -> M3 -> M1 -> M0 | +-> M2 +-> M4 -> M13 -> M12 -> M14 +-> M5 + M6 -> M7 -> M9 +-> M10 -> M16 M17 runs as a separately gated data-product track. M15 requires a new construction-domain discovery. ``` ## Commercial Position These are internal rough-order ranges, not a quote. They assume a named enterprise team, client-controlled Azure, security engineering, data migration, acceptance automation, documentation, and handoff. | Workstream | Internal ROM | |---|---:| | Paid discovery and binding Phase 1 design | $75,000 to $125,000 | | Phase 1A foundation and pilot loop | $200,000 to $325,000 | | Phase 1B deal state and portfolio expansion | $175,000 to $300,000 | | M17 bounded proof | $150,000 to $300,000 plus data costs | | Full requested Phase 1 as written | $600,000 to $950,000 and likely 5 to 7 months | | Phase 2 | $500,000 to $900,000 | | Phase 3 | $450,000 to $800,000 | | Phase 4 ROM | $500,000 to $1,200,000 | | Maintenance and quarterly uplift | $25,000 to $50,000 per month | Likely total program range is $2 million to $4 million plus cloud, model, licensed data, security, and third-party costs. The price should not be discounted to fit an automation-project budget. The scope creates material operational, legal, security, and financial exposure. ## Recommended Vendor Response The response should not challenge TerraWatt's vision. It should show that we understand why the operating model is valuable and that we are protecting its success by sequencing it correctly. ### Opening position > MIOSA is aligned with TerraWatt's agent-default, human-approved operating model and can deliver the backbone as a TerraWatt-controlled, Azure-hosted system with open data, exportability, source-level evidence, and replaceable modules. BusinessOS and Optimal Engine provide an open-source foundation. MIOSA provides the paid deployment and operating platform. TerraWatt funds and controls its custom operating implementation. MIOSA and Fractal form the joint delivery team, while any separately licensed Fractal technology is activated only where the approved architecture requires it. Our proposal qualifies the requested 90-day Phase 1 by separating the first operational loop from the nationwide intelligence product and by using the paid discovery sprint to finalize the taxonomy, permissions, source universe, acceptance corpus, and commercial boundaries required for a responsible fixed fee. ### Response package 1. Executive response and qualification letter. 2. Architecture memo against Section 03. 3. Module-by-module compliance matrix. 4. Acceptance-test plan for every criterion. 5. Phase and milestone pricing. 6. Named team, allocation, location, and key-person commitments. 7. Assumptions, exclusions, dependencies, and client responsibilities. 8. Security, privacy, and prompt-injection control plan. 9. Data migration and zero-loss verification plan. 10. Model usage and run-cost model. 11. Maintenance, incident, uplift, and SLA plan. 12. Phase 4 ROM. 13. Live demonstration script. 14. Reference strategy. 15. Open-source, platform-service, third-party, optional-license, and TerraWatt ownership schedule. ### Immediate response to TerraWatt Use a short acknowledgment now. Do not negotiate scope, price, ownership, or acceptance criteria by email before the response package is complete. > **Subject:** Re: TerraWatt AI-Native Operating Backbone RFP > > Hi Royden, > > Thank you for sending the complete RFP. > > I have received it and started reviewing the architecture, module dependencies, acceptance criteria, phasing, and commercial structure. > > The direction is closely aligned with how MIOSA approaches governed agent systems. > > I also appreciate the flexibility around the bracketed assumptions. > > Where we believe a different sequence or threshold will improve delivery and reduce risk, we will propose it clearly and explain why. > > I would be glad to walk through it with you next week before we finalize our response. > > I am available: > > - [Option 1 with time zone] > - [Option 2 with time zone] > > If neither works, send me another window and I will adjust. > > We will return the formal response within the requested ten-business-day period. > > Best, > Roberto ## Questions We Must Resolve Before A Binding SOW ### Business and operating model - Who is the authoritative product owner? - Royden signs the transmittal as Acquisitions. Who owns procurement, executive sponsorship, requirements decisions, and final acceptance? - Which deal class is the first pilot? - How many active deals and data rooms are in the first migration? - Which people can approve each action class? - What is the critical-date adjudication process? ### Data and systems - Supply the full systems inventory. - Supply sample OneDrive and SharePoint topology. - Supply the Master Comp Sheet v7 and data dictionary. - Supply three representative data rooms. - Supply current trackers and deal-stage definitions. - Supply standard acquisition, lease, and capital model templates. - Confirm Teams, Zoom, e-signature, accounting, CRM, and data-provider systems. ### Security and legal - Confirm Azure tenant and subscription ownership. - Confirm Entra identity configuration. - Confirm data residency. - Confirm outside-counsel access. - Obtain counsel-approved recording policy. - Define retention, deletion, legal hold, and e-discovery requirements. - Define DPA, incident notice, cyber insurance, and audit requirements. ### Acceptance - Define benchmark datasets and denominators. - Define which failures are critical. - Define factual ground truth and adjudicators. - Define treatment of inaccessible sources. - Define parallel-run responsibilities. - Define acceptance remediation and retest. ### Commercial and IP - Confirm that TerraWatt owns its data and expressly commissioned client-specific deliverables. - Confirm the published BusinessOS release license and the verified MIT license for Optimal Engine. - Confirm MIOSA subscription, support, deployment, export, and transition terms. - Confirm whether any Fractal capability is required and, if so, its separate license and scope. - Confirm source access, escrow, transition rights, and post-termination operation. - Confirm third-party data and cloud costs are client-funded. - Confirm schedule relief for client dependency delays. ## Live Demo Strategy Do not show slides. Demonstrate one complete operating loop using a sanitized TerraWatt-like room: 1. A document enters an approved OneDrive location. 2. The system records its source, identity, and hash. 3. It classifies and extracts a critical date with a page citation. 4. The policy layer requires review. 5. A user approves or corrects the assertion in BusinessOS. 6. The critical-date ledger and completeness tracker update. 7. M0 answers a deal question with citations. 8. The audit view shows every source, model, prompt, policy, user, and state transition. 9. A failed or low-confidence example routes to review instead of contaminating the record. 10. The application displays deployment, connector, queue, and watcher health. That demonstration directly answers the core RFP better than attempting to imitate all 18 modules. ## Final Recommendation Bid. Do not accept the RFP unchanged. Lead with the architecture and operating-model alignment. Use paid discovery to convert assumptions into a contractible system. Classify ownership correctly instead of grouping every layer under one IP label. Make F0, M3, M1, and a bounded M0 the first operating loop. Separate M17. Describe Fractal as a joint delivery and architecture partner, while keeping any separately licensed Fractal technology conditional on an approved requirement. Position BusinessOS as TerraWatt's human operating surface, Optimal Engine as its governed context and memory plane, PostgreSQL as the transactional spine, OneDrive and SharePoint as the document estate, and MIOSA as the deployment and execution control layer. If TerraWatt insists on the current Phase 1 scope, 90-day deadline, full IP assignment, and fixed fee without discovery-based qualification, decline the fixed commitment rather than absorb an unbounded enterprise transformation risk. ## Source Notes RFP references in this analysis point to `TerraWatt_AI_Backbone_Scope_v2_2.pdf`. External technical validation: - Microsoft Graph selected permissions and OneDrive/SharePoint access: https://learn.microsoft.com/en-us/graph/permissions-reference - Microsoft Graph delta tracking: https://learn.microsoft.com/en-us/graph/api/driveitem-delta - Azure Service Bus duplicate and loss controls: https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-message-loss-and-duplicates - Azure PostgreSQL backup and point-in-time restore: https://learn.microsoft.com/en-us/azure/postgresql/backup-restore/concepts-backup-restore - Azure Blob immutable storage: https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-storage-overview - MCP security guidance: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices - Anthropic indirect prompt-injection guidance: https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/mitigate-jailbreaks - Anthropic agent hosting guidance: https://platform.claude.com/cookbook/claude-agent-sdk-07-hosting-the-agent