CASE STUDY · DESIGN CANDIDATE

The method applied to itself.

This page treats the Tinework consulting engagement as the workflow under study. It presents the same connected views that a client engagement would produce.

StatusDesign candidate

SubjectThe Tinework consulting engagement

Revision0.1 · 20 August 2026

This is not a claim of client results. It is a provisional design. Baselines and results remain unvalidated until real engagements produce evidence.

MAP

ONE MODEL · MANY VIEWS

Every view describes the same engagement.

The views are not separate deliverables with separate facts. Their identifiers connect one underlying model from intent through evidence, authorization, action, and outcome.

01Engagement job and outcomes

What the work must accomplish and how improvement would be judged.

ENGAGEMENT JOB & OUTCOMES

Start with what the engagement must accomplish.

The client job and the consulting job are related, but they are not the same. The desired outcomes below are candidate measures, not established performance claims.

Client job: Improve a recurring operational workflow without disrupting the work it must continue to support.
Tinework job: Help the client understand, redesign, test, and adopt that workflow.
Job executor: The business operator responsible for the recurring work
Business sponsor: The client leader accountable for the business outcome

ID	Candidate desired outcome	Measure	Baseline	Evidence method
O1	Reduce the time required to establish a trustworthy current-state map.	Elapsed time from intake to operator-confirmed map	Not established	Timestamps and operator confirmation from real engagements
O2	Reduce ambiguity about the job, outcomes, constraints, and authority.	Open material questions at the design gate	Not established	Decision log and unresolved-question count
O3	Reduce the time needed to allocate work to people, software, or AI.	Elapsed time from current-state confirmation to allocation proposal	Not established	Candidate revision history and review timestamps
O4	Increase the likelihood that a pilot demonstrates measurable value before wider deployment.	Pilots with an agreed prediction, baseline, and decision rule	Not established	Pilot plans and completed outcome observations
O5	Reduce the risk that automation moves hidden burden into exceptions and monitoring.	Exception rate, review load, and recovery time	Not established	Exception logs, observation, and operator interviews
O6	Increase the share of freed capacity reassigned to named higher-value work.	Freed hours with an agreed reallocation destination	Not established	Before-and-after capacity plan and follow-up observation

02Job map
The solution-independent stages required to complete the consulting job.
JOB MAP
The engagement, independent of the current process.
This Ulwick-informed job map describes what must happen to complete the consulting job. It is not a diagram of how Tinework happens to perform the work today.
PROCESS MAP · J1–J8From definition to an authorized conclusion.
1. J1DefineSigned scope and job statement
2. J2LocateEvidence inventory
3. J3PrepareObservation and data-use plan
4. J4ConfirmConfirmed engagement brief
5. J5ExecuteConfirmed map and design candidate
6. J6MonitorRisk, exception, and test records
7. J7ModifyRevision history
8. J8ConcludeAuthorized decision and outcome record
1. J1
  DEFINE
  Select the workflow, job executor, job, and objectives.
  Signed scope and job statement
2. J2
  LOCATE
  Gather cases, artifacts, systems, policies, and participants.
  Evidence inventory
3. J3
  PREPARE
  Set permissions, observation methods, consent, and the baseline plan.
  Observation and data-use plan
4. J4
  CONFIRM
  Verify scope, authority, measures, constraints, and exclusions.
  Confirmed engagement brief
5. J5
  EXECUTE
  Observe the work, model its current state, and design a candidate future state.
  Confirmed map and design candidate
6. J6
  MONITOR
  Inspect ambiguity, exceptions, controls, and pilot evidence.
  Risk, exception, and test records
7. J7
  MODIFY
  Revise the map, allocation, candidate, and tests as evidence changes.
  Revision history
8. J8
  CONCLUDE
  Decide whether to adopt, adjust, or stop, then record the learning.
  Authorized decision and outcome record

03Current and proposed workflow

The working baseline and candidate redesign.

CURRENT & PROPOSED WORKFLOW

Redesign the engagement before automating it.

The current-state column is a working assumption based on the emerging practice. It must be replaced by observation. The proposed column is the candidate to test.

Working assumption Current practice to observe and correct

Design candidate Proposed practice to test

Stage	Current working assumption	Proposed workflow
W1Qualify	Conversation and email establish whether there may be a useful engagement.	Structured intake captures the job, desired outcome, workflow owner, urgency, and authority.
W2Discover	Founder-led interviews and notes reconstruct how the work happens.	A guided interview and observed run collect cases, decisions, handoffs, exceptions, systems, and controls.
W3Model	Bespoke notes and diagrams describe the current workflow.	One evidence-bound model generates the job map, workflow, service blueprint, state view, and control view.
W4Redesign	Recommendations depend on consultant synthesis.	Remove needless work, then allocate each task to a person, deterministic software, or AI with a reason.
W5Pilot	A custom proof of concept tests the proposed solution.	A bounded PDSA cycle tests an explicit prediction against a baseline and the four product risks.
W6Evaluate and adopt	Manual follow-up determines whether the work continues.	Compare results with the prediction, decide adopt, adjust, or stop, and assign freed capacity deliberately.

04Service blueprint
Who acts, what evidence moves, and where authority sits.
SERVICE BLUEPRINT
Make responsibility, evidence, and control visible.
This view adds the operating lanes around the workflow. It shows who owns the work, what evidence supports it, and which boundary prevents an unauthorized transition.
DATA ARCHITECTUREOne model produces every client-facing view.
Evidence enters once. Stable identifiers connect it to derived views, gates, tests, and outcomes.
01EVIDENCE SOURCES
Intake
Interview
Observed run
Artifacts
02CANONICAL ENGAGEMENT MODEL
Job + actor
Outcome
Workflow node
Evidence
Control + decision
Pilot + result
03MATERIALIZED VIEWS
Job map
Workflow
Blueprint
State model
Traceability
04AUTHORIZED ACTION
Pilot
Adopt
Adjust
Stop
W1
Qualify
Responsible lane
Sponsor + Tinework
Evidence lane
Intake record
Control lane
No observation or recording without scope and consent
W2
Discover
Responsible lane
Job executor + Tinework
Evidence lane
Interview, recording, artifacts, and observation notes
Control lane
The operator can correct the record and restrict sensitive evidence
W3
Model
Responsible lane
Tinework proposes; job executor confirms
Evidence lane
Traceable nodes linked to source evidence
Control lane
Unconfirmed inferences remain visibly provisional
W4
Redesign
Responsible lane
Client team + Tinework
Evidence lane
Allocation rationale and discovery tests
Control lane
Human judgment, escalation, and recovery paths remain explicit
W5
Pilot
Responsible lane
Client authority authorizes; delivery team runs
Evidence lane
Pilot plan, observations, and exception log
Control lane
Pilot authorization does not authorize production deployment
W6
Evaluate and adopt
Responsible lane
Client authority
Evidence lane
Outcome observation, decision, and capacity plan
Control lane
Tinework may recommend; the client owns the adoption decision
05State and gate model
The permitted progression from intake to an adoption decision.
STATE & GATE MODEL
Progress requires evidence and authority.
The engagement progresses as a state machine. A completed activity does not itself authorize the next state. Each transition has an explicit gate.
UML · STATE MACHINEEvidence and authority govern each transition.
«state» · S1SubmittedThe request identifies a workflow and accountable person.
«state» · S2QualifiedThe job and business reason are plausible and in scope.
«state» · S3Observation readyAuthority, access, consent, and evidence boundaries are explicit.
«state» · S4Current state mappedThe job executor confirms the material steps, decisions, and exceptions.
«state» · S5Candidate designedThe allocation and four product risks have testable evidence plans.
«state» · S6Pilot authorizedThe client accepts scope, prediction, measures, controls, and stop conditions.
«state» · S7Pilot activeOnly the bounded pilot may run; exceptions and interventions are recorded.
«state» · S8Evidence readyResults can be compared with the baseline and prediction.
«state» · S9Adopt · adjust · stopThe client records a separate, authorized decision.
1. 01
  Submitted
  Gate: The request identifies a workflow and accountable person.
2. 02
  Qualified
  Gate: The job and business reason are plausible and in scope.
3. 03
  Observation ready
  Gate: Authority, access, consent, and evidence boundaries are explicit.
4. 04
  Current state mapped
  Gate: The job executor confirms the material steps, decisions, and exceptions.
5. 05
  Candidate designed
  Gate: The allocation and four product risks have testable evidence plans.
6. 06
  Pilot authorized
  Gate: The client accepts scope, prediction, measures, controls, and stop conditions.
7. 07
  Pilot active
  Gate: Only the bounded pilot may run; exceptions and interventions are recorded.
8. 08
  Evidence ready
  Gate: Results can be compared with the baseline and prediction.
9. 09
  Adopt · adjust · stop
  Gate: The client records a separate, authorized decision.

06Decisions and controls

Who can decide what, and what evidence each decision needs.

DECISIONS & CONTROLS

Advice, approval, and authorization stay distinct.

Tinework can assemble evidence and propose a decision. The client retains authority over its data, operating model, pilot, and deployment.

Decision	Authority	Required evidence
Engagement scope	Client sponsor	Job, business outcome, exclusions, and named participants
Recording and data use	Data owner + job executor	Consent, retention, access, and permitted use
Current-state accuracy	Job executor	Observed cases and explicit corrections
Desired outcomes	Sponsor + job executor	Outcome statements, baseline plan, and trade-offs
Future-state acceptance	Client authority	Allocation rationale, exception paths, and controls
Pilot authorization	Client authority	Prediction, bounds, success measures, and stop conditions
Production deployment	Separate client authority	Pilot outcome, residual risks, operating owner, and rollback plan
Outcome interpretation	Sponsor + executor + Tinework	Observed result, variation, operator experience, and limitations

07Product discovery risks
The value, usability, feasibility, and viability questions.
PRODUCT DISCOVERY RISKS
A plausible solution is not yet a viable one.
The SVPG four-risk model turns the future workflow into questions that can be tested before engineering effort or organizational commitment grows.
01
VALUE
Will the redesign solve an important workflow problem?
Evidence: Ranked outcomes, representative cases, and sponsor commitment
02
USABILITY
Can operators understand, supervise, and recover from it?
Evidence: Task walkthroughs, exception drills, and operator feedback
03
FEASIBILITY
Can it work with the available systems, data, skills, and reliability?
Evidence: Technical spike, data sample, integration test, and failure analysis
04
VIABILITY
Does it fit policy, economics, risk, and the operating model?
Evidence: Control review, cost model, ownership plan, and stakeholder decision
08PDSA pilot
How the candidate becomes a bounded learning cycle.
PDSA PILOT
Use the pilot to learn, not to confirm a pitch.
A bounded pilot begins with a prediction and ends with a decision. Completion does not imply success, and success does not imply permission to scale.
1. 01
  Plan
  State the prediction, baseline, target, scope, risks, controls, and decision rule.
2. 02
  Do
  Run the smallest bounded pilot and record interventions, exceptions, and deviations.
3. 03
  Study
  Compare observations with the prediction. Examine variation, failure demand, and operator experience.
4. 04
  Act
  Adopt, adjust, or stop. Do not treat pilot completion as automatic permission to scale.

09Traceability

How needs connect to outcomes, workflow nodes, controls, tests, and results.

TRACEABILITY

Follow each claim from need to observed result.

This is the connective tissue. It prevents a desired outcome, design feature, control, or result from becoming detached from the reason it exists.

CONNECTED MODEL · TRACEABILITYNeed → model → pilot → decision

One continuous path from the reason for the work to an observed and authorized result.

01INTENT

Shorten research
Reduce rework
Preserve judgment
Convert time to value

02OUTCOMES

Desired outcomes

O1–O6

03WORKFLOW

Evidence-bound nodes

W1–W6

04CONTROL

Authority + gates

Explicit decision rights

05PILOT

Bounded PDSA

Prediction + measures

06RESULT

Observed evidence

Compared with baseline

07DECISION

Adopt · adjust · stop

Client-authorized action

View Mermaid definition

flowchart LR
  subgraph intent[Intent]
    N1["Shorten research"]
    N2["Reduce rework"]
    N3["Preserve judgment"]
    N4["Convert time to value"]
  end
  subgraph model[Evidence-bound model]
    O["Desired outcomes · O1–O6"]
    W["Workflow nodes · W1–W6"]
    C["Controls and authority"]
  end
  subgraph test[Pilot and decision]
    P["Bounded PDSA pilot"]
    R["Observed result"]
    D{"Adopt · adjust · stop"}
  end
  N1 --> O
  N2 --> O
  N3 --> W
  N4 --> O
  O --> W
  W --> C
  C --> P
  P --> R
  R --> D
  classDef evidence fill:#fafafa,stroke:#a5a5ad,color:#41414b,stroke-width:1px;
  classDef decision fill:#f1f1f3,stroke:#686872,color:#2f2f36,stroke-width:1px;
  class N1,N2,N3,N4,O,W,C,P,R evidence;
  class D decision;

Need	Outcomes	Workflow nodes	Control	Pilot test	Result
Shorten research and synthesis	O1 · O3	W2 · W3 · W4	Operator confirmation	Compare elapsed time and correction load	Evidence gap
Reduce rework and error	O2 · O4	W1 · W3 · W5	Explicit gates and revision history	Compare unresolved questions and rework events	Evidence gap
Preserve judgment in exceptions	O5	W2 · W4 · W5	Human review, escalation, and recovery path	Exception drills and review-load observation	Evidence gap
Convert time saved into value	O6	W4 · W6	Named capacity owner and destination	Before-and-after time allocation	Evidence gap

10Measures and capacity
How operating change and the use of saved time are evaluated.
MEASURES & CAPACITY
Measure the work—and what replaces it.
Time saved is not an outcome by itself. The engagement must observe operating performance and name the higher-value work that receives the released capacity.
- 01Elapsed cycle timeBaseline not established
- 02Human touch timeBaseline not established
- 03Error and rework rateBaseline not established
- 04Exception rateBaseline not established
- 05Human review loadBaseline not established
- 06Recovery timeBaseline not established
- 07Adoption and sustained useBaseline not established
- 08Outcome qualityBaseline not established
- 09Freed capacityBaseline not established
- 10Capacity reallocated to named higher-value workBaseline not established
1Measure removed effort
Verify that touch time fell without hidden rework.
2Name the destination
Assign the capacity to a specific higher-value job.
3Observe the result
Check that the new allocation occurred and produced value.
11Evidence gaps
What must be learned before this can be called a validated case study.
OPEN EVIDENCE GAPS
What this example does not yet prove.
Making the gaps public is part of the method. These are the first questions that real engagement evidence must answer.
- G1
  No observed baseline yet exists for a representative Tinework client engagement.
- G2
  No representative workflow recording has been coded against this model.
- G3
  The structured intake completion rate and correction burden are unknown.
- G4
  No pilot has yet compared the proposed engagement workflow with the current approach.
- G5
  No outcome record yet shows that saved capacity was reassigned and sustained.
- G6
  No external client has reviewed and challenged the complete worked example.

A MAP TO CHALLENGE

This model should change when the evidence does.

A client engagement would replace assumptions with observed evidence, retain each revision, and keep the decision trail visible.

Bring us a workflow Return to the method and sources

The method applied to itself.

Every view describes the same engagement.

Start with what the engagement must accomplish.

The engagement, independent of the current process.

Select the workflow, job executor, job, and objectives.

Gather cases, artifacts, systems, policies, and participants.

Set permissions, observation methods, consent, and the baseline plan.

Verify scope, authority, measures, constraints, and exclusions.

Observe the work, model its current state, and design a candidate future state.

Inspect ambiguity, exceptions, controls, and pilot evidence.

Revise the map, allocation, candidate, and tests as evidence changes.

Decide whether to adopt, adjust, or stop, then record the learning.

Redesign the engagement before automating it.

Make responsibility, evidence, and control visible.

Progress requires evidence and authority.

Submitted

Qualified

Observation ready

Current state mapped

Candidate designed

Pilot authorized

Pilot active

Evidence ready

Adopt · adjust · stop

Advice, approval, and authorization stay distinct.

A plausible solution is not yet a viable one.

Will the redesign solve an important workflow problem?

Can operators understand, supervise, and recover from it?

Can it work with the available systems, data, skills, and reliability?

Does it fit policy, economics, risk, and the operating model?

Use the pilot to learn, not to confirm a pitch.

Plan

Do

Study

Act

Follow each claim from need to observed result.

Desired outcomes

Evidence-bound nodes

Authority + gates

Bounded PDSA

Observed evidence

Adopt · adjust · stop

Measure the work—and what replaces it.

What this example does not yet prove.

This model should change when the evidence does.