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

Clarify: Define which internal state changes may post automatically and which require approval.

Section 03 - Target architecture

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

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

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

Phase 4 modules

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

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

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:

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

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.

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

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:

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

Derived stores

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.

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

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:

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.

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:

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.

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