The Enterprise Transformation Firm

Translate the fictional client brief into an engagement scope with sponsor questions, operating risks, and explicit exclusions. Treat process timings as synthetic case facts rather than a baseline measured at a real enterprise.

Inputs: starter/docs/client-brief.md, starter/docs/process-facts.md

Outputs: deliverables/engagement-scope.md

Depends on: No prerequisites

• The scope stops before invoicing, payment, ERP writes, and credit authorization.
• Sponsor decisions and unvalidated value assumptions are separate.
• All client facts remain marked SYNTHETIC.

Reconcile keys and field meanings across accounts, headers, lines, and policy. Create a fact register distinguishing intentional bad-data fixtures, policy exceptions, and unknown real-world requirements.

Inputs: deliverables/engagement-scope.md, starter/docs/process-facts.md, starter/data/accounts.csv, starter/data/quotes.csv, starter/data/quote-lines.csv, starter/data/policy.json

Outputs: deliverables/source-facts.csv

Depends on: engagement-boundary

• All eight quotes and four accounts are covered without invented repairs.
• Missing PO and unknown tax on q-105 and negative quantity on q-107 are recorded.
• No synthetic policy is represented as tax or accounting advice.

Map the supplied requirements to source fields, process facts, and the eight acceptance cases. Mark any new requirement as proposed and name the role that must resolve it.

Inputs: deliverables/source-facts.csv, starter/docs/requirements.csv, starter/docs/acceptance-cases.md, starter/docs/handoff-contracts.md

Outputs: deliverables/requirements-trace.csv

Depends on: source-reconciliation

• Every supplied requirement has at least one acceptance case.
• Data readiness and policy review are separate requirements.
• Unresolved policy questions are not silently converted into defaults.

Describe the pure input/output contract, validation limits, rounding points, and state precedence around the authored utility. Keep enterprise adapters, identity, persistence, and approval outside the reference.

Inputs: deliverables/requirements-trace.csv, starter/data/policy.json, starter/reference/quote_flow.py, starter/docs/handoff-contracts.md

Outputs: deliverables/calculation-contract.md

Depends on: requirements-trace

• The contract specifies cent precision and ROUND_HALF_UP per line and shipping tax.
• needs-data outranks needs-review and no state means invoice-sent.
• Unknown accounts and malformed numeric values are rejected without network side effects.

Run only the authored utility and tests on the supplied data. Capture the full result and command metadata as a proposed engineering handoff, without altering source fixtures.

Inputs: deliverables/calculation-contract.md, starter/reference/quote_flow.py, starter/reference/test_quote_flow.py, starter/data/accounts.csv, starter/data/quotes.csv, starter/data/quote-lines.csv, starter/data/policy.json, starter/reference/expected-results.json

Outputs: deliverables/prototype-run.json

Depends on: calculation-boundary

• Exactly eight results are captured in quote-ID order.
• The authored tests pass and source inputs remain unchanged.
• The run records three readiness categories and never claims a real invoice.

Compare the reproduced batch to the expected-results reference and requirements trace. Record each case's expected amount, actual amount, state, and review or data reason.

Inputs: deliverables/prototype-run.json, deliverables/requirements-trace.csv, starter/reference/expected-results.json, starter/docs/acceptance-cases.md, starter/reference/test_quote_flow.py

Outputs: deliverables/acceptance-matrix.csv

Depends on: prototype-reproduction

• q-101 totals USD 268.21 and q-106 totals USD 10.16.
• q-102, q-103, q-104, and q-108 remain review-gated.
• q-105 and q-107 have null totals and needs-data, not zero-dollar approval.

Turn the observed reason codes into a proposed routing table with role, minimum evidence, proposed response window, and re-evaluation trigger. Do not auto-approve any exception.

Inputs: deliverables/acceptance-matrix.csv, starter/docs/handoff-contracts.md, starter/docs/process-facts.md

Outputs: deliverables/exception-routing.md

Depends on: acceptance-review

• Each observed reason code has a proposed owner and return path.
• Commercial policy and missing-data routes remain separate.
• All response times are targets to validate, not measured service levels.

Create a correction-proposal ledger for q-105 and q-107. Record original values, why they block evaluation, what evidence is needed, and who may supply a replacement. Use proposed synthetic alternatives only as clearly labeled what-if examples.

Inputs: deliverables/exception-routing.md, deliverables/acceptance-matrix.csv, starter/data/quotes.csv, starter/data/quote-lines.csv

Outputs: deliverables/correction-proposals.csv

Depends on: exception-routing

• Original fixtures are preserved and all three data defects are addressed.
• Missing PO, tax code, and quantity are not guessed into approved source data.
• A reviewer can distinguish a hypothetical correction from an authorized one.

Build a 35-minute practice plan using the sample quotes and the exception routing. Include seller, credit reviewer, and billing coordinator exercises and a no-send rehearsal.

Inputs: deliverables/exception-routing.md, deliverables/acceptance-matrix.csv, starter/docs/adoption-playbook.md, starter/docs/acceptance-cases.md

Outputs: deliverables/adoption-session.md

Depends on: exception-routing

• The agenda totals 35 minutes.
• Learners must explain why clean is not authorized and missing data is not a zero total.
• Attendance, competence, and adoption are not claimed before the session occurs.

Propose measurable pilot outcomes and a baseline collection design using the acceptance findings. Distinguish calculation correctness from cycle time, financial impact, and user adoption, which are not measured by this seed.

Inputs: deliverables/acceptance-matrix.csv, deliverables/correction-proposals.csv, deliverables/engagement-scope.md, starter/docs/client-brief.md

Outputs: deliverables/pilot-value-case.md

Depends on: correction-proposals

• The case defines denominators for rework rate and quote-readiness lead time.
• No savings, revenue, deployment, or customer validation is invented.
• The pilot proposal includes stop conditions and separate enterprise access approval.

Evaluate the acceptance matrix, unresolved data proposals, adoption plan, and measurement case. Record pass, fail, or not-observed for each gate; lack of real policy confirmation must remain visible.

Inputs: deliverables/acceptance-matrix.csv, deliverables/correction-proposals.csv, deliverables/adoption-session.md, deliverables/pilot-value-case.md, starter/docs/requirements.csv

Outputs: deliverables/pilot-gate.json

Depends on: adoption-workshop, pilot-value-case

• Every requirement has a gate disposition and linked evidence.
• The gate cannot authorize production connectivity, spending, or invoice issuance.
• Unobserved adoption and real-policy validation are explicitly not passed.

Compile operator instructions, escalation paths, practice materials, and outstanding owner approvals. Include a rollback step that is simply ceasing the offline exercise; no production migration exists.

Inputs: deliverables/pilot-gate.json, deliverables/exception-routing.md, deliverables/adoption-session.md, deliverables/engagement-scope.md, starter/docs/adoption-playbook.md

Outputs: deliverables/pilot-owner-pack.md

Depends on: pilot-quality-gate

• The owner pack identifies all three readiness categories and their meaning.
• The handoff can be followed using only the package's offline artifacts.
• It states what has not been deployed, approved, measured, or sent.