Jump to another pillar
VAO · pillar 03 · the delivery methodology
How vertical domain expertise gets built, taught and turned into an asset that travels — run as a sequence of workshops, not a project plan.
Part one
The four assets the Solution Consultant walks into the room with
The Solution Consultant is the more technical customer-success role on the delivery team — the person who owns the pre-built material below and carries it into every workshop.
An opinionated model of the domain's core objects, built for an archetype rather than for one account. Designing it from scratch takes quarters.
Opens with — here is the model we use for operations shaped like yours; where does it not fit?
A typed catalogue of recurring disruption classes, each with its trigger, its candidate actions and its learning target already defined.
Opens with — here is the shortlist operations like yours usually need solved; which do you recognise, and what is missing?
For known situation types, a draft set of competing strategies already articulated elsewhere and generalised in through a consented process.
Opens with — here are the ways operations like yours resolve this; which do your practitioners use, and which is wrong here?
A simulation environment and a calibration methodology that already exist and are not rebuilt per account.
Opens with — here is how we measure trustworthiness before anything touches live, and the bar we hold everywhere else
The rule this creates. No workshop opens with a question the client must answer from nothing. Every session opens with a draft, a benchmark, a shortlist or a reference model, presented explicitly as a hypothesis to be confirmed, corrected or overridden — never as a finished answer. This is a constraint on how sessions are run, not a talk track added afterwards: if the Solution Consultant arrives without the relevant pre-built material, the session is not ready.
Five tests, applied before a single workshop is scheduled
Is there a named routine? A recurring rhythm with a schedule, participants, and a measure of whether it went well.
Do good practitioners disagree? If they converge on one answer it is a calculation, not a judgement — and a solver is the right product, not a taught agent.
Is the expertise written down nowhere? Spread across people, visible only in what they do.
Can the delivery org reach the systems where the change is actually made? Or get approved to.
Is each decision worth materially more than it costs to think about?
The standing rule-out list: pure query and reporting, single changes inside one system, areas where experts agree, anything checkable instantly.
Part two
CS lead running the opportunity · one operations-side sponsor
The five tests and the rule-out list above as the framework — patterns seen from similar archetypes: here is what we usually find at operations like this.
A qualification record — pass or fail per test, with the reasoning, per product family or site.
Go or no-go on proceeding, owned by the delivery lead — not by the account executive alone.
One session per operating role, plus a leadership session on archetype
The pre-built object model for the archetype we believe this account fits, presented as a hypothesis to confirm or correct. The routine catalogue from comparable accounts as a checklist to accept or reject line by line.
Run the interview template in order, and shadow the routines in parallel. Interview answers are not a substitute for observation.
Confirmed archetype · a before-state routine map · candidate situations, each flagged as matching the library, a variant of it, or genuinely new.
Archetype recorded as a dated attribute. Nothing gets committed to the pilot.
Managers of the W1 attendees, or a group with authority to commit scope
The library's known-situation shortlist for this archetype, with the use cases already sketched from prior deployments — presented as the starting ranking.
Cross-reference the shortlist against W1's candidates. Rank by value at stake and by reach if solved once. Separate what needs agents from what graph analytics alone can answer.
A ranked shortlist, each type marked known (library strategies exist) or net-new.
Which types enter the pilot — and whether it deliberately includes one known type, so the account sees the library in action rather than only a bespoke build.
Data and platform engineers · the account's integration owner · sponsor for sign-off
The reference graph schema already built for the confirmed archetype — a starting configuration to ingest against, not a whiteboard design session.
Ingest the deterministic core across the stack for the chosen scope, map dependencies, begin logging actual-versus-promised behaviour.
A validated graph covering the chosen scope.
The account validates the graph model before any agent is deployed against it.
The practitioners who hold the judgement · a machine-teaching lead
For a known type: the draft strategy set generalised from comparable accounts — here are the ways we have seen this resolved; tell us which apply, which are wrong, and what is missing. For a net-new type: build on the nearest comparable type.
Decompose into skills. Work the draft strategy by strategy — confirm, correct or reject each. Build the selector against the features practitioners actually use.
A situation-type playbook: skills, strategies, selector logic, written into the graph as portable configuration — each strategy tagged as carried, adapted, or taught net-new here.
Strategies and selector logic are validated.
Machine-teaching lead · evaluation owner · one practitioner for spot review
The existing simulation environment and benchmarks — the same one used everywhere else, so the client is held to the same evidence as every other.
Rehearse the taught type against historical and simulated cases. Measure predicted versus realised outcomes before any live authority exists.
A proving-ground calibration record — predicted versus realised, with no live authority yet.
Whether calibration is sufficient to propose moving up a level.
Account sponsor · delivery lead · machine-teaching lead
The four steps, already defined and used at every other account — the agent watches only, then suggests, then acts with someone signing off, then acts alone. Plus a plain account of how similar decisions have progressed elsewhere, without naming another customer, so nobody has to invent a standard from nothing.
Go through the evidence together — what the system predicted, what actually happened, and how often it was right. Then decide the step, one situation type at a time. Never a blanket permission across everything.
A signed record of what the agent is allowed to do, with the evidence behind it.
The customer decides. It is granted, not assumed — and it comes back down the same way if the agent starts getting things wrong.
Delivery lead · certified partner lead where one is used · account sponsor
The library’s next-best-types recommendation for this archetype — a proposed sequence based on what has paid off at comparable accounts, not a blank what do you want next.
Decide what is known-library activation versus net-new teaching going forward, and confirm the partner boundary explicitly: a partner may build and deploy a known type; only the machine-teaching function may decompose and teach a net-new one.
A scale-out plan naming which known types deploy next, and which net-new types are queued.
The certification boundary for this account, and who owns graph maintenance from here.
Part three
A candidate situation type surfaces — cross-referenced against the pre-built taxonomy, not invented from zero.
Workshop 1Does it pass the five tests? Is it worth teaching, or does it belong to the deterministic kernel or a solver instead?
Workshop 0 · a rule-out, not a scoping problemValue at stake, frequency, and blast radius if solved once and reused everywhere it recurs — opened with the library's known reach patterns, corrected against this account.
Workshop 2Break the situation into skills — atomic, and separately evaluable.
Workshop 4Open with a draft strategy set from the library where one exists; validate, correct or displace it with the practitioners who hold the judgement. Never present it as final.
Workshop 4Build or adapt the selector — the feature set that decides which strategy applies to which instance of the situation.
Workshop 4The taught decomposition is stored as a situation-type playbook — strategies, selector, evaluation suite, and the limit on what the agent may do on its own. Configuration, not code, so it is portable across customers and sites.
Workshop 4Rehearse in the existing proving ground against measurable benchmarks, before any authority is granted.
Workshop 5The agent moves from watching, to suggesting, to acting — one step at a time, only when the evidence shows it has been getting this right, and only with the customer's sign-off.
Workshop 6Every executed action’s outcome writes back onto the behavioural edges — and, under the consented generalisation clause, may in time refine the draft the next account opens with.
Workshop 7 · and continuously thereafter↺ Step 10 feeds step 01 at the next account. That return path is the entire asset — everything else is delivery.