Core Model Blueprint

The Core Model Blueprint is where directional judgment becomes measurement, on one named agent workflow. Where the Diagnostic Briefing places you on the maturity scale from a half day of structured discussion, the Blueprint earns the placement: content is sampled, retrieval is tested against a ground-truth question set, semantic drift is checked across the systems the workflow reads, and every score on the L0–L5 card carries an evidence note saying what was examined and what it showed.

Diagnose is, concretely, a connector assessment. Every system the workflow reads structure or meaning from — data and content platforms, the warehouse, APIs, ontologies, the wiki that has quietly become a source of truth — is inventoried with the format it speaks and the connector or public standard it would need to feed one governed model. Blueprint then sequences the Core Model itself: what imports first, how the schemas harmonize, what conformance contract the boundaries enforce, and which agents read from it through the MCP endpoint.

It splits into two separately priced phases, and the split is real, not decorative. Diagnose ($15,000, roughly two weeks) establishes what is true. Blueprint ($17,500, roughly two weeks) decides what to do about it. You can commission the first and decline the second — the diagnosis is a complete deliverable on its own, and some clients take it to their own engineering organization and stop there. That is a supported outcome, not a failed sale.

Capacity is genuinely limited to three engagements per quarter. This is a delivery constraint, not a scarcity device: the assessment is run by the practice lead, not staffed out, because a scorecard is only as good as the judgment behind the evidence notes.

Scope is one named agent workflow, chosen with you at kickoff — usually the one the Audit or the interview map pointed at. That is a tightening, on purpose: seven stages measured for one workflow yields a Core Model your engineers can build next quarter; seven stages surveyed across an estate yields a report.

• Enterprises with multiple agent pilots on multiple retrieval stacks and no shared answer for why quality varies between them — and one workflow they would fix first
• Regulated organizations that must show what an agent read, where it came from, and what checked it — and currently cannot
• Teams that funded diagnosis after a briefing, and want the implementation decision made on measurement rather than momentum
• Engineering leaders who intend to build the fixes themselves and want the diagnosis and sequencing done by someone who has seen the failure patterns before

Each of the seven stages gets its own examination for the named workflow, with method matched to stage:

1. Sources — inventory of what content exists, who owns it, and freshness sampling: how much of what agents can reach has been superseded, and would anyone know
2. Structure — a content sample audited for machine-legible shape: what has schema, what has convention, what has neither
3. Semantics — drift check across systems: does “customer” (or “policy”, or “asset”) mean one thing everywhere it appears, and where the meanings fork, does anything record the fork
4. Validation — inventory of what checks content before an agent reads it; usually the shortest chapter, which is itself the finding
5. Retrieval — fitness testing against a ground-truth question set built with your domain owners: what should have been returned versus what was
6. Agent Operations — observability review: when an agent misbehaves in production, what signal exists, who sees it, and how fast
7. Learning Loop — the uncomfortable question, asked with evidence: when did a failure last change the system, and can you point at the change

Output: the L0–L5 maturity scorecard, one score per stage, each with evidence notes and a gap analysis. Not an average — a chain is as strong as its weakest defended stage, and the card says which stage that is.

The blueprint answers three questions the diagnosis raises.

Not L5 everywhere — recommending maximum maturity across the board would be malpractice by spreadsheet. A customer-facing regulated workflow and an internal drafting assistant justify different targets, and the blueprint sets targets per stage per use case, with the reasoning shown.

Sequencing by dependency and risk. Retrieval built on unstructured sources rebuilds itself in a year; the blueprint sequences so no quarter's work is torn up by the next quarter's.

The first implementation quarter scoped against the fixed package on the next rung, and any expansion quarters priced by scope — so what you carry into a funding conversation is a costed plan, not an aspiration.

And one more, made explicitly: a go or no-go recommendation, including “do not implement yet”. If the honest read is that your sources need an ownership model before any build is worth funding, the blueprint says so, in writing, at the cost of the larger engagement it forgoes.

• The seven-stage current-state map of the workflow’s context supply chain
• The L0–L5 scorecard with per-stage evidence notes — procurement-ready, and reusable in vendor evaluations far beyond this engagement
• A prioritized remediation roadmap, sequenced by dependency and risk, with the first implementation quarter costed
• A written go or no-go recommendation
• Everything owned by you outright — executable by your engineers, by another partner, or by us; the ladder is priced so that this is a real choice

A large organization ran agent pilots in three business units; one performs well, two do not, and each team has a theory involving another team's systems. The Blueprint replaces three theories with one measured answer on the workflow they pick first — typically the difference lives in the stages, not the models, and the scorecard shows exactly where.

A compliance function asks the AI team to show what an agent read before it answered, and the honest current answer is a retrieval log nobody can interpret. The validation and agent-operations chapters of the diagnosis become the gap register the compliance program is built against.

An engineering organization fully intends to do the implementation internally — it wants the diagnosis, targets, and sequencing from someone who has watched these chains fail before. Diagnose-only, blueprint declined or taken and self-executed, is a designed-for path, and the deliverable ownership terms exist precisely for it.

• No code is shipped and no system is changed. Access is read-only: telemetry, a content sample, and time with the people who own the sources.
• It is not an audit of your models. When the model genuinely is the limit, the diagnosis says so — but in most estates we examine, model limits are the smaller share of the failure surface, and the evidence notes let you check that claim rather than take it.
• The blueprint is not a proposal in costume. It is priced, sequenced engineering scope that any competent team can execute. If it only made sense when we execute it, it would be a sales document, and it would be worth less to you.