AI shouldn't replace your operators.
It should make them ten times stronger.
Six things OpsATC.AI commits to, in the architecture and in the design-partner contract. If any one is broken on day one, we want to hear about it before you sign.
Two right decisions can still cost you a customer.
Two buyers at the same contract manufacturer. The same customer build. Different supplier portfolios — and no signal between them. One $14,000 expedite that solves nothing. The story explains why orchestration has to read across portfolios, not just inside them.
It wasn't my portfolio.
— Both buyers, asked separately, after the variance landed.
Designed to make your team stronger. Never to make it smaller.
OpsATC.AI's objective is never to reduce headcount. The objective is to take the operators you have — the planner who knows the H100 line, the buyer who knows the supplier, the customer-ops lead who's been on the account for nine years — and connect them more directly to the ecosystem they already run.
The Captain doesn't replace the analyst. She gives the analyst a Monday morning where the data is already gathered, the exceptions already surfaced, the response options already drafted — so the analyst spends the day on judgment, relationships, and the work AI cannot do. That's a ten-times-stronger operator. That's the company that wins the next decade.
What OpsATC.AI does for your team
- ✓ Eliminates the swivel-chair tax — no more 40-tab Mondays
- ✓Surfaces the exception before it becomes an escalation
- ✓ Drafts the response so your analyst can refine, not author
- ✓ Connects the field tech, the planner, and the CFO to the same source of truth
- ✓ Makes tribal knowledge visible — and shareable
What it never does
- ✗ Pretend to have your nine-year planner's judgment
- ✗ Act on a system of record without a human in the loop
- ✗ Get measured on headcount reduction in the design-partner contract
This is what "compress decisions" means in practice: three to five items per persona per day, ranked by impact. Everything else is visible on demand — never pushed. The agent is tuned to reduce notifications, not multiply them.
The state of the build, in numbers — and what's next on the calendar.
Honest-stage means publishing the math, not the marketing. Here's what's scaffolded today, what's production-shape, and the dates we're driving toward.
Accepted ADRs, each one tracing a design choice to its constraint and trade-off. Reviewed under change-control before any structural shift.
Platform adapters scaffolded across the supply-chain stack as of build 2026-06-29. 141 are production-built, contract-tested Tier-1 connectors — typed client, health-check ping(), fixture-driven contract tests, write-gate-denied stubs for high-risk operations, and — gate-enforced in CI — at least one real, non-stub data read each, including SAP S/4HANA, SAP ECC, Oracle Fusion ERP, Blue Yonder WMS, and Rockwell FactoryTalk, normalized to canonical domain types. ~700 more architecture-ready scaffolds elevate per customer signal during pilot onboarding. Plus 8 generic adapters (JDBC, OData, OpenAPI, GraphQL, SFTP, SOAP, Webhook, X12) bridging anything not yet in the catalog. Reads are validated against synthetic replay fixtures synthesized from public API documentation; live-sandbox validation happens per-tenant during onboarding. Search the full catalog →
Write-gate registry as of build 2026-06-22 — 644 entries (634 high-risk Tier-2 + 10 low/medium static), default-deny with audit trail. The CI lint (scripts/lint-write-gates.ts) refuses any PR adding an unregistered write. Most high-risk writes don't have an executable code path at all: Tier-1 enforcement (code-path absence) is the first defense layer; the Tier-2 registry is the second. The Captain is read-only by default; every system-of-record write is gated (per ADR-0020).
Forward-only database migrations applied (through 0043) to the multi-tenant Postgres schema. Tenant isolation enforced via row-level security; every migration tested under multi-tenant fixtures before it ships. Migration 0015 introduces the Data Quality Detection Layer (ADR-0023) — see Data Governance below. Migration 0035 makes RLS fail-closed — a query with no tenant context returns zero rows via an all-zeros sentinel, not every tenant.
The library is a factory, not a catalog. The 30-adapter foundation is the customer-pull anchor; the codegen pipeline is the production line; parallel implementer waves are the volume engine. Together they make the 839-catalog defensible — not as inventory, but as throughput.
30 platforms · ~80% pull
Production-Shape Foundation. The systems every enterprise customer in our 7 supported verticals is statistically likely to have. Today: 5 (SAP S/4HANA, SAP ECC, Oracle Fusion ERP, Blue Yonder WMS, Rockwell FactoryTalk). Week-4 target: 30. Each one hand-crafted with normalized domain reads and passing contract tests, validated against synthesized fixtures with vendor-sandbox recording pending.
70 platforms · ~95% pull
Codegen-Accelerated Library. Vendors with well-formed public OpenAPI / OData / WSDL / GraphQL specs. Generated via the codegen CLI; senior implementers apply auth + mappers + fixtures via parallel implementer waves anchored in packages/mcp-codegen. Week-12 target. Five generic protocol adapters (OpenAPI, OData, GraphQL, SOAP, SFTP) act as configuration-only multipliers — many vendors drop in with no new package required.
300+ platforms · long tail
Just-In-Time Long Tail. Vendors not in Phases 1–2. Built by the customer's senior implementer using the codegen pipeline plus framework when the customer's specific stack reveals the need. 4–8 hour build time per adapter. Already scaffolded at directory level (~210 of 300+ have tools.ts / adapter.ts skeletons). This is how OpsATC promises "plug-and-play day 1" for any customer regardless of stack composition — without overstating depth.
Honest-stage framing: today's library is 5 production-shape and 141 production-built, contract-tested Tier-1 connectors (each with a real read verified in CI, against synthetic fixtures) of 839 catalog directories. The remainder are architecture-ready scaffolds — auth strategy declared, contract satisfied, registry-discoverable, OpenAPI-mappable. Scaffolds move to implementation-ready in 30–90 days at onboarding via the codegen pipeline. Breadth is not overstated as depth.
July 1, 2026
Founding senior-engineer hire onboarded June 2026. MVP feature-complete for first design-partner pilot — Captain orchestrator, five production-shape adapters, full Trusted Advisor flow, audit trail, tenant isolation.
January 1, 2027
Phase I production launch. SOC 2 Type II audit in flight (target Q4 2026). EU residency by Q1 2027. Adapter library deepens just-in-time as pilots add platforms to their footprint.
5-day · 30-90 day
5-day: design-partner accelerated track, available at pilot launch — read-credentialed and answering live operational questions inside one work week. 30-90 day: standard onboarding cadence to first measurable operational outcome — a missed cut prevented, an expedite held back, an exception triaged before escalation. The accelerated track is a design-partner commitment, not a current production offering.
Dates are commitments to design partners under the master-agreement template, tracked under the same ADR + change-control discipline that produces the architecture set above. Slip exposure is communicated to design partners in writing as soon as a dependency moves — not at the milestone date.
The Captain finds the dirt before it produces a wrong answer.
Every operation's data is dirty when we start. Stale records. Missing identifiers. Duplicate keys. Two source-of-truth systems disagreeing about the same SKU. The legacy answer is a six-month data-cleanup project before the tool produces its first useful output. The Captain's answer is different: she runs the cleanup continuously, surfaces what she finds, and lets your operators decide what to fix. The Data Quality Detection Layer (architected in ADR-0023, landed in migration 0015) is the operational mechanism behind the Improve pillar.
Stale records
A record that the system of record claims is current but whose last-touch timestamp falls outside the window your operators trust for that record type. PO status not updated in N days. Inventory snapshot older than the cycle-count cadence. Shipment milestone past its expected event.
Missing identifiers
Records present in one system but missing the linking key needed to join them to records in another. Order without a customer reference. Shipment without a PO. PO without a part number. The downstream effect is silent under-counting in every report that depends on the join.
Duplicate keys
A primary key that appears more than once where the schema declares it unique. Same SKU created twice with different units of measure. Same supplier with two vendor IDs. Same shipment booked under two carrier references. Recommendations split across the duplicates and look smaller than they are.
Source-of-truth contradiction
Two systems that should agree about a record do not. ERP says on-hand 240; WMS says 180. Shipment booked in TMS does not appear in the carrier portal. CRM lists the customer as terminated; ERP keeps shipping. The Captain presents both, names which she trusts and why, and routes the discrepancy to an operator.
Schema drift
Source-system fields rename, retype, or repurpose without notice. The adapter that fetched a string yesterday gets a numeric today; the field that meant unit-cost last quarter now means landed-cost. Detected at the MCP boundary and surfaced before it propagates into a recommendation that uses the wrong value.
Reference-data gaps
Lookups missing from the lookup tables. A carrier in the shipment feed not present in the carrier master. A cost center on a PO not present in the GL hierarchy. A part number used in production that has no entry in the item master. The Captain sees the gap in the same query that would have used it.
The four modes work together. Baseline scans run at MCP connect time to establish a known reference. Inline checks run on every read The Captain performs, catching drift as it happens. Scheduled scans run on a background cadence per record type, catching what inline missed. On-demand scans answer operator questions in real time. No mode is sufficient alone; together they form a defense in depth.
At MCP connect time
The first read of each source system runs a full structural and statistical scan against the schema and record set. Establishes the reference cardinality, identifier coverage, and value distributions. This is the "what does normal look like for this tenant" snapshot. Future reads are scored against it.
On every query The Captain runs
Every tool call The Captain makes through MCP runs a lightweight quality check against the records the call returns. Counts compared to baseline. Identifier completeness checked. Value distributions sampled. A finding flagged inline is surfaced to the operator alongside the answer that depended on it — not hidden in a backend log.
Background cadence per record type
A cadence-aware background scanner runs targeted checks per record type — POs every six hours, inventory snapshots daily, supplier master weekly, customer hierarchy on demand. Catches the slow drift that inline checks miss because they only see what the operator asks about. Configured per tenant; defaults align with common operational rhythms.
Operator-triggered deep dive
When an operator wants to investigate a specific finding — "are we sure the PO count is right for supplier X?" — they can ask The Captain to run a deep targeted scan. Full identifier match across systems, full value reconciliation, full record-level pivot. Slower than the other modes, more thorough, scoped to the question.
Findings are surfaced through the Trusted Advisor card pattern (per ADR-0020). The Captain describes what she found, names the records affected, proposes the fix, and routes the decision to a named operator. She does not write back to source systems without human approval — Data Quality Detection raises the signal; the operator decides the response.
The Captain is not the girl who cried wolf.
A detection system that surfaces every minor anomaly trains operators to ignore it. The Data Quality Detection Layer is severity-graded — informational findings stay in the background, threshold-crossing findings surface inline with the answer they affect, and material findings escalate to a named owner. Operators can tune the thresholds per record type, per portal, per role. Trust is a function of signal-to-noise; the layer is engineered for that ratio.
Augmentation only works if your team knows what they're augmenting with.
The augment-not-replace principle requires operators who understand AI behavior at a working level. Without that literacy, the agent runs unsupervised (dangerous) or gets quietly ignored (waste). AI fluency is part of what we deliver.
Knowing what to give the agent and what to keep. The Captain is good at synthesizing, summarizing, structuring, and routing. She is bad at judgment under deep ambiguity, relationship work, and accountability. Operators learn the line.
Asking clearly. Vague prompts produce vague outputs. Operators learn to write prompts specific enough that another planner reading them cold could produce a similar response. Context goes in. Constraints go in. The output gets useful.
Evaluating outputs critically. Operators learn to spot hallucination patterns, recognize when an answer is fluent but wrong, and know which kinds of questions the model is unreliable on — before acting on the response.
Verifying and owning the result. AI does not absolve accountability. The operator who acts on a recommendation is the operator responsible for it. Diligence is the verification habit, built in.
Built on Anthropic's AI Fluency framework, adapted for operations contexts.
Persona-specific training tracks
Each role — Operations Directors, Supply Chain Analysts, Process Improvement Leads, Customer Ops, Field Service — gets a tailored curriculum and hands-on workshops with your actual operational data, not synthetic scenarios.
Anthropic's Claude AI Fluency course
The foundation model behind The Captain is Anthropic's Claude. Anthropic publishes free AI fluency training — short, well-produced, accessible to non-engineers. Every operator who interacts with The Captain should take it. We pay for the time.
Ongoing enablement, not one-time training
Monthly office hours. New-feature briefings as the platform evolves. A literacy assessment in the Admin Portal so leadership tracks fluency progress. Operators who can direct the agent get the value; operators who can't, don't. We pay for the time operators spend reading The Neuron — a plain-English daily AI newsletter.
Anthropic's AI Fluency framework and The Neuron newsletter are independently produced and freely available. We are building OpsATC.AI on top of Anthropic's Claude foundation models; we are not affiliated with Anthropic or The Neuron beyond our use of their API and our recommendation of their content. Both recommendations are editorial, not commercial.
Four reasons we built on Claude — and the seam we left for everything else.
When you stake a company on a foundation model partner, you choose with the same care you'd choose a co-founder. Buyers ask why Anthropic and not the alternatives. Here's the proactive answer — and the honest caveat at the end.
Safety as engineering discipline, not marketing.
Anthropic published Constitutional AI, the Responsible Scaling Policy, model cards with capability evaluations, and an interpretability research program before most labs admitted alignment was a real problem. OpsATC.AI ships into supply chain — a domain where a confident wrong answer can route a wafer shipment to the wrong country. We needed a foundation model partner that treats "the model said something wrong" as an engineering bug, not a PR event.
Anthropic's release cadence pulled our architecture forward.
Claude Opus and Sonnet have shipped at a release cadence that has moved production primitives — tool use, long-context retrieval, sub-agent orchestration, computer use — from preview to ready faster than this category typically allows. The Captain's architecture — state machine plus selectTools chokepoint plus Trusted Advisor doctrine — only became feasible at Anthropic's late-2025 tool-use reliability. We design to the leading edge and let Anthropic's roadmap pull us forward.
A procurement checkbox, not a six-month negotiation.
Default no-training-on-customer-data. Workspace isolation. SOC 2. Zero data retention available. Audit logs. The legal review for using Claude on regulated supply-chain data is a checkbox, not a six-month negotiation. For a pre-revenue company landing its first design-partner pilot, that's the difference between getting through procurement and dying in it.
A partner building the rails — not just selling tokens.
Anthropic publishes prompt-engineering guidance, runs developer education, maintains the Model Context Protocol (MCP) standard we build adapters against, and ships the Claude Agent SDK we run sub-agents on. MCP is the reason OpsATC.AI's connector strategy is even possible — without an open protocol, we'd be writing 839 bespoke integrations against 839 vendor schemas. They're building the rail; we're running cars on it.
We chose Anthropic because they lead on the four dimensions above. If that changes, we'll change.
Our MCP adapter layer is model-agnostic by design — connector work isn't Claude-locked. The Captain orchestrator itself is built on Claude's tool-use semantics today; switching foundation models would require a deliberate re-architecture of the state machine, not a configuration toggle. Cross-model validation against alternate frontier models is on the Year-2 roadmap, at the point where they reach the tool-use reliability our orchestrator depends on — and is a conversation we're prepared to have with design partners whose vendor-diversification posture requires it. We've made the seam explicit so the cost of changing course is known, not hidden. Customer outcomes come first; platform fidelity comes second. Today, Anthropic is the right partner. We've left ourselves the seam to say so for as long as it stays true — and to act on the day it doesn't.
Seven states. One chokepoint. Zero autonomous writes.
CTOs scrutinizing the architecture ask the same question: how does the orchestrator actually work, per request? The state machine below is the answer — codified in ADR-0019, defended by ADR-0020 (Trusted Advisor doctrine), and implemented across packages/captain and packages/mcp-core. Seven operational states. A runtime legal-transitions table. Every transition audit-logged. One tool-selection chokepoint between thinking and tool-calling that filters write tools out of the model's tool list before it ever sees them.
packages/captain/src/state-machine.ts. Legal transitions sit in a runtime table; every transition is audit-logged; illegal transitions throw IllegalTransitionError. The selectTools chokepoint filters write tools from the model's tool list before it sees them. The Captain never writes to a customer system of record — recommendations exit as deep-linked RecommendationCards a human clicks (ADR-0020).Why the chokepoint matters.
A foundation model can choose any tool it has access to. Without a chokepoint, "tool access" is an attack surface: an LLM that should be reasoning over read-only data accidentally invokes a write tool and updates a system of record. The selectTools chokepoint inverts that. Adapters declare every tool with a read or write tag in their tools.ts; the chokepoint rejects every write tool at selection time, cross-checks every selection against the write-gates registry in @opsatc/mcp-core, and audit-logs every rejection with the registered risk class. The result: the model never sees a write tool in its tool list, so the model never picks one. There is no second path.
Why this state machine is bounded.
The state machine is bounded by design: seven operational states (idle, listening, thinking, tool-calling, responding, escalating, error), a runtime legal-transitions table in packages/captain/src/state-machine.ts, and every transition audit-logged. Illegal transitions throw IllegalTransitionError — they indicate orchestrator bugs and must be loud, not silent. The bounded structure means no free-form agent loops: every request walks the same graph, and the selectTools chokepoint sits between thinking and tool-calling as the architectural enforcement point. (Distinct from OpsATC.AI's five-layer product architecture — Read, Reason, Analyze, Sync, Recommend — described on the Platform page; the product architecture describes the stack as a whole, the FSM here governs what happens inside one Captain request.) Long-running multi-decision workflows — multi-stage approval chains with different decision-makers at each step — would require state persistence and branching logic; those are on the post-GA roadmap, not in MVP scope.
Phase 1 versus Phase 2 enforcement.
The CTO due-diligence question is "what exactly enforces the no-autonomous-write doctrine?" Honest answer in two phases. Phase 1 (pilot scope, today): enforcement is runtime — the selectTools chokepoint filters write tools at tool-selection time; the write-gates registry in @opsatc/mcp-core holds ~634 high-risk adapter writes as defense-in-depth defaults-disabled entries (Tier 2); high-risk writes have no executable code path in their adapters (Tier 1); and a build-time CI lint (scripts/lint-write-gates.ts) refuses any PR that declares a high-risk write tool without registering it. Phase 2 (production hardening, pre-GA): cryptographic signature verification on RecommendationCard actions, single-use approval tokens that cannot be replayed, time-bound approval windows that expire automatically, and immutable cryptographically-signed audit-log entries. OpsATC.AI will not run against customer-production systems of record on Phase 1 enforcement alone — Phase 2 hardening is a pre-GA gate, named here so the timeline is on the calendar.
How The Captain learns your operation — without copying it.
Operators who have rolled out a forecasting tool, an integration platform, or a planning suite have heard this story before: "fourteen months to get it live, and it still doesn't have visibility into PLM." That timeline is not an accident — it's what happens when the tool needs to copy your data before it can act on it. OpsATC.AI doesn't.
Six months before the first useful answer.
- Months 1-3: ETL pipeline build. Source-system extraction. Schema mapping. Data-quality cleanup.
- Months 4-6: Historical data load. Model training. Validation against known-good outcomes. Reconciliation reviews.
- Months 7-9: Pilot scope. Initial portal launch. Discovery of edge cases the model wasn't trained for. Re-training cycle.
- Months 10-18: Production rollout. Vendor-side support tickets when source systems drift away from the trained schema.
By the time the tool answers its first real question, your operation has changed underneath it.
Day 1 read-access. First measurable outcome in 60–90 days.
- Day 1: Read-only credentials on the systems you want orchestrated. The Captain can answer questions about live operational state immediately.
- Week 1-2: Field-mapping confirmation per connector. Sandbox validation. Operator training on the Trusted Advisor card interface.
- Week 3-8: First role-aware portal goes live with real users. Recommendations flow into operator queues. Adaptation happens on feedback, not retraining.
- Day 60-90: First measurable operational outcome — a missed cut prevented, an expedite held back, an exception triaged before escalation.
The platform was useful from Day 1. The first defensible business outcome lands in the design-partner pilot window.
Pre-trained reasoning
The Captain brings general operational reasoning out of the box — supply-chain, procurement, fulfillment, and exception-management vocabulary already understood. Your domain doesn't need to be taught.
Query in place
MCP lets The Captain query your live systems on demand — the way an operator would open a tab. The history is already in your ERP. We don't need a copy of it.
Feedback-driven adaptation
Adaptation happens on operator feedback signals — accepted recommendations, overridden recommendations, the reasons given — not on retraining cycles. Your operation tunes the agent through use, not through preparation.
The same architectural truth is what makes the Buyer's Dilemma story possible: cross-portfolio visibility on the day The Captain is connected, not the day a six-month integration project finishes.
See it on your operation →Six commitments. They live below.
If a single one of them is broken on day one, OpsATC.AI isn't the platform you want — and we'd rather hear that early than later.
-
01 HITL
Human-in-the-loop, by doctrine
The Captain is advisory: she reads, reasons, cites, and recommends. She doesn't issue POs. She doesn't reroute shipments. She doesn't post journals. Those clicks belong to the operator. This is doctrinal, not a default — OpsATC.AI is not building write capability against customer systems of record. The clicks are yours, permanently.
-
02 No Data Training
No training on customer data — ever
Customer data is never used to train any foundation model. Anthropic's API terms forbid it. Our tenant-isolation architecture enforces it. Process improvements identified by the Process Intelligence Engine inside your tenant belong contractually and operationally to you.
-
03 Citation
Every fact cited. Every action audited.
The Captain doesn't say "operational health is 87/100" — she says "operational health is 87/100, sourced from your ERP, your planning suite, and your WMS, computed at 6:00 AM." Every action is tied to a user, a role, a source system, and a timestamp. Phase 1 includes structured audit logging with write-gate enforcement. Phase 2 adds immutable cryptographically-signed persistent storage and exportability to regulated-industry audit formats.
-
04 Tenant Isolation
Tenant isolation: your data is yours
Per-customer data isolation enforced at every layer of the stack. No cross-tenant model fine-tuning. No "shared learnings" that leak one operator's IP into another's recommendations. Architecturally, your competitor's view never crosses your view, and your view never crosses theirs.
-
05 Augmentation
Workforce intent: amplify, never replace
Design-partner contracts explicitly do not include a headcount-savings clause. Outcomes we measure with you are cycle time, OTIF, exception MTTR, onboarding velocity, decision compression — never seats eliminated. The objective is to amplify the operators you have, not to enable their replacement.
-
06 Disclosure
What we don't yet know — and what we tell you up front
Foundation models hallucinate when they're asked to reason without grounded data. Long-running agent reasoning chains can fail in ways the agent can't self-detect. Compliance certifications take time. We tell you what we don't know, what we haven't built yet, and where the platform's edges are — before you sign anything.
A refundable $15K–$100K pilot fee. Three commitments you can hold us to.
OpsATC.AI is pre-revenue. The commercial shape below is honest framing — a price range, not a price; a pilot scope, not a contract; an ask, not a quote. Pricing is structured around four inputs: your vertical, your company size, the number of users, and the scope of system integrations. The design-partner posture below is offered consistently to the first three customers entering pilot before GA. Final terms are set per design partner in the SOW.
Materially-discounted rate, locked for the term.
Pilot customers lock their materially-discounted monthly subscription rate for the duration of their initial contract — 1 year or 2 years, your choice. The rate stays flat through the term regardless of which length you choose. Commercial pricing post-design-partner is TBD and will be set against measured pilot economics; the pilot-discounted rate stays frozen through your contract whichever path you take.
Refundable pilot fee, $15K to $100K.
Pilot fee: $15K–$100K, sized to the scope, scale, and complexity of your engagement — paid up-front as a refundable deposit, not a sunk cost. 2-year contract: pilot fee returns to the customer as a fixed monthly rebate spread across the first six months (net pilot cost: zero). 1-year contract: pilot fee is non-refundable, but the materially-discounted monthly rate still stays frozen for the full year. The longer commitment earns the rebate and the lower lifetime spend, transparently.
Marginal-pricing schedule, disclosed at kickoff.
Adding users, integrations, or workflows during your contract term follows a marginal-pricing schedule documented in your master agreement at kickoff — not in a discretionary uplift conversation later. The cost of the next user, the next integration, the next workflow is in writing before you ever need it.
Materially-discounted monthly, locked
The pilot-discounted monthly rate stays locked for the full contract term — 1 or 2 years, your choice — as a long-term benefit to customers who commit early.
Roadmap influence
Your KPI thresholds, persona library, and workflow shapes land in the shipped vertical configuration — not just inside your tenant. The platform you help shape is the platform that ships.
Direct founder access
On every recommendation The Captain produces against your data, every week of the pilot. Not a triage queue. Not a CSM proxy. Brian, in the loop, in writing.
Reference willingness optional
Optional, not contractual. Named design partners go public with their explicit written consent only — never as marketing. The first named partner will be a milestone, not an announcement.
Pilot duration: 90 days from data-connection live — a full operating quarter of observation, long enough to evaluate The Captain across a monthly close, a planning cycle, and one QBR cadence.
Commercial pricing post-design-partner is TBD and will be set against measured pilot economics — we will not commit to commercial pricing numbers before they are measurable. The full as-deployed design-partner pricing detail lives in your master agreement. Reach out to brian@opsatc.ai for a tailored estimate based on your vertical, scale, user count, and integration footprint.
If you disagree with any of this, that's the call I want.
The principles above are settled in the architecture and the design-partner contract. They're not settled in my head — pushback from an operator who has actually run an operation is the most valuable input the platform gets. Thirty minutes, direct with me.