Four deployments, no client names.
The organizations below have not authorized us to use their names, so we do not. What we can describe is the constraint, the architecture, and the outcome — which is the part that tells you whether we can help. A vendor who leaks one client's name will eventually leak yours.
Verification coverage for safety-critical embedded software
The constraint
A verification organization maintaining requirements across hundreds of PDF, Word, and Excel specifications, with tests needing to live in a structured ALM tool. Model-based design repositories defined real system behavior with no corresponding coverage, and thousands of legacy tests carried inconsistent structure, no signal enrichment, and no requirement traceability. Manual modernization had been costed and rejected as arithmetically impossible.
What we built
A knowledge base built by parsing the actual source into roughly 35,000 signal entities and 45,000+ embedded code chunks, with three generation paths on top of it: requirement documents, source repositories, and merged pull requests. A fourth path reads existing tests from suites and retrofits them to a golden structure with a field-level diff. Eight subsystems in total, each isolated, fail-open, and independently kill-switched so the rollout could proceed one capability at a time.
The non-negotiable
Nothing reaches the ALM tool without human review. Every generated case stops in a queue with the source requirement and matched signals displayed alongside it, and a grounding critic rejects anything referencing a signal absent from the index before a reviewer ever sees it. In a regulated verification context, an unattended write into a test plan is a defect — so the system does not have that capability at all.
At a glance
- Signal entities
- 35,000+
- Code chunks
- 45,000+
- Generation axes
- 4
- Subsystems
- 8
- Unreviewed writes
- 0
Autonomous revenue workflows that security would sign
The constraint
The organization wanted agents to qualify accounts, run competitive analysis, produce pricing proposals, and update the CRM. Every one of those is a write, and the security position was unambiguous: no proprietary customer data crosses the perimeter, no agent updates a system of record without a human, and any answer used in a forecast has to be traceable to its source. A read-only assistant had already been built and abandoned as not worth operating.
What we built
A two-plane architecture. Orchestration holds no customer data; the execution plane runs inside the customer VPC, where agent-generated code executes in hardware-isolated MicroVMs behind an eBPF egress filter and DNS sinkhole. A semantic router is designed to classify each turn in under 100 milliseconds so follow-up questions reuse a cached agent specification instead of recompiling. Connectors are declarative YAML manifests, so adding a system is a configuration commit rather than a release.
The part that mattered
Citations are generated deterministically by the backend from the tool-call record, never by the model, and markers the model invents are stripped before rendering. That single property is what moved the conversation from "can we trust this" to "which systems do we connect next" — because a number in a forecast could now be opened to reveal the exact query that produced it.
At a glance
- Automated tests
- 1,800+
- Test failures
- 0
- Production modules
- 60
- Catalog navigated
- 50,000+
- Data leaving the VPC
- 0
Clearing a business intelligence backlog without hiring
The constraint
A standing queue of dashboard requests measured in months, against sources scattered across cloud warehouses, a lakehouse, finance workbooks, and quarterly PDFs. Business units had begun building shadow spreadsheets rather than waiting, which meant the organization was quietly losing the single source of truth it had spent years establishing. Headcount was not available, and the requests were mostly variations on dashboards the team had already built many times.
What we built
A pipeline that takes a plain-English request plus a governed source and emits a native Power BI project folder — semantic model, relationships, DAX measures, report pages, theme — in 30 to 90 seconds. Nineteen connectors cover five cloud warehouses and fourteen file and service adapters, including the awkward sources where the real reporting actually lives. Inference decides what the dashboard should contain; deterministic builders emit the output format, which is why the artifact is valid rather than approximately valid.
The economics
A schema hash check runs before anything else, so a scheduled rebuild against an unchanged structure skips inference entirely and repackages the previous configuration. Since most rebuilds are refreshing data against a stable schema, the steady-state cost of keeping the estate current settled close to zero — which is what turned this from a pilot into standing infrastructure.
At a glance
- Build time
- 30–90s
- Connectors
- 19
- Automated tests
- 750+
- Correction loops
- 3
- Inference on cached rebuild
- 0
Researched outreach at a volume no small team can staff
The constraint
A professional services firm selling complex technical work had no room for a volume outbound motion. Templates do not survive contact with a technical buyer, and a damaged sending domain would have taken contracts and invoices down with it. The only viable approach was genuinely researched outreach — which their team could produce at perhaps five accounts a day, nowhere near enough to build a pipeline on.
What we built
A nine-stage pipeline that discovers qualifying organisations from public filings, federal award records, higher-education registries, and web research; enriches each through a four-tier firmographic waterfall so research works from real size data rather than inference; routes the binary qualification decision to a fast model tier and the nuanced research to a deep one; resolves an executive contact through ranked commercial providers; and clears a three-tier deliverability firewall before anything is drafted.
Where it deliberately stops
At the drafts folder. Every message is read by a person before it goes. Nothing in the pipeline has send authority, which is what made the system approvable by a leadership team that owned the sending domain and could not risk it. The limitations we publish for this platform are specific rather than generic because they are the ones this deployment actually hit.
At a glance
- Pipeline stages
- 9
- Discovery sources
- 4
- Verification tiers
- 3
- Guessed addresses
- 0
- Unreviewed sends
- 0
Why there are no logos on this page
Reference logos are the standard currency of enterprise sales, and their absence here is deliberate. The work above touches proprietary product architecture, internal control systems, and revenue data. Naming the organizations would tell you something about our sales pipeline and nothing about whether the architecture fits your problem.
In a briefing under mutual non-disclosure we can go considerably deeper — architecture decision records, the actual failure modes we hit, and what we would do differently. If a named reference is a procurement requirement for you, say so early and we will ask a client directly rather than assume.
Yours would be the fourth.
And we would not name you either.