MIOSA MIOSA wordmark Fractal Computing
TerraWatt / next client conversation

Turn the vision into one accountable 90-day operating loop.

The RFP describes the destination. This brief defines the conversation that prevents the entire destination from becoming one undefined fixed-price obligation.

Required outcome

Confirm one bounded Phase 1, one ownership schedule, one acceptance boundary, one required source package, and one sequence for the formal proposal.

01 / Run of show

Move from their RFP to evidence, then from evidence to the operating system.

Roberto controls the screen. The team supports defined sections and saves commercial or legal debates for the alignment block.

Open and frameRoberto sets the sequence: RFP, evidence, product, technical layers, decisions.
Walk TerraWatt's RFPRoberto interprets each major requirement; Royden confirms intent and corrects assumptions.
Show a real implementation processProve how outcomes, sources, vocabulary, workflows, modules, and acceptance become software.
Show BusinessOSConnect the method to the operating surface, governed context, modules, roles, work, and evidence.
Separate the technical layersExplain Claude API/SDK, Claude Code, agent harness, operating harness, MIOSA, and Fractal.
Resolve the boundariesJordan supports scope, ownership, vendor independence, dependencies, and acceptance.
Lock the handoffName owners, source package, proposal sequence, and next decision date.
02 / Presentation logic

Make the argument in four moves.

Every move answers a different question: what they asked for, whether the method works, what they receive, and how the technical stack fits together.

01 / Their language

Walk the RFP first.

For each major section: request, operational meaning, existing foundation, custom implementation, discovery requirement, and phase assignment.

02 / Evidence

Show a real implementation process.

Outcome to source package, vocabulary, taxonomy, ontology, workflow, authority, module configuration, benchmark, deployment, and evidence.

03 / End product

Show BusinessOS.

Organization, workspaces, people, roles, modules, sources, decisions, tasks, permissions, agents, interfaces, and accepted company context.

04 / Technical clarity

Separate model access from the operating system.

Claude can reason. Claude Code can build. The agent harness governs execution. The operating harness makes the work belong to the company.

03 / Technical layers

Do not let one word, "Claude," collapse six different responsibilities.

Model interface

Claude API / SDK

Programmatic access to model reasoning and generation. It does not supply company hierarchy, durable memory, workflow state, permissions, or audit evidence.

Inference interface
Development agent

Claude Code

An interactive coding agent that can inspect repositories, edit files, and run tools. It helps build and maintain the system but is not the production backbone.

Build-time operator
Execution contract

Agent harness

Controls context assembly, instructions, tools, execution, errors, approvals, and evaluation for a specific class of agent work.

Agent-level governance
Company contract

Operating harness

Supplies identity, hierarchy, workspaces, accepted context, policies, workflow state, evidence, observability, human authority, and recovery.

Organization-level governance
The line to use

Claude can reason and Claude Code can build. The harness determines what an agent is allowed to know and do. The operating system determines how that work belongs to the company and becomes durable evidence.

04 / First release

Prove the complete loop before expanding the module count.

F0, M3, bounded M1, and minimal M0 form a coherent production release. M17 remains a separately accepted proof unless TerraWatt removes equivalent scope.

One source becomes one accepted operating record, then returns as evidence.

01 / RECEIVEEmail or document arrives

Approved Outlook, OneDrive, or data-room source.

02 / PRESERVEStore immutable source

Identity, timestamp, checksum, and provenance.

03 / INTERPRETClassify and extract

Bounded fields, dates, obligations, and confidence.

04 / REVIEWHuman approval gate

Low-confidence and high-impact changes are reviewed.

05 / ROUTEFile the accepted record

Correct deal, project, data room, or tracker.

06 / ACTSurface deadline and owner

Bounded M1 workflow creates accountable action.

07 / ANSWERRespond with citations

Minimal M0 answers only from accepted records.

08 / LEARNReturn evidence

Result, correction, and approval improve future work.

05 / Decisions

These questions determine whether the proposal is responsible.

Ownership

Classify the work instead of assigning everything.

  • Does "all code" mean TerraWatt-specific commissioned repositories?
  • Do open-source components retain their licenses?
  • Does pre-existing MIOSA and Fractal technology retain prior ownership?
  • Does TerraWatt own its data, configurations, mappings, acceptance corpus, and commissioned modules?
Vendor independence

Define control and portability precisely.

  • Is the requirement about avoiding lock-in and preserving continuity?
  • Or does it prohibit every paid API and managed service?
  • How is the prohibition reconciled with the required Claude SDK?
Acceptance

Name the benchmark and the adjudicator.

  • Which deal class and user group form the pilot?
  • What corpus and denominator support each accuracy target?
  • Which failures block acceptance?
  • When does the 60-day parallel run begin?
Commercial boundary

Fixed fee requires fixed responsibility.

  • USD 200,000 covers the accepted 90-day Phase 1.
  • Third-party costs remain separate.
  • Client access and approval delays move the schedule.
  • Material additions require a change order or new phase.
06 / Architecture

Four layers, four ownership categories, one coordinated delivery plan.

This answers the proprietary-platform concern without pretending external services do not exist.

Open foundation

BusinessOS + Optimal Engine

Operating interface, governed context, sources, facts, signals, decisions, permissions, evidence, and module primitives.

Published open-source licenses
Operating platform

MIOSA

Deployment, execution, release management, managed runtime, secrets, observability, and recovery services.

Paid platform service
Commissioned work

TerraWatt implementation

Custom modules, workflows, schemas, mappings, prompts, acceptance assets, and company configuration.

TerraWatt-specific deliverables
Scale partner

Fractal

Joint architecture, compatibility layer, enterprise data boundaries, scale path, and selected technology where validated.

Partner IP and disclosed licenses
07 / Client package

Ask for real work, real owners, and real failure cases.

Source material

TerraWatt sends

  • Three representative data rooms: clean, typical, and difficult.
  • Master Comp Sheet and data dictionary.
  • Outlook, OneDrive, tracker, filing, and approval workflows.
  • Templates, expected outputs, and known failure examples.
  • Azure, Entra, Graph, residency, retention, and recovery requirements.
Named authority

TerraWatt confirms

  • Pilot deal class and user group.
  • Business owner and final acceptance adjudicator.
  • Benchmark corpus and acceptance denominators.
  • Security and infrastructure owner.
  • Who can approve workflow, taxonomy, and policy changes.
08 / Demo

Show one truthful operating loop, not eighteen conceptual modules.

  1. Open the TerraWatt workspace in BusinessOS.
  2. Show how Optimal Engine scopes accepted sources, context, permissions, and evidence.
  3. Ingest one representative document or email.
  4. Show extracted fields, source identity, confidence, and review state.
  5. Approve the result and show its deal, deadline, owner, and filing destination.
  6. Ask one cited question through the command interface.
  7. Show the audit event, correction path, and resulting memory.
  8. Explain how MIOSA deploys the accepted system into the approved runtime boundary.
09 / Positioning

Use language that preserves alignment without accepting undefined risk.

We agree with the destination. The question is which operating loop must become trustworthy first.
Vendor independence should mean control, portability, and continuity, not pretending no external services exist.
The 90-day fixed fee can be responsible only when the acceptance boundary is equally fixed.
Fractal gives the architecture a credible enterprise scaling path without making Phase 1 wait for that path.
10 / Internal owners

Everyone enters the call with a defined job.

OwnerBefore the callAfter alignment
RobertoLead the call, show BusinessOS, frame the loop, and hold scope and ownership boundaries.Draft the 90-day proposal, acceptance schedule, architecture memo, team plan, and run-cost assumptions.
JordanPressure-test commercial language, IP categories, and acceptance structure.Review proposal narrative, assumptions, exclusions, and negotiation position.
MichaelExplain Fractal's role, the compatibility approach, and enterprise scale path.Draft the compatibility layer and provide SDK plus test credentials.
PedroSupport product and implementation feasibility during the demo.Translate the accepted workflow into interface and module requirements.
11 / Meeting evidence

Jump directly to the decisions behind this brief.

Vendor contradiction and Claude SDK Aggressive IP language Ownership baseline RFP response requirements First high-value operating loop Open-source core and custom modules Ninety-day Phase 1 Parallel Fractal integration Hold the scope boundary
Bottom line

TerraWatt is asking for the operating system Roberto has been building.

The opportunity is real. The risk is treating the entire future-state program as one fixed-price 90-day obligation. The next call must convert the vision into one accepted loop, one ownership schedule, one evidence-based acceptance plan, and one bounded proposal.