The first quarter is a fixed package: three of your systems imported, one Core Model harmonized across them, the conformance contract exported, and your agents connected through the MCP endpoint — built with your engineers, so the capability stays when we leave. Expansion quarters are scoped from there.
Published · Revised
$75,000First quarter, fixed — import three systems, one Core Model, the MCP endpoint, licence included; expansion quarters $60,000 – $180,000 by scope
Cadence
Per quarter
Fee
$75,000 first quarter, fixed
Basis
First quarter: three systems imported, one Core Model, the MCP endpoint; includes the CoreModels licence for the engagement term. Expansion quarters $60,000 to $180,000 by scope, fixed at quarter start
Prerequisite
Assessment or equivalent
Deliverables
The Core Model: three systems’ schemas imported — as JSON Schema, JSON-LD or ShEx, or through the connectors coremodels.io lists — into one workspace spanning them
Harmonization: cross-system mapping and terminology agreed across the teams that own each schema, with the change log as the record
The conformance contract exported to JSON Schema, JSON-LD or ShEx, whichever each boundary enforces, and applied at the validation stage
Retrieval and agent wiring through the CoreModels MCP endpoint on your own agent API key
Quarterly implementation plan, runbooks, and handoff packages for operations teams
Detail
The engagement in full
What it is
Implementation is where the blueprint becomes running infrastructure. The first quarter is a fixed package at $75,000: three of your systems imported, one Core Model harmonized across them, the conformance contract exported, your agents connected through the MCP endpoint, and the CoreModels licence included for the term. Expansion quarters are scoped from the blueprint’s sequencing and priced by that scope, $60,000 to $180,000 — a further single-domain build with one pipeline sits at the bottom of the range; a multi-source estate with validation gates and an evaluation harness sits at the top. You know which you are before a quarter begins, because the blueprint already priced it.
The middle of every implementation quarter is the Core Model. We facilitate the import — your existing schemas come in as JSON Schema, JSON-LD or ShEx, or through the connectors coremodels.io lists, rather than being re-authored — and then the harmonization, which is the human part: the teams that own each schema agree, in the model, how their definitions relate, with the change log as the record of what was decided and why. What comes out is exported to whatever each boundary enforces and read by your agents through the MCP endpoint. The licence for the platform is included for the engagement term; the model is yours.
We build with your engineers rather than around them. That is a delivery philosophy with teeth: pairing during the build, runbooks as first-class deliverables, and handoff criteria agreed at quarter start. The test of a quarter is not that the system works while we are in the building — it is that your team operates and extends it after we are not.
The prerequisite is an assessment or equivalent. Equivalent is meant honestly — if you arrive with a rigorous internal diagnosis, we build against it. What we will not do is build against a guess, because a quarter of engineering aimed at the wrong stage is the most expensive way to discover which stage was actually broken.
Who it is for
Teams holding an approved blueprint whose engineering capacity is committed to the product roadmap
Organizations that want the first domain built as a pattern transfer — our build, your engineers alongside — and intend to self-serve the remaining domains
Programs with a hard external date — a regulatory deadline, a launch — that need specific stages production-grade by a quarter boundary
Anyone whose last agent initiative died in the gap between a good plan and a maintained system
What gets built, by stage
Structure — schemas authored where none exist, imported and reconciled where they do; content pipelines that emit machine-legible shape instead of prose with headings
Semantics — one governed model of what your business objects are, mapped across the systems that name them differently. CoreModels is typically the authoring layer here: it is where the model lives, and it exports the conformance contract the next stage enforces
Validation — conformance gates that check content against that contract before an agent reads it, so plausible but superseded gets caught at the boundary instead of in front of a customer
Retrieval — structure-aware retrieval that uses the model rather than resemblance alone, stood up alongside an evaluation harness seeded from the assessment's ground-truth set, so retrieval quality is a measured number from day one
Agent operations and learning-loop plumbing — instrumentation so production behavior is observable, and the pipework that lets failures reach the people and systems that can act on them
A given quarter builds a subset of these. Which subset is exactly what the scope fixes.
How a quarter runs
Scope and acceptance criteria are fixed in the first week. Build proceeds with your engineers embedded, on a weekly cadence with working software as the progress measure. The final weeks are handoff: runbooks completed, operations walked through, acceptance criteria checked off item by item. Access is scoped explicitly at quarter start and limited to the systems in that quarter's scope — no standing keys to the estate.
If mid-quarter reality argues for a scope change, the change is written down and traded against something of equal size. The fee does not move; the scope does not silently grow or shrink.
What you walk away with
Implemented context pipelines across the agreed stages, running in your environment, owned by you
The structure and semantics layers wired into your actual data and agent workflows — not a reference architecture, your architecture
Validation gates enforcing the conformance contract at the boundaries that matter
Runbooks and handoff packages your operations team has already rehearsed against, plus artifacts your procurement and technical evaluators can review, accept, and operate against
Engineers on your side who built it with us and can extend it without us
The situations this exists for
The committed roadmap
The blueprint is approved, the funding is real, and every engineer who could build it is committed to the product for three quarters. Implementation is the difference between a funded plan and a shelved one.
The pattern transfer
A capable platform team wants the first domain — say, the product catalog — built as a working exemplar, with their engineers pairing throughout, then intends to replicate the pattern across the remaining domains themselves. The fixed first quarter, deliberately structured for imitation.
The date that will not move
A regulatory requirement lands in nine months and demands provenance and validation on everything a customer-facing agent reads. The blueprint sequences two quarters; the quarters are scoped backward from the date; the acceptance criteria are the regulation's language, not ours.
What it is not
It is not staff augmentation. You are buying scoped outcomes with acceptance criteria, not hours. If what you need is engineers on demand, there are better ways to buy that.
It is not open-ended time-and-materials. The quarter's scope is fixed at its start, and the trade-a-change discipline exists to keep it that way.
It is not model work. We do not fine-tune models or promise model behavior; we build the chain that determines what models are given. In our experience that is where the leverage is — and the assessment you arrived with is the evidence for that claim in your estate, not a slogan.
Pricing
This engagement on the ladder
Rung 4
Implementation
$75,000First quarter, fixed — import three systems, one Core Model, the MCP endpoint, licence included; expansion quarters $60,000 – $180,000 by scope
Buyers with an approved blueprint ready to deploy.
First quarter fixed: three systems imported, one Core Model, the MCP endpoint
Stages wired into operations
Retrieval and agent operations standup
Validation gates in the supply chain
Handoff criteria and runbooks
CoreModels licence included for the engagement term
The interview, then a written fixed-scope fixed-fee proposal. We recommend starting at the Agent Context Cost & Failure Audit — it is approvable without a steering committee. Nothing requires you to enter at the bottom of the ladder — a Diagnostic Briefing within ten days of the interview is common when the funding decision is contested.
What system access do you need?
Assessment work is read-only: usage telemetry, a content sample, and time with the people who own the sources. Implementation access is scoped explicitly at the start of each quarter and is limited to the systems in that quarter's scope.
Who owns the deliverables?
You do. Reports, blueprints, runbooks and code produced in an engagement are yours outright. A blueprint you commission from us can be executed by your own engineers or by another partner — that is a deliberate property of how the ladder is priced, not a concession.
What does assessment or equivalent mean in practice?
It means we need a measured diagnosis and a sequenced target before we build — ours or yours. If yours is rigorous, we build against it and say so. If it has gaps, we will name them in the scoping call, and sometimes the honest answer is a short diagnosis phase before the build quarter.
How much of our engineers' time does a quarter take?
Plan for one to two engineers meaningfully embedded — enough to pair through the build and own the runbooks at handoff. Less than that and the capability leaves when we do, which defeats the design of the engagement.
When two systems disagree on the same metric, how is it resolved and can I reproduce yesterday's answer?
The disagreement is resolved as a mapping in the Core Model, approved by the owner of each schema, and recorded in the change log with who changed what and when. Agents read the model through the MCP endpoint, so an answer traces to the model version it was read from. Version history is a Team and Enterprise feature on coremodels.io; with it in place, yesterday's version is read back, and the answer with it.
What evidence do you hand my auditors when an agent answer becomes a finding?
The change log, showing who changed what and when. The exported conformance contract in force at the time. The mapping the answer depended on, and who approved it. And, on Managed Operations' Ops + Eval, the incident attribution: whether the failure was in the context, the model or the application.
Every refuse or warn decision is a record with named fields: who approved the mapping and when, the timestamped freeze record tied to the contested mapping id, who ran the check, the agent or workflow id that asked and a hash of the input it sent, the UTC timestamp, the Core Model project with its schema version and the element version in force, the ShEx shape and the mapping it failed, the check that fired and its reason code, and the answer that was refused or warned. Records are retained for the period set in your engagement letter, alongside your other audit artefacts. Your named control owner, and anyone they authorize, can export the pack as JSON at any time.
What is deterministic is the decision, not the prose: for a given contract version and mapping, the same input produces the same refuse or the same warn every time. Your evals assert that decision, not the prose. A generated answer is not reproducible word for word, which is why the boundary, not the model, is what you audit. The engagement maps each boundary check to a control in the framework you already report against — BCBS 239, Solvency II, IFRS 17 and 21 CFR Part 11 are the shapes it takes most often.
When an agent answer becomes a finding, that pack — the refuse or warn record, the approved mapping and the contract version in force — is what your auditors receive, and because the decision is deterministic they can re-run it without us in the room.
