// For the person who was sent this link
Everything you can check before you hire us.
Somebody on your team wants to hire a firm of our size. The hard part of that decision is not whether we can do the work. It is whether the choice holds up in front of a board, a CISO and a procurement committee.
Every line below is checkable before you sign anything.
Who is actually on your account
The engineers on your account are named in the proposal, with the systems they've built, and you meet them before you sign.
- Named individuals, not roles.
- No delivery team behind them. The person in the room is the person writing the code.
The surfaces we will and will not touch
We build through sanctioned integration surfaces, and a build that would need an unsanctioned one is declared in the proposal rather than discovered at implementation.
- Will: Guidewire Cloud API, Application Events, Integration Gateway, Cloud Data Access. Duck Creek's gateway and its MCP and A2A interfaces. ACORD AL3.
- Will not, without your explicit decision: direct database reads, Gosu plugins on cloud instances, screen scraping, robotic process automation.
- General-availability status is verified against the vendor's own documentation before scoping, not after.
What happens when the model changes
Nothing we build depends on one AI vendor. The rules, data handling and audit trail are deterministic code, and the AI sits behind a stable interface. When a better model ships, we swap it and the workflow stays put.
- Model, version and prompt version are recorded on every written decision, so a swap is auditable rather than invisible.
- The evaluation corpus is yours, which is what makes a replacement testable before it is trusted.
- No pricing, no roadmap and no contract term of ours depends on which model you end up running.
What ships for your compliance file
Every build ships with a governance file: model inventory with risk tier, data lineage, pre-deployment bias testing and the annual re-test procedure, drift thresholds with remediation triggers, human-override specification with a named decision-maker, and the vendor-validation record.
- Roughly half the states have adopted the NAIC AI Model Bulletin, and the variations are material.
- Responsibility is non-delegable. New York DFS states that an insurer “may not rely solely on a third-party's claim of non-discrimination or a proprietary third-party process to determine compliance with anti-discrimination laws.”
- If the deliverable does not include the governance artifact, it cannot deploy. So it is scoped with the build, not after it.
What you own, and when
What gets built is yours, and it is yours as the work happens rather than at the end of it.
- Code, schema, transformations, tests, runbook and documentation live in your repository.
- It runs on your infrastructure throughout.
- We keep the tools and methods we arrived with, the way any firm does, and the contract says so.
- The contractual mechanism, the assignment language itself, is in the master agreement, and we will send it before you ask.
How the handover works, and what partnership obliges us to
Exit criteria are written at kickoff, not negotiated at the end, and we are measured on your team running it without us.
- An owner is named on your side before go-live.
- Runbook, monitoring, alerting, retraining procedure and escalation path are deliverables, not documentation debt.
- Launch budgets fund development and implementation, not monitoring, retraining, documentation or user support, so the operating model is scoped with the build.
- We publish four conditions we call partnership and hold ourselves to them: the people who sold it build it, your engineers are on the team, you own the asset from the first commit, and we are measured on you not needing us.
What an engagement costs, and what it does not include
Discovery is four weeks, fixed scope, and the fee is quoted before work starts. The build is scoped from it.
- Discovery excludes any build, any production change, and any commitment to a next engagement.
- The build is priced from the Discovery output and is never priced publicly, because it is never the same twice.
- The build fee is fixed before work starts. Continuing to run and improve what we built is a separate agreement and your call.
Where your data lives
Everything we build carries role-based access and audit logging, and the subprocessor list is named. The master agreement carries the data-handling terms, and it goes out with the proposal rather than on request.
- Data stays in your tenancy. Where a step cannot run there, we name it in the proposal and you decide.
- Named subprocessor list, kept current, sent with the proposal rather than on request.
- Three terms your security review asks first — training use, subcontracting, and substitution of a named engineer — are with counsel for wording.
- We answer a model-governance and explainability questionnaire for anything touching a regulated decision.
What we can prove, and what we cannot
We ran a carrier for a decade and one of those builds is published in full. We have no review-site profile and no analyst placement, and analyst relations is a 2027 project.
- Can prove: the operating record on Origins — Clearcover, verified July 2026 — and one published build, servicing, with its definitions.
- Cannot prove yet: a Dearborn Labs delivery number. No time-to-production, no cost-per-build. We will not borrow an industry average and present it as ours.
- That gap closes with our own measured data or it does not close.
What a board will ask, and the answer in each case
Written so it can be forwarded as it stands, and restated in your own words in ninety seconds.
- “Why not the incumbent integrator?” The incumbent implements the systems every carrier can buy. This work is the part that is supposed to be different, built by people who have run the job rather than staffed it.
- “What if they disappear?” The code, the schema and the runbook are on the carrier's infrastructure from the first commit, and the exit criteria were written at kickoff.
- “What is the exposure?” Four weeks, fixed scope, quoted before day one, with no build commitment attached.
- “How do we know it works?” The baseline is instrumented in week one, before anything is built, so the improvement is measured against your own starting number.
Everything above is restated by name in the proposal, so it is a commitment before it is a claim. If it holds up, the person who sent you this can start with one workflow.
Read the evidence, then get a read on one workflow.
Every claim on this page is checkable before you sign anything.