Skip to content
Brandon Olander
← The 60-second case study

Technical case study · Revenue Orchestration Lab

Keeping readiness and permission to act apart

High readiness is not permission to sell. When a governance constraint applies — a critical support escalation, a consent restriction or a late-stage deal with an existing owner — the engine withholds outbound action while the account stays opportunity-ready and the evidence is kept.

In the lab, S04 is held back by a critical support escalation, S10 by a consent opt-out, and S05 by an existing owner’s late-stage deal, where the evidence goes to that owner instead.

A working, tested decision engine that runs 12 synthetic B2B scenarios from first signal to a governed action and a named owner. This page shows how it is built, which guarantees it holds, and the evidence that each one is enforced rather than described.

Fictional company, synthetic data · No model calls · AI-assisted implementation · Evidence classes

Three decisions from the engineModeled output · class 4All three reach the same readiness: Opportunity-creation ready

  1. S03Expansion-ready customer

    Permission
    Allowed · owner Sales
    Because
    No hard block, competing owner or raised approval bar

  2. S04High readiness, support veto

    Permission
    Blocked · owner Customer Success
    Because
    Critical support escalation and CSM commercial hold

  3. S05Late-stage opportunity precedence

    Permission
    Coordinate through owner · owner Sales
    Because
    Late-stage opportunity owned by Priya Raman

Final step of each scenario. Each has its own events; they share a readiness level, not their inputs. Full readouts

Worked contrast

One readiness level, three different decisions

Modeled output · class 4

Each readout is the final step of a scenario, produced by calling the engine when this page is built. The company, the people and the events are fictional. In all three, the account reaches the same readiness. What changes is permission to act.

S03

Expansion-ready customer

Readiness
Opportunity-creation ready
Permission to act
Allowed
No hard block, no competing owner, and no warning that raises the bar.
Action and owner
Open a Control expansion conversation with Sofia Marchetti, referencing the validated deployment.
Owner: Sales

S04

High readiness, support veto

Readiness
Opportunity-creation ready
Permission to act
Blocked
Critical support escalation and CSM commercial hold forbid this class of action. Readiness is unaffected and the evidence is retained.
Action and owner
Hand the Control evidence to Customer Success as internal expansion context. Nothing leaves the building until the block clears.
Owner: Customer Success
Suppressed
Outbound commercial

S05

Late-stage opportunity precedence

Readiness
Opportunity-creation ready
Permission to act
Coordinate through owner
Priya Raman owns an active late-stage Control opportunity. Independent activation would cut across a live negotiation; the evidence still belongs in front of the owner.
Action and owner
Surface the new Control evidence to Priya Raman inside the existing opportunity. No independent sequence, no separate outreach.
Owner: Sales
Suppressed
Outbound commercial

The lab runs 12 scenarios in all. Step through any of them in the interactive lab.

Executive technical summary

A rules engine whose decisions can be traced and broken on purpose

Portfolio-built demonstration · class 3
What it is
A deterministic decision engine written as plain TypeScript functions, with no framework dependency. Each scenario's fixed events are replayed from the initial state at every step, so the same scenario at the same step always produces the same result. React only renders what the engine returns.
The guarantee that matters
Commercial readiness and permission to act are separate types produced by separate functions. Readiness can shape what the engine wants to do. Only governance decides whether it may. In the S03 and S04 readouts below, the same readiness level produces opposite permissions.
How the guarantees are held
Each load-bearing rule has guard tests, and a recorded mutation exercise broke each rule on purpose to show those tests fail. At candidate ada1d43, all 7 recorded mutations were caught.
What it is not
There is no model call, no CRM or product integration, no persistence and no real data. Thresholds were chosen for legibility, not calibrated. The page makes no business-outcome claim.

What this page is

  • Portfolio-built demonstration · class 3The engine, its tests and the recorded verification.
  • Modeled output · class 4Scenario readouts, computed from the engine when this page is built.
  • Inference · class 5The design argument and one proposed extension that is not built.

VantageGrid, its two products, every account, every person and every event in this lab are invented. Nothing here is a real customer, a real outcome or a real performance claim. No model is called anywhere in the lab. The implementation was AI-assisted.

The design problem

One score cannot carry every question

Inference · class 5

When product usage, marketing engagement, buying-group evidence, opportunity status and customer health share a single score or lifecycle field, each one starts to change the meaning of the others. Readiness to buy and permission to contact become the same number, and a block on one becomes an invisible penalty on the other.

The engine is built around the opposite rule: keep each question in its own type, compute it from its own inputs, and make the path between them inspectable. The business framing is in the 60-second case study.

Architecture

Seven stages, each owning one kind of fact

Portfolio-built demonstration · class 3

Source references name files in a private repository. They are listed so the claims can be audited by anyone with access, not as links.

  1. 01Event

    A fixed, dated fact from the scenario fixture: a login, a deployment, a ticket, an opt-out.

    scenarios · content/revenue-orchestration-lab/scenarios.ts
  2. 02World state

    Events are folded into people, accounts, product relationships, buying groups and opportunities. Each step replays from the initial world.

    replay · lib/revenue-orchestration-lab/world.ts
  3. 03Assessment

    Technical validation, commercial validation, buying-group coverage, signal confidence and readiness, scoped to one purchase motion.

    assess · lib/revenue-orchestration-lab/assess.ts
  4. 04Governance

    Hard blocks, existing-owner precedence and warnings, evaluated as three separate mechanisms.

    evaluateGovernance · lib/revenue-orchestration-lab/govern.ts
  5. 05Eligibility

    Permission to act on one class of action. The function receives the action class and the governance result, and has no readiness input.

    resolveEligibility · lib/revenue-orchestration-lab/govern.ts
  6. 06Orchestration

    The action, its owner, the participating teams, the recipients consent allows, and the action that was suppressed, if any.

    resolveAction · lib/revenue-orchestration-lab/orchestrate.ts
  7. 07View projection

    One object per step for the interface, with motion-scoped fields already selected. Components render it and decide nothing about scope.

    runScenario · lib/revenue-orchestration-lab/orchestrate.ts

Guarantees

Five rules the engine holds, and how each is checked

Portfolio-built demonstration · class 3

  1. Readiness and permission to act are different questions

    Readiness is computed from the validation assessments before governance runs. Eligibility is resolved from the intended action class and the governance result alone, so no readiness level can talk its way past a block.

    Enforced in

    assessReadiness · lib/revenue-orchestration-lab/assess.tsresolveEligibility · lib/revenue-orchestration-lab/govern.ts

    Guarded by

    • “no governance value reaches readiness”lib/revenue-orchestration-lab/engine.test.ts
    • “never moves readiness when only governance changes”lib/revenue-orchestration-lab/engine.test.ts

    Recorded mutation

    Mutation 1 downgraded readiness whenever an action was blocked, the exact collapse the design forbids. Seven tests failed.

  2. An inference never becomes a verified fact by repetition

    A role inferred from a job title stays inferred however often it recurs. Only an explicit verification event promotes it, and that verification counts only in the purchase motion where it was made.

    Enforced in

    motionRole · lib/revenue-orchestration-lab/world.ts

    Guarded by

    • “never promotes a repeated inference into a verified role”lib/revenue-orchestration-lab/engine.test.ts
    • “does not mark the Control authority seat verified”lib/revenue-orchestration-lab/motion-scope.test.ts

    Recorded mutation

    Mutation 4 wrote every inferred role as verified (four tests failed). Mutation 2 read the account-level role instead of the motion's (two tests failed).

  3. Commercial state belongs to a purchase motion, not the account

    Buying groups, opportunities and intent are selected for the product being evaluated, and an SLA assignment counts only for the product it was made for. Which opportunity is relevant is decided in the domain layer, not by whichever record a component happens to read first.

    Enforced in

    motionOpportunity · lib/revenue-orchestration-lab/world.tsintentFor · lib/revenue-orchestration-lab/world.ts

    Guarded by

    • “selects the Control opportunity for the Control motion”lib/revenue-orchestration-lab/view-projection.test.ts
    • “shows the focus motion's opportunity when another sits at index 0”components/revenue-orchestration-lab/motion-projection.test.tsx

    Recorded mutation

    Mutations 5a and 5b reverted the selection to the first opportunity on the account, once in the domain layer and once in the interface. Two tests failed for each.

  4. Three governance mechanisms stay distinct

    A hard block forbids a class of action. An existing owner's late-stage opportunity redirects activity through that owner without vetoing it. A warning raises the approval bar without erasing evidence. They are evaluated separately and resolved in that order.

    Enforced in

    evaluateHardBlocks · lib/revenue-orchestration-lab/govern.tsevaluatePrecedence · lib/revenue-orchestration-lab/govern.tsevaluateWarnings · lib/revenue-orchestration-lab/govern.ts

    Guarded by

    • “shows every eligibility value across the scenario set”lib/revenue-orchestration-lab/engine.test.ts
    • “cannot be bypassed by high readiness”lib/revenue-orchestration-lab/engine.test.ts

    Recorded mutation

    Mutation 3 made owner precedence disappear. Five tests failed, because the late-stage scenario began running an independent action at a live deal.

  5. A block never answers with a stronger action

    When governance forbids the intended action, the engine steps down a fixed ordering to the strongest action still permitted. An action outside the ordering floors at the weakest one rather than borrowing a stronger rung.

    Outbound commercial → Internal review → Owner notification → Nurture → Intelligence only

    Enforced in

    FALLBACK_ORDER · lib/revenue-orchestration-lab/orchestrate.tsblockedAlternative · lib/revenue-orchestration-lab/orchestrate.ts

    Guarded by

    • “never returns an action class stronger than the one that was blocked”lib/revenue-orchestration-lab/view-projection.test.ts

    Recorded mutation

    Mutation 6 restored the original fallback code. Three tests failed. The first draft of the key test had passed under this mutation; see the recorded gap below.

Verification

What was checked, and when

Portfolio-built demonstration · class 3

Builder’s record · candidate ada1d43 · 2026-08-28

  • All twelve scenarios driven to their final step in a real browser and compared with the contract: twelve passes. Diagnostics appeared on exactly the four scenarios that require them.
  • Interaction, keyboard and focus checks on a production build in Microsoft Edge, which is Chromium. Desktop at 1440 by 900; four scenarios re-driven at 375 by 812.
  • The full site suite then ran 964 tests in 40 files.
Recorded mutation exercise at candidate ada1d43
#Guard brokenTests failed
1Readiness and eligibility separation7
2Motion-scoped commercial state2
3Governance precedence5
4Evidence versus inference4
5aOpportunity scoping, domain layer2
5bOpportunity scoping, interface2
6Fallback guard3

The recorded gap. The first draft of the test meant to catch an upward fallback used its own copy of the action ranking. That copy put the two affected actions in the wrong order, so the test passed under mutation 6. It was rewritten to read the engine’s own ordering, and it failed under the mutation as it should. A test that cannot fail produces confidence without evidence.

Re-checked at f7119a6, the production deployment at the time · 2026-11-04

  • The engine, fixtures and lab components are byte-identical to candidate ada1d43, the code the record describes. Only the tool page’s outer wrapper has changed since.
  • The lab’s own 8 test files pass: 200 tests.
  • The browser matrix and the mutation exercise were not repeated for this re-check.
  • After this re-check, the lab’s wording was corrected and one vacuous test was repaired. The engine and its scenarios were not changed. The verification record’s corrections section lists each change and the limitations found after promotion.

What these checks do not cover

  • No coverage instrumentation is configured. A test count is not a coverage measurement.
  • The mutation exercise covered the guards named above. It is not a mutation-coverage score.
  • Browser checks ran in Chromium only, with no screen reader and no touch input.

Corrected defects

Three faults that read as correct until they were tested

Portfolio-built demonstration · class 3

  1. Fix A

    The interface was deciding scope

    The engine was already motion-scoped, but the state panel picked its own values from account-level collections. The view now carries the focus product, its opportunity and its intent, already selected, so components only render. Account-level intent is still shown, labelled as not an input to this decision.

  2. Fix B

    Collection order was treated as commercial scope

    Reading the first opportunity on an account returned another product's renewal for a Control decision, along with that deal's owner. The domain selector replaced it, and the step diff now uses the same selector so the two cannot disagree.

  3. Fix C

    A blocked action could fall back upward

    For an action class outside the fallback ordering, the lookup returned minus one and the scan then started from the strongest action. A blocked escalation could be answered with an internal review, a stronger action than the one just forbidden. The branch is now explicit, and an unordered class floors at the weakest action.

AI authority boundary

Where a model would be allowed to act, if one were wired in

Portfolio-built demonstration · class 3

The lab makes no model call. These tiers are part of the design: they state which work is deterministic today, which a model could assist with at low consequence, and which must stay with a person.

Deterministic automation

Rules, not intelligence. Running today.

  • Owner selection from explicit rules
  • SLA timers and breach detection
  • Suppression and hard-block enforcement
  • State updates replayed from recorded events

Assistive, low consequence

A model could do these. A wrong answer is cheap and visible.

  • Summarise account activity for an owner
  • Normalise a job title into a tentative role category
  • Identify which buying-group seats are empty
  • Explain why a deterministic decision was reached

Human approval required

A wrong answer here costs an account, a contract or a compliance position.

  • Personalised outbound execution
  • Material lifecycle or status override under ambiguity
  • Overriding a governance veto
  • High-consequence exception handling

Proposed extension · not built

A downstream authorization gateway

Inference · class 5

Not implemented. No code, test or verification exists for anything in this section.

The engine decides permission at the moment it evaluates a step. Nothing in the lab executes an action, so the lab neither has the following failure nor guards against it.

The hypothetical failure. In a system that did execute, an outbound sequence could be queued while the account looked like S03, with permission allowed. If a critical support escalation then arrived, as it does in S04, a sending system that trusted the earlier decision would contact the account anyway. The decision would have been right when it was made and wrong when it was used.

The proposed control. A gateway between the decision and every execution channel that re-evaluates eligibility and each recipient’s permission at the moment of sending, refuses when the decision is missing or older than the latest event, and records the refusal with the condition that caused it. Building it would need its own tests, including one that a queued action is refused after a block arrives.

Limitations

What the artifact does not do

Portfolio-built demonstration · class 3
  • No live AI. No model is called and no value in the lab was produced by one.
  • No persistence and no integration: no database, CRM, marketing automation, product telemetry or analytics vendor.
  • Twelve fixed scenarios. There is no free-form input, no way to author an account, and no persistence.
  • The legacy comparison is VantageGrid's own scoring rule, invented for this lab. It is not a claim about marketing qualification in general.
  • Momentum, confidence and coverage use small integer thresholds chosen to make the mechanics legible, not calibrated against any real dataset.
  • The clock advances only when an event fires. Trial momentum decays at the next recorded event rather than continuously, which is what makes a step reproducible; a production implementation would run it on a timer.
  • Account fit is recorded and displayed but no rule reads it. It is context here, not an input to routing.
  • Identity reconciliation is triggered by an event in the fixture. There is no matching service behind it.
  • State comes from the scenario's events exactly as written. The engine does not reject an invalid transition, such as reopening a closed-won deal, and it assumes each event arrives once and in order.
  • Owner precedence applies only to a late-stage opportunity on the product being evaluated. An earlier-stage open opportunity does not route activity through its owner.
  • One routing assignment is held at a time. A later assignment, even for another product, replaces the earlier one and its SLA timer.
  • Customer health is shown but feeds one rule: a customer on Watch with no open escalation gets a pacing warning. At-risk or critical health raises no warning on its own; on the customer-context side, only a Sev1 escalation or a CSM hold blocks outreach.
  • A verified departure removes the person's later milestones from validation. Product-usage recency is not attributed to a person, so a departed user's later activity still counts toward trial momentum.
  • Sales-led evidence is under-read relative to this lab's own contract. A verified economic buyer engaging with commercial material, with no product activity, is classed as product interest and held in nurture, although the contract reserves product interest for evidence with no meaningful validation. This is a known gap, not a recommended qualification policy.
  • An overdue assignment escalates internally even while outreach is blocked, and its explanation still says the route was correct. The escalation reaches a manager, not anyone at the account.
  • The written explanations were checked against the twelve scenarios only. Outside them some are wrong or misleading: a readiness reason can say no validation is meaningful when commercial validation is, and an eligibility reason can say there is no hard block while one is in force, or no competing owner while another seller holds an open opportunity on the same product.
  • One account at a time. There is no aggregate view across accounts.
  • One action class, data remediation, is declared in the types but no rule produces it.

Role and evidence limits

What this demonstrates, and what it does not

I defined the lifecycle architecture, business rules, authority boundaries, failure modes, and cross-functional operating model, then used AI-assisted engineering to turn that system design into a testable interactive artifact. The artifact is synthetic by design and makes no claim of live customer data, live AI, or production revenue impact.

The implementation was AI-assisted. The tests, the browser checks and the mutation exercise verify the artifact. They are not evidence that I could have written or could defend every part of the engine unaided, and this page does not make that claim.

Open the interactive lab Back to the 60-second case study

Contact

Working on a similar GTM problem?

If your team is trying to coordinate lifecycle, PLG, sales ownership, and revenue operations without creating another black-box score, get in touch.

Email meLinkedInDownload Executive Profile