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
A pure services engagement cannot open with a draft. That is the whole difference, and it has to be visible in every session.
A client who spends three workshops answering questions and watching their own answers written back to them concludes, correctly, that they paid for a facilitator. A client who watches the delivery team open with a draft — a taxonomy that already exists, strategies already taught at comparable operations, a simulator already running — concludes they are buying a product with expertise embedded in it, and that services is how it gets fitted to them.
The four assets that walk into the room before the client does
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 delivery lead arrives without the relevant pre-built material, the session is not ready.
Two failure modes, named because both are commonThis is not telling the client what to do. The draft is corrigible by design. A draft that is never challenged in the room means the elicitation was too polite, not that the library was right.
And it is not collateral read aloud. The pre-built material has to be specific to the archetype and the situation under discussion. A generic industry deck produces exactly the reaction the exercise exists to avoid, delivered with more slides.
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?
A no on any of the first four is a rule-out, not a scoping problem to work around. The standing rule-out list — pure query and reporting, single changes inside one system, areas where experts agree, anything checkable instantly, and frequent low-stakes decisions — does not get softened per account.
Part two
CS lead running the opportunity · one operations-side sponsor
The five tests and the rule-out list as a stated framework — plus, where the sector has been seen before, the archetype and situation pattern typical of it: 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 — never a blank list your routines.
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. Pilot scope deferred.
Managers of the W1 attendees, or a group with authority to commit scope
The library's known-situation shortlist for this archetype, with the reach pattern already sketched from prior deployments — presented as the starting ranking, not the final one.
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 (teaching starts from elicitation).
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: the decomposition pattern from the nearest comparable type, as scaffolding.
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.
Whether the strategies are genuinely distinct schools of thought. If practitioners converge on one, the type fails test 02 retroactively and reverts to a deterministic rule — and that reversal is recorded, not quietly dropped.
Machine-teaching lead · evaluation owner · one practitioner for spot review
The existing simulation environment and benchmarks — not a validation approach invented for this account, but the one used everywhere else, so the client is held to the same evidence bar as every other.
Rehearse the taught type against historical and simulated cases. Measure predicted versus realised outcomes before any live authority exists.
A calibration record at shadow level.
Whether calibration is sufficient to propose moving up a level.
Account sponsor · delivery lead · machine-teaching lead
The delegation ladder and evidence standard as already defined — shadow, recommend, commit-with-review, unsupervised — plus a qualitative account of how comparable types have progressed, without disclosing another account's data, so nobody is asked to set a bar from nothing.
Walk the calibration evidence with the customer. Decide the level explicitly, per situation type, never granted globally.
A signed delegation record with the evidence attached.
The delegation level itself — owned by the customer, granted rather than assumed, and revocable on the same evidence basis if calibration degrades.
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, delegation ceiling. 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 promotion gate moves the taught type up the delegation ladder on measured calibration — never on elapsed time, 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.
The objection this has to survive in the roomYou are just a services company with a good story. It is the right question and it deserves a direct answer rather than a deflection.
The answer is the return path above. A services firm bills the engagement and starts the next one from zero. Here the engagement produces a portable artefact — a taught decomposition that opens the next account’s workshop as a draft — while the customer’s own data never leaves their boundary. If a delivery model does not produce that artefact, it is a services engagement wearing a product’s language, and it should be priced accordingly.
One rule that does not relax under deadline pressure. A situation type’s strategies are opened as a draft from the library where one exists, and are always validated, corrected or displaced by the practitioners who hold the judgement — never accepted from the client as if the delivery team had nothing to bring, and never imposed as if the draft were final.