These examples teach a method. They are not your assessed submission, validated industry policies or proof of real deployment. Use changed inputs and your own observed results for assessment.
Commercial account preparation and approved handoff
A fictional telecom account manager prepares a renewal meeting. Information is scattered across an account note, a meeting transcript and a service update. The assistant prepares a brief with source references and a proposed follow-up. It cannot promise commercial changes or send a message.
Fictional source pack
AC-01: SYNTHETIC account record
Lotus Components, a fictional enterprise connectivity customer. Account owner: Mira. Renewal review: 2027-02-15. Current contract value: 120,000 fictional currency units annually. No approved discount is recorded. Baseline preparation time is an assumption until measured.
MT-01: SYNTHETIC meeting transcript
Mira: We should investigate the service concern before renewal. Buyer: Please consider a 10% discount and send the latest recovery estimate. Mira: I will ask the service manager; I cannot confirm a discount or a recovery time. No follow-up deadline was agreed.
SV-01: SYNTHETIC service record
Incident INC-04 is investigating. No verified restoration estimate. Service manager is the escalation owner. Only approved account contacts may receive the account update. Policy POL-02 requires approval before commercial commitments or external messages.
POL-02: SYNTHETIC action policy
Drafting is allowed for authorized account staff. Sending messages or changing contract fields requires a separate approval and authorized tool. A customer request is not approval. Missing facts remain unknown. Never expose another account’s records.
Annotated end-to-end walkthrough
Define the scope: one account manager, one renewal brief, approved sources only. Exclude discount negotiation, contract edits and outbound sending. Write a quality checklist before asking the assistant to draft.
Inspect the four records. Separate confirmed facts (owner, review date, incident state) from requests (discount, estimate) and gaps (deadline, verified recovery time). Keep record IDs.
Use this instruction: From AC-01, MT-01, SV-01 and POL-02, produce a brief with facts, open questions and proposed next actions. Cite each factual bullet. Mark requests as requests. Use unknown for missing values. Draft only; do not send or promise a change.
Compare the output with the worked result and its explanation. If it turns a requested discount into an approved offer, record a critical failure and revise the instruction. Do not silently correct the output and call the run successful.
Prepare a structured handoff: account_id AC-01, incident_id INC-04, question verified recovery estimate, owner service manager, status pending approval. Keep the actual deadline unknown.
In an authorized sandbox, inspect the actual available read/update tools. Preview a proposed record update, obtain the required approval, apply the approved limited change and verify the stored result. If the tool is unavailable, record that blocker rather than pretending it ran.
Repeat with a different fictional account and a conflicting record. Keep that case separate from the example used to improve the instruction.
Measure manual and assisted preparation on comparable tasks. Count research, prompting, verification and corrections. Report total time and quality, not just generation time.
Present a five-minute explanation: user problem, source boundary, one observed failure, correction, handoff and remaining supervision. Do not claim measured savings from these fictional example records.
Expected example outputs and why they are appropriate
Meeting facts
Mira owns the account; renewal review is 2027-02-15 [AC-01]. Incident INC-04 remains investigating [SV-01].
Why: Both claims are directly supported by source records.
Commercial request
The buyer requested consideration of a 10% discount; no discount is approved [MT-01, AC-01].
Why: A request must not become a commitment.
Unknowns and next action
Recovery time and follow-up deadline are unknown. Ask the service manager for an approved update; keep any external response as a draft [SV-01, MT-01, POL-02].
Why: The records do not support invented dates or execution.
Failures and changed-case practice
Critical failures
Inventing a restoration date
Treating the 10% request as approved
Claiming an email was sent without a tool result
Leaking another account’s information
Try a different case
A second source changes the incident to resolved but has no approval/version metadata. Ask which source is approved by the responsible owner.
The account user lacks permission. Expect a denial without revealing account content.
A write times out. Check status using the stable request key before attempting another action.
A fictional equipment supplier receives quote requests by email. Sales drafts quotes in a spreadsheet, pricing and stock come from the ERP, and finance approves discounts. The client wants fewer incomplete requests and less rework before approval. This pilot ends at an approved draft and operator handoff. Sending quotes, updating the ERP and collecting payment are outside scope.
Choose this case or use the same decision exercise on your current project. If you already have an agreed scope, keep working on it and apply the exercise at your next relevant checkpoint.
Open the synthetic source pack
REQ-101, incoming request. An existing customer asks for eight AX-40 units and a 12% discount. Delivery region is missing.
ERP-201, pricing and stock snapshot. AX-40 is listed at 250 USD per unit and six units are available. The snapshot must be refreshed before approval if current availability cannot be confirmed.
POL-301, fictional approval policy. Discounts above 10% require finance approval. Missing region or unavailable stock must be flagged. The ERP owns catalog, stock and price data. The approval record owns the decision.
REQ-102, comparison request. Another existing customer requests two AX-40 units for the Dallas region at list price. Use this alongside REQ-101 and add a changed case of your own.
Choose your track
Applied AI Practitioner
Map the current workflow, time a manual pass, and configure or simulate a triage workflow with a clear approval handoff. Show what an operator sees when information is missing and what they check before approving.
AI Engineering and Forward Deployed AI
Build one bounded integration in an authorized training environment, such as a read-only catalog lookup and an approval-gated draft write to a training store. Test denied access, stale data, a timeout, and a duplicate retry. Show how the operator recovers.
Use the existing checkpoints
Week 1 · Discovery and scope. Map who requests, prepares and approves a quote. Measure manual effort on synthetic requests and agree what success means.
Week 3 · Tool choice and integration. Complete the architecture decision below before committing to a build. Show the approval boundary and observed test results for your chosen scope.
Week 9 · Pilot and release readiness. Show the version, environment, smoke checks and recovery steps. Hand off unresolved exceptions to a named role.
Week 12 · Demonstrated delivery and impact. Walk through a successful request and a blocked request. Compare assisted and manual effort on comparable cases, including review and corrections. During the live change exercise, handle a revoked catalog permission or a new approval rule, then rerun the affected checks.
One-page architecture decision
Use this exercise for quote-to-cash or any project you already have in flight. Attach your decision to the existing Week 3 submission when it fits your current milestone.
Problem and success measure. Who does the work, what fails today, and what baseline will you compare against?
Options. Compare a process change, rules-based automation, an existing product and a custom AI workflow. State which is simplest for your acceptance criteria and what each costs or puts at risk.
Systems and authority. List the source of truth for each important field. Identify who may read, who approves writes and what remains manual.
Decision. Explain what you chose, why the other options fell short, and which assumption or constraint would make you revisit the choice.
Evidence. Name the test and expected outcome that would justify moving forward. Include at least one condition that stops the workflow safely.
Worked example. Start with a required-fields form and fixed approval rules. Consider AI for extracting details from free-text requests only if a measured comparison shows less operator effort while preserving the same approval and accuracy standards.
