Frame a Deployed Outcome

Course boundary: Optional Komal learning material. Not required by Abhyaas. NOT FOR LIVE CERTIFICATION BANK. Orchid Equipment Services, its people, records, and outcomes are fictional. All local evidence is synthetic.

This module begins before architecture. A sponsor has asked for an AI assistant that helps field technicians decide what to inspect. The request names an interface and a technology, but it does not yet name a bounded workflow outcome, an eligible population, a decision owner, a measurement contract, or an acceptable failure path. Your job is to turn that request into a deployment question that can be accepted, narrowed, or stopped by evidence.

The result is not a pitch deck. It is the first reviewable slice of a deployment dossier: an outcome statement, a workflow evidence map, an authority map, and a discovery plan. Each claim must preserve whether it was observed, reported, inferred, or remains unknown.

Demonstration: watch the request lose certainty

Run the deterministic module demonstration:

npm run course:fde -- --module 01

The output contains a sponsor request, four evidence records, a bounded recommendation, and a stop condition. Read it as a change in claim quality:

1. reported: technicians spend time finding approved service evidence.
2. observed: a synthetic ticket lacks a reconciled equipment identity.
3. inferred: an evidence retrieval step may be a useful intervention point.
4. unknown: the selected population, baseline, and authorized risk owner are not yet established.

The demonstration should not conclude that AI is needed. It should conclude that a representative workflow path can be investigated without granting production access or making a safety decision. The important move is from a solution noun to a testable system boundary.

Scenario walkthrough: the first sponsor meeting

Use this fictional transcript as raw evidence, not as truth:

Sponsor: We want a copilot that reads a ticket and tells the technician the likely repair. It should reduce service time by twenty percent. We can start with our western region next month.

Separate it into fields:

Fragment	Initial status	What it can support	What it cannot support
wants a copilot	reported request	discovery scope	technology necessity
reads a ticket	reported workflow surface	candidate input path	legitimate access or complete semantics
tells likely repair	reported decision intent	identify decision consequence	model authority or safety
reduce service time by 20%	target without contract	metric-definition work	baseline, attribution, or feasibility
western region next month	proposed cohort/window	dependency discovery	readiness or approval

Now rewrite the request:

Investigate whether a bounded evidence-assisted inspection step can help qualified technicians on an approved non-safety subset move from a reconciled ticket and equipment identity to a reviewable next action, while preserving evidence provenance, deterministic policy, accountable approval, safe fallback, and explicit exclusion of unsupported cases.

This statement is deliberately less exciting and more useful. It names the work, the actor, the prerequisite identity state, the evidence product, the authority boundary, and the exclusions. It still does not promise an outcome.

Guided lab: build OA-01

Create a working copy of OA-01 Responsibility Charter and Discovery Plan. Use Appendix A of the book as a structural reference, but produce your own responses to the following prompts.

Step 1: name the unit of accountability

Write one sentence that contains:

• an eligible actor and case;
• a start state and terminal or escalation state;
• the decision or work product being improved;
• evidence and control obligations;
• one explicit non-goal.

Reject any sentence that can be satisfied by a fluent demo while leaving identity, evidence, authority, or failure unresolved.

Step 2: classify the evidence

Create at least eight records with these fields:

evidence_id
statement
status: observed | reported | inferred | unknown
source
scope
confidence
decision_supported
disconfirmation_path
owner

At least two records must remain unknown. At least one reported statement must conflict with an observation. Do not resolve the conflict by averaging confidence; name the next observation that could discriminate between them.

Step 3: map authority

For each decision, name the recommender, implementer, reviewer, and accountable authority:

• legitimate ticket and equipment data use;
• safety-relevant action boundary;
• regional deployment and identity design;
• release disposition;
• operational incident command;
• acceptance of residual business risk.

The FDE may occupy several execution roles. The FDE must not silently become the formal authority merely because another owner has not attended yet.

Step 4: write stop conditions

Write at least five discovery stop conditions. Include missing legitimate access, absent qualified decision owner, unrepresentative evidence, unresolved high-consequence boundary, and a condition under which the requested AI intervention is unnecessary.

Debugging drill: confident but unusable discovery

The lab runner returns a deliberately weak discovery packet. Diagnose each defect before reading the disposition:

• the metric says resolution time but has no population, start/end events, exclusion rules, or baseline;
• the sponsor is named as every authority;
• a support anecdote is labeled observed;
• the discovery plan requests unrestricted ticket notes before a minimum-data question exists;
• the team treats a next-month date as a readiness decision;
• the proposed assistant can produce a safety-relevant recommendation without a qualified reviewer.

For each defect, record:

defect
consequence
missing evidence
next action
decision owner
stop/escalation condition

A good repair does not merely add documentation. It changes what the team is allowed to claim or do.

Project checkpoint: evidence gate 1

Your module artifact passes only if another reviewer can answer all of these questions without interviewing you:

• What exact workflow path is being investigated?
• Which statements are observations, reports, inferences, and unknowns?
• What data and access are minimally justified now?
• Who has authority over risk, release, and domain decisions?
• Which result would disconfirm the proposed intervention?
• What stops discovery or forces a narrower path?
• Which production and customer outcomes remain unproved?

Save the artifact as OA-01. Record its version and the evidence IDs used. Do not add implementation detail that has not been earned by workflow evidence.

Completion evidence

Submit:

1. one bounded outcome statement;
2. an eight-record evidence table with at least two unknowns and one conflict;
3. an authority map with no unassigned formal decision;
4. five stop conditions;
5. a one-paragraph recommendation that separates facts, inference, unknowns, and next evidence.

The module is complete when the recommendation could credibly be continue, narrow, or stop. It is not complete if the structure guarantees that the original copilot request survives regardless of evidence.

Prohibited overclaims

Do not claim that the workflow is representative, the target is feasible, the data use is legitimate, the proposed control is approved, or the intervention will improve outcomes. This lab proves only that you can frame an evidence-seeking deployment question using synthetic material.