The Delivery Framework
From a request to a provable outcome.
Four jobs move delivery forward. Shared memory and coordination keep the work connected.
Work can loop back as new information arrives. Memory and coordination support the whole path.
One request, followed through
“Review large discounts before we approve them.”
Follow a sales manager’s request through a Salesforce change. Select a job to see what it contributes and the record it leaves behind.
Illustrative scenario. The threshold and records below are teaching examples, not customer results.
The delivery path / Signal
Capture the request
Record the request, origin, intended outcome, and open questions.
Example artifact
Request record
- Source
- Sales manager · discount review request
- Intent
- Require review before a large discount is approved.
- Open questions
- What counts as large? Who can approve an exception?
What this makes possibleStructured intent with a traceable source.
Why Signal matters
Delivery begins the moment someone says what they want — in a meeting, a Slack thread, an email, a hallway. Signal captures every one of those inputs as structured intent instead of letting it evaporate. Nothing downstream can be traceable if the origin was never recorded. This is where the audit trail starts.
The delivery path / Blueprint
Plan against the current system
Inspect current rules, stakeholders, dependencies, and agreed review criteria.
Example artifact
Acceptance criteria
- Illustrative agreement
- Discounts above 20% require sales director approval.
- Expected behavior
- Hold the request until the director records a decision.
- Boundary checks
- Verify discounts below, at, and above the threshold.
What this makes possibleA grounded plan with explicit assumptions and acceptance criteria.
Why Blueprint matters
A plan that ignores the current state of the system is fiction. Blueprint turns captured intent into a plan grounded in what actually exists — the data model, the integrations, the team's real capacity, the decisions already made. It's the difference between a wish and a workable path to shipping.
The delivery path / Run
Execute with traceability
Implement and validate changes while linking work back to the request.
Example artifact
Linked change record
- Change
- Update the Salesforce approval rule for the agreed threshold.
- Validation
- Check routing, pending approval, rejection, and exceptions.
- Traceability
- Attach each check to the acceptance criterion and original request.
What this makes possibleChanges and checks tied to the original intent.
Why Run matters
Execution is where most delivery loses the thread — work happens, but the link back to why gets severed. Run carries the plan into execution while keeping every change tied to the intent that motivated it. When someone asks "why does this exist?" months later, the answer is one hop away, not an archaeology project.
The delivery path / Receipt
Prove the outcome
Link the released behavior, checks, decisions, and request.
Example artifact
Release evidence
- Requested
- Review large discounts before approval.
- Delivered in this example
- The agreed approval rule and director review route.
- Evidence to retain
- Validation results, release reference, approval, and original request.
What this makes possibleA traceable record of what shipped and why.
Why Receipt matters
"Done" is a claim; Receipt is the proof. It closes the loop by tying the shipped outcome all the way back to the original signal — what was asked, what was decided, what was built, and what actually went live. The result is software that isn't just delivered but provable: auditable, traceable, and defensible.
Across the delivery path / Nexus
Preserve the decision
Record the rationale and relevant context for future teams.
Example artifact
Decision record
- Decision
- Use a strict “above 20%” threshold for this example.
- Rationale
- Keep the agreed boundary explicit so future changes preserve its intent.
- Revisit when
- The discount policy or approval ownership changes.
What this makes possibleA durable decision record that can be found and reused.
Why Nexus matters
Every project is a chain of decisions, and most of them are made once and forgotten. Nexus is the memory: it holds the decisions, the tradeoffs, and the context behind them so the organization stops re-litigating settled questions. This is where context becomes durable knowledge that compounds across projects.
Across the delivery path / Relay
Resolve the conflict
Surface conflicting assumptions and agree the dependency before release.
Example artifact
Dependency agreement
- Conflict
- Another team is changing the same approval workflow.
- Coordination
- Agree one owner for the shared rule and sequence both changes.
- Release condition
- Validate the combined workflow before either change ships.
What this makes possibleA shared decision and coordinated delivery plan.
Why Relay matters
Work rarely fails inside one team — it fails in the gaps between them, where two efforts quietly assume opposite things. Relay watches the flow across teams and surfaces conflicts before they become production incidents: the collision, the duplicated effort, the dependency nobody flagged. It turns cross-team coordination from a hope into a signal.
Put the framework in context