Mapping to 3SF¶

This page explains how the CDS Commitment Envelope maps into 3SF as a delivery runtime.

CDS produces a commitment object. 3SF runs that commitment through execution while maintaining coherence across the triangle (Client–Vendor–Product) and across the three lines (Engagement–Delivery–Value). The mapping below is designed to make that handoff explicit and repeatable.

Why the mapping matters¶

Most delivery breakdowns happen when a commitment is formally “agreed” but is not runtime-ready:

roles and decision rights are unclear
value evidence is undefined
constraints are discovered late
dependencies are implicit
change becomes escalation-by-default

3SF can detect and manage drift during execution — but only if the commitment envelope provides the necessary “input contract.”

Mapping overview¶

The mapping is done in two passes:

Pass 1 — Triangle coherence: Client ↔ Vendor ↔ Product
Pass 2 — Line coherence: Engagement ↔ Delivery ↔ Value

You can treat this as a checklist during Commitment Formalization.

Pass 1: Client–Vendor–Product coherence¶

Client (why / authority / acceptance)¶

Commitment Envelope fields that must map clearly:

Sponsor / accountable buyer
Decision rights and escalation path
Acceptance owner (who decides “this is acceptable”)
Value evidence expectations (what counts as proof)
Constraints owned by client (policy, compliance, access, internal approvals)

3SF runtime implication: If these are missing, delivery will drift into “busy work,” or stall waiting for decisions and approvals.

Vendor (capability / responsibility / execution integrity)¶

Commitment Envelope fields that must map clearly:

Accountable delivery owner
Delivery responsibilities (what the vendor owns vs supports)
Risk posture (what risks vendor will actively manage)
Change handling (how vendor proposes changes and what happens next)
Dependency obligations (what vendor needs from client and by when)

3SF runtime implication:
If these are missing, vendor execution becomes reactive, and accountability diffuses.

Product (scope boundary / constraints / operability)¶

Commitment Envelope fields that must map clearly:

Commitment statement boundary (in/out/unknown)
Quality bar (including operational constraints)
Non-negotiables (security, privacy, performance, uptime, data)
Revisit triggers (what invalidates the commitment)
Evidence instrumentation expectations (how product value is observed)

3SF runtime implication:
If these are missing, “done” becomes subjective and value becomes unprovable.

Pass 2: Engagement–Delivery–Value coherence¶

Engagement line (Client ↔ Vendor)¶

This is the working relationship contract.

Map from Commitment Envelope:

Governance cadence (how often, who attends, what is reviewed)
Decision forum (where decisions are made and recorded)
Communication norms (channels, response expectations where needed)
Escalation rules (what escalates, how, and to whom)
Change protocol (normal vs urgent changes)

3SF runtime implication: This prevents “relationship drift” where delivery is blocked by absent leadership or unclear collaboration mechanics.

Delivery line (Vendor ↔ Product)¶

This is the execution integrity contract.

Map from Commitment Envelope:

Definition of done / quality bar
Constraints enforcement (who validates security, compliance, performance)
Dependency access (environments, data, credentials, approvals)
Risk posture (rollback, mitigation, cutover stance where relevant)
Decision rights for technical tradeoffs (who can accept debt, performance tradeoffs, scope cuts)

3SF runtime implication: This prevents “delivery drift” where teams build the wrong thing, build it unsafely, or are blocked by invisible dependencies.

Value line (Product ↔ Client)¶

This is the value validation contract.

Map from Commitment Envelope:

Evidence & acceptance (what counts as value, who verifies, how often)
Success signals (leading/lagging indicators)
Adoption expectations (if relevant: training, rollout, comms ownership)
Post-release responsibilities (who owns operations, support, incident response)
Revisit triggers tied to value (signals that force re-evaluation)

3SF runtime implication:
This prevents “value drift” where deliverables ship but outcomes remain unclear or unmeasured.

Practical mapping table¶

Use this as a compact handoff guide.

CDS Commitment Envelope element	3SF coherence target
Parties, roles, decision rights	Client ↔ Vendor alignment (Engagement)
Commitment statement (outcome + boundary)	Product scope coherence (Product)
Deliverables	Delivery coherence (Vendor ↔ Product)
Evidence & acceptance	Value coherence (Product ↔ Client)
Constraints & non-negotiables	Delivery + Product integrity
Tradeoffs accepted	All three lines (prevents conflict later)
Governance cadence	Engagement runtime stability
Change protocol	Engagement + Delivery drift control
Risk posture & escalation	Delivery safety + recoverability
Revisit triggers & expiry	Runtime re-entry conditions

Mapping quality checks (profile gates)¶

Before handing the Commitment Envelope into 3SF, confirm:

Every triangle vertex has an accountable owner (Client/Vendor/Product).
Every line has a defined operating contract (Engagement/Delivery/Value).
Acceptance is defined as evidence, not “we shipped it.”
Dependencies are visible and owned (especially client-side access/approvals).
Change protocol exists and is routable without escalation-by-default.

Common mapping failures¶

Engagement undefined: delivery starts without decision forums and escalation rules.
Delivery undefined: constraints and dependencies are discovered late.
Value undefined: acceptance is subjective and metrics are absent.
Triangle imbalance: one vertex dominates (e.g., vendor blamed for client decision vacuum).
Tradeoffs denied: later conflict appears as “quality vs speed” arguments.

What comes next¶

The next profile pages extend the CDS lifecycle artifacts so the mapping becomes natural:

Meaning Discovery (Software Delivery additions)
Intent Refinement (Software Delivery additions)
Commitment Formalization (Software Delivery additions)