Inspiration

Every business runs on systems nobody fully understands. The pricing rule lives in a spreadsheet, the real process lives in someone's head and three email threads, and — worst of all — what the team believes happens usually isn't what the data shows actually happens. Documenting this is what consultants charge thousands and weeks to do by hand.

We wanted to invert the usual AI pitch. Instead of "trust this AI going forward," we asked: can an AI learn how a business already works from its own messy artifacts, prove what it learned against that business's real history, and hand back a working automation — all in one sitting? The key word is prove. Not a plausible-sounding summary, but a number that traces back to the business's own data.

What it does

Operandi learns a real workflow, verifies it, and generates a working automation — an X-ray for how your business actually operates:

  • Learn — you drop in a couple of real files (a spreadsheet of past transactions + a chat/email thread describing how the work is done). It extracts a structured Operational Graph — steps, rules, roles, data flows — tagging every node as DECLARED (a human stated it) or OBSERVED (the data evidences it).
  • Verify — it replays a stated rule against the real history and catches where reality differs. The node flips to PROVEN, or a CONFLICT is raised:

"You said 30% deposit on jobs over £500. Reality (40 real records): the policy was skipped on enough jobs to leave £3,858 in deposits uncollected."

  • Generate — from a proven process it generates a runnable skill (an OpenAI function-tool with a typed schema) plus auto-generated tests, and runs it live on a new input.
  • Recommend — a ranked board of the biggest gaps and automation candidates, scored by effort × impact.

The whole loop runs on real data.

How we built it

We built Operandi with Codex as the pair-builder and GPT-5.6 (OpenAI Responses API) as the reasoning layer, inside a strict TypeScript pnpm monorepo (17 packages, Node 24).

The architecture enforces one rule in code: the LLM proposes, deterministic code proves.

  • Learn is GPT-5.6 via the Responses API with structured outputs — it reads the spreadsheet + thread and emits the Operational Graph against a strict JSON schema, tagging each node DECLARED vs OBSERVED. Every model artefact carries full provenance (model, revision, routing tier, prompt/schema hashes, tokens).
  • Verify is pure deterministic TypeScript. A Rule IR engine compiles the confirmed rule and replays it over the real rows; a separately authored independent verifier re-computes the same answer a different way, and pinned oracle tests lock the numbers. The model never produces the figure a business acts on — only code does. That's what lets a node earn PROVEN, or surface a CONFLICT.
  • Generate runs through a skill sandbox (packages/skill-sandbox) that validates, compiles, replays and escape-checks a generated OpenAI function-tool with a typed schema and auto-generated tests, then executes it live on a fresh input.
  • Govern — any action that would touch a real system goes through the Action Gateway: dry-run → exact approval hash → execute → independent read-back. Nothing writes without a human approval, and missing credentials surface as typed blockers (CONFIGURATION_BLOCKED), never fake success.
  • Persist — Postgres with append-only capture receipts and Supabase RLS enforcing multi-tenant isolation at the database (verified by a cross-tenant zero-rows test).

Codex accelerated the mechanical mass — monorepo scaffolding, contract-to-type generation, the durable outbox/idempotency layer, and the test breadth (RLS, prompt-injection evals, REAL/SIMULATED UI states). The human calls were the trust boundaries: what counts as OBSERVED vs PROVEN, when a finding may be promoted, and the refusal to ever let the model mint a number.

Challenges we ran into

  • Making "prove" real, not rhetorical. The hard part wasn't getting a model to summarize a workflow — it was building the wall that stops the model from inventing the numbers. We had to physically route every business figure through deterministic code with an independent second implementation and pinned oracles, so a finding is either backed by rows or it doesn't exist.
  • Honest failure states. It's tempting to demo a green "success." We chose the harder path: when OpenAI/Composio/Supabase credentials aren't present, the product returns typed blockers and honest SIMULATED states instead of fabricated receipts. Designing for graceful, truthful "not yet" everywhere took real discipline.
  • A generated skill that actually runs. Emitting a function-tool is easy; emitting one with a typed schema, auto-generated tests, and a sandbox that catches escapes before it runs live was the real engineering.
  • Replay determinism inside a time-boxed demo. Live OAuth + model calls have variable latency, so we made the presentation replay immutable cached model artefacts (timestamps/provenance preserved) while the deterministic verification and the governed action run live.

Accomplishments that we're proud of

  • The Verify step catches what humans miss. The moment a stated rule ("30% deposit over £500") collides with the real history and flips to a CONFLICT with a pound figure attached — that's the whole product in one screen.
  • DECLAREDOBSERVEDPROVEN / CONFLICT as a first-class, code-enforced classification. Trust is a data type here, not a vibe.
  • A runnable, tested, sandboxed generated skill — not a code snippet, an actual OpenAI function-tool the business can invoke.
  • Full provenance + pinned oracles + independent verifier — the numbers are reproducible and auditable end to end.
  • Green locally with zero API keys. The seeded demo runs the whole arc offline, so a judge can see it work in minutes.

What we learned

  • "Prove it" beats "trust it." The strongest reaction was never to a slick summary — it was to a number that traced back to the business's own rows. Evidence is the product.
  • Scope is a feature. One workflow proven end-to-end (learn → verify → generate → govern) is worth more than 250 shallow integrations. We deliberately rejected breadth for a provable loop.
  • The trust boundary has to be structural. "The model shouldn't make up numbers" only holds if the architecture makes it impossible — separate verifier, pinned oracles, typed blockers. Guardrails written as prose don't survive contact with a demo.
  • Codex changes the ratio. With Codex carrying the scaffolding and test mass, the scarce human hours went where they mattered: the honesty architecture and the classification model.

What's next for Operandi

  • Close the real-client loop: one consented client, a live Composio OAuth read → governed real write → independent read-back with retained redacted hashes, and a live GPT-5.6 evaluation against a redacted dataset.
  • Always-on sensing: scheduled polling of connected systems (auto-sync plane already scaffolded) so gaps are caught early — before problems grow.
  • Exception-first auditing: capture the overrides and edge cases ("ignore the second attachment," "Sarah already signed off") that live only in people's heads.
  • Deliverables clients forward upward: an exportable Operating Map, and auto-generated business + technical briefs from one engagement.
  • Deploy where the data must live: SaaS today → private-cloud single-tenant → self-hosted (ops/self-host/) → air-gapped local-model mode for regulated industries.
  • Extensive client onboarding experience: Make it dead easy for clients to onboard, connect, upload and talk with the data, visualise and see what data/connectors/systems are probably the blockers or lossy, etc.
  • Make connectors intuitively simple to integrate: Use innovative mechanisms for Operandi to auto learn and adapt to various interfaces, versions and formats.

Built With

Share this project:

Updates