Built for the operator who can't afford a leak, or a hallucination.

A clear runway, not a checklist

OpsATC.AI is architected against SOC 2 and ISO 27001 from day one. SOC 2 Type I and an independent penetration test are budgeted but not yet initiated; Type II is sequenced to follow, since its observation window can only begin once Type I is in place. We will not claim certifications we have not earned, and we will publish current status on this page as each one is awarded.

Industry-specific attestations (CMMC, ITAR, HIPAA where applicable) considered on a per-customer basis during design-partner contracting. Reach out to [email protected] before evaluation if your industry requires a framework not listed above.

Regulatory disclosure

Every first-session interaction with The Captain includes a verbatim disclosure that The Captain is an AI assistant, and every response surface (chat reply, recommendation card, Logbook entry, daily workbench tile) carries a persistent AI-assistant notice. This disclosure is enforced at the component level — the surfaces cannot render without it — and is designed to satisfy applicable AI-transparency requirements (EU AI Act Articles 4 and 50, California SB-1001, and FTC Section 5 anti-deception guidance). The exact disclosure wording is being finalized; procurement and legal teams can verify the implementation under NDA.

What the platform enforces, by topic

Skeptical buyers want to see what the platform actually enforces, not just what it markets. The ten domains below are the decisions and controls that govern how OpsATC.AI handles tenant isolation, integration, data quality, security, and privacy. The full technical detail behind each one, including the decision records that document it, is shared with design partners under NDA.

The ten domains we govern

• Multi-tenant data isolation: Postgres row-level security enforced at every query; tenant boundary is a database-level invariant, not application-level.
• MCP-native connector architecture: read-only connectors over the Model Context Protocol (MCP); per-connector capability, scope, and write-gate classification.
• The Captain agent runtime: a thin agent over a bounded tool set with a tool-selection chokepoint and per-operation routing; one defined path per workflow, not free-form agent loops.
• Trusted Advisor doctrine: The Captain reads systems of record; writes route through a human-gated approval queue; no autonomous writes to customer systems.
• Data quality detection: layered detection (baseline → inline → scheduled → on-demand) of the six issue classes that erode operator trust: stale records, missing identifiers, duplicate keys, contradictory source-of-truth values, schema drift, and reference-data gaps.
• Security controls: five control families. Live today: per-tenant egress allow-list (read verbs only); a TLS 1.2+ (AEAD) floor with mTLS and per-connector certificate pinning supported in the egress client (we do not force TLS 1.3, which would break older customer endpoints); secrets management via pgcrypto with per-tenant HKDF-derived data keys. On the roadmap: managed-key encryption, distributed per-tenant rate limiting, static egress IPs, and a managed web application firewall in front of the API.
• Privacy & PII Protection: four-tier sensitivity taxonomy applied at the connector boundary. The Forbidden tier (SSN, passport, bank account, ICD-10 diagnosis codes linked to identity, GDPR Article 9 special categories, 42 CFR Part 2 substance abuse records, COPPA minors data) is designed to be filtered at the connector boundary before it reaches The Captain, rather than passed through, even with customer consent or admin override. The Identifying tier (names, employee numbers, customer IDs) is default-deny and not accessible in-product today; the four-gate elevation policy (express written customer permission, signed DPA, per-tenant policy flag, two-person admin approval, all audit-logged) is defined and will be enforced when that access path ships.
• Token governance: per-tenant monthly budgets and per-user daily caps, hard-enforced at the orchestrator with an atomic, race-safe cutoff and an append-only record of every block. A per-operation model router with admin policy knobs ships in the codebase; production traffic exercises a single tier today, and the cheaper and deeper tiers activate as more operation types land. OpsATC runs on an AI provider we manage, with the spend cap checked before every request; because the platform is model-neutral, bringing your own AI provider is on our roadmap.
• Live-read architecture: connectors integrate without ingesting source data into a central lake; The Captain queries source systems live and uses the returned data only to answer the request in-flight, retaining read metadata (system, operation, record count, latency), never the read payload.
• Network Federation (a planned capability): a design that would let two adjacent partners in a real-world business relationship share a defined slice of operational data (e.g., ASN status for one customer's orders, demand for one supplier's parts) without either side losing read-only posture, tenant isolation, or audit. Bilateral acknowledgment before any data flows; scope enumerated as canonical entities plus a filter predicate; every cross-tenant read writes an audit event visible to both tenants; either side revokes unilaterally and instantly. Roadmap, not running: this is design intent, not a shipped feature.

Five operating rules we hold ourselves to

The decisions above describe what the platform enforces. Operating rules describe what we hold ourselves to: explicit organizational rules, internally enforced across every conversation, every commit, every dispatch. The five we publish:

• Honest-stage discipline. Never invent customer counts, quotes, shipped-feature status, or operational data. Pre-revenue framing is explicit. The honest-stage banner above is anchored to a single source-of-truth value in code, not hand-edited copy.
• Four-tier sensitivity model. Forbidden PII (Social Security numbers, passport numbers, bank account numbers, PHI) is blocked by default and never intentionally surfaced, filtered at the connector boundary by design, regardless of consent. Identifying data (names, employee numbers) requires explicit written per-tenant permission. Operational data is default-allow; public data is unrestricted. This four-tier model is defined doctrine; enforcement is being built into the product in stages and is not yet active in the pilot.
• Verbatim AI disclosure. Every first-session message with The Captain includes a verbatim disclosure that it is an AI assistant. Designed to satisfy EU AI Act Article 4/50, California SB-1001, and FTC Section 5 anti-deception simultaneously.
• Single-writer discipline. Only one development conversation modifies a given working tree at a time. Prevents parallel-write corruption and silent commit interleaving. Discovered the hard way; codified after.

These five are a subset of nine operating rules codified internally; four are engineering-discipline rules less relevant to a buyer audience. The full set is shared to design partners under NDA at pilot kickoff.

Full architectural detail, including the decision records behind each control, is shared with design partners under NDA at pilot kickoff. Reach out for architectural deep-dive sessions during contracting.

Read-only by doctrine. The clicks belong to the operator.

The Captain is read-only against every system of record. She reads, reasons, cites, and recommends. She does not issue POs, reroute shipments, or 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.

How this works in practice

• Default mode: advisory. The Captain drafts, recommends, and cites. Nothing changes in your systems of record unless a human user clicks approve.
• OpsATC writes only to its own application data. Notes, scheduled prompts, configuration, draft artifacts (emails, briefs) that you review and send from your own system. Never outbound to your ERP, Kinaxis, Salesforce, or any system of record.
• Approval audit. Every approval is logged with approver identity, scope, and any limits. Structured logging is captured during the design-partner pilot; SIEM streaming (Splunk HEC, Elastic, Datadog) lands with production hardening, post-pilot.
• Kill switch. The Admin Portal is designed to expose a per-workflow disable that immediately pauses The Captain from generating recommendations on the affected workflow. Implementation completes during the design-partner pilot.

The read-only doctrine is defense-in-depth across three layers: a default-deny write-gate registry that classifies every write action, The Captain's tool-selector filtering high-risk writes out before any tool list reaches the model, and a CI lint that blocks any pull request adding an unregistered write tool. Most high-risk writes have no executable code path at all. The full write-gate architecture is detailed under Platform controls above and on the integrations page.

Where your data lives: regions, retention, third parties.

Hosting is in US regions, with EU and APAC residency on the production roadmap. We set out residency, retention, and sub-processor-change commitments in writing in the pilot agreement.

Regions & status

Sub-processors

Every third party that may touch customer data. Additions are communicated to design partners 30 days in advance with an objection window, set out in the pilot agreement. Status reflects current platform integration; design partners receive the as-deployed list before pilot kickoff.

All customer data is hosted in the United States. Other tools we rely on, such as our background-job and agent frameworks, are open-source software we run ourselves on our own infrastructure, so no customer data is shared with the companies behind them. The definitive list is set out in the Data Processing Agreement, and additions are communicated to design partners in advance with an objection window.

Last updated: October 2026.

Strategic independence, in writing

OpsATC.AI is built to operate independently of any single distributor, ERP vendor, or supply chain platform. We include explicit change-of-control protections in the pilot agreement so an acquisition cannot leave you stranded.

Design-partner change-of-control terms

• Perpetual license to the version of the platform you are running at the moment of an OpsATC.AI change-of-control event.
• Source-code escrow with a recognized third-party escrow agent. The escrow account is established at the first design-partner contract execution; release triggers include change-of-control, business-continuity events, and material breach.
• Defined transition window: no less than 12 months, during which the platform continues to operate at current pricing and SLA terms regardless of acquirer intent.
• Right of first refusal on data extracts, configuration exports, and tenant-isolation guarantees during the transition.

These terms are set out in the pilot agreement, available for review under NDA prior to engagement.

Buyer questions, answered straight

Strategic-objection questions we hear from security teams, data leads, and operations buyers during evaluation. Pilot-scope and architectural-pattern markers are preserved: what ships today versus what lands during the pilot is called out in each answer.