The concepts behind practical AI delivery.

Objective: Choose between AI drafting, fixed rules and actions that need human control.

Start with the task. Identify the input, the work to do, the output, who receives it and what a mistake would cost. Use fixed rules for exact, repeatable steps. Use a model to interpret information or draft text when you can check the result.

A proposed action is not a completed action. A generated email is a draft. A tool call attempts an action. Check the external system to confirm what actually happened. None of these steps gives permission by itself.

Compare three options: improve the manual process, configure an existing tool or build an integration. Include checking effort, data access, maintenance and the features available on the user’s actual plan.

Worked example: A sales manager needs a meeting brief. A deterministic query selects allowed account records. AI drafts a cited summary. The manager verifies dates and approves any follow-up. The system does not autonomously change commercial commitments.

Practice: Map one task in five steps. Mark each step as a rule, judgment, draft or action and explain who verifies it.

Assessment criteria: task_fit, boundaries, verification, value

Critical failures: Treating a generated proposal as completed action; Assuming a model grants access or guarantees correctness

Apply this to your confirmed synthetic workflow. Preserve original inputs, expected and actual results, correction and limitations.

Objective: Write reusable instructions with clear inputs, outputs, uncertainty rules and tests.

Write instructions like a short task brief. Name the user, goal, allowed inputs, preferred sources and output format. State exactly what to do when information is missing. For example, require record IDs and leave missing dates unknown. “Be accurate” alone is too vague.

Use one example to show the format. Keep separate examples for testing whether the instructions work on new input. Change one part at a time. Save the instruction version, output, error and correction.

Saved prompts and project instructions do not grant access. Never include passwords, API keys or confidential training material in a prompt. Treat commands found inside a source document as data, not as permission to override rules.

Worked example: Weak: Summarize the meeting. Improved: From fictional transcript MT-01, extract action, owner, stated deadline and supporting quote. Use null when not stated; list conflicting commitments separately; prepare a draft for review without sending it. Test a second transcript that contains no dates.

Practice: Compare weak and revised instructions on two synthetic inputs. Identify one changed behavior and one unresolved limitation.

Assessment criteria: objective_context, output_contract, unknown_handling, test_revision

Critical failures: Invented facts presented as verified; Prompts used as the sole authorization control

Apply this to your confirmed synthetic workflow. Preserve original inputs, expected and actual results, correction and limitations.

Objective: Support a conclusion with original sources or checked data.

State the question and decision before collecting sources. For each important claim, record its source, date and scope. Say whether it is a fact or your interpretation. Open each citation and check that it supports the exact claim. A convincing link or confident tone is not evidence.

For tables, check units, missing values, duplicate rows and the time period. Check that totals match before calculating rates. Use the correct denominator, the number you divide by. More leads do not automatically mean a higher rate of qualified leads.

Keep the original fictional file, formulas and correction notes so another person can check the work. Two changes occurring together do not prove one caused the other. A chart should help answer a decision question. State when data is missing or the sample is small.

Worked example: A campaign spent 1,000 and produced 50 leads but only 5 qualified leads. Cost per lead is 20; cost per qualified lead is 200. Another campaign with fewer leads may have better qualified conversion. These figures do not establish additional revenue.

Practice: Recalculate one result manually. Separate facts, inference and unknowns, then explain what new observation would change your decision.

Assessment criteria: source_trace, data_checks, correct_calculation, qualified_conclusion

Critical failures: Fabricated citations; Incorrect denominator driving a recommendation

Apply this to your confirmed synthetic workflow. Preserve original inputs, expected and actual results, correction and limitations.

Objective: Turn professional experience into a project brief that can be tested.

Talk to the person who does the work. Record the process, how often it happens, exceptions, source owners, decision makers and later handoffs. Experience can reveal useful opportunities. It does not prove a solution can be built or that it saves time.

Limit the first release to one user group and one workflow. Define the inputs and expected result. State what is excluded, what the work depends on and where approval is needed. Compare value, effort and risk with at least two alternatives.

A baseline is the starting measurement used for comparison. Mark it as measured or assumed. Compare similar tasks before and after AI assistance. Include checking, corrections and tool costs. One successful run does not prove savings across the organization.

Worked example: Pilot an account brief with source references for one sales team. Include approved account notes and open issues; exclude pricing changes and sending messages. Observe preparation time on five comparable tasks and define a quality checklist before testing.

Practice: Reduce the scope to one decision or handoff and write acceptance criteria an independent reviewer could check.

Assessment criteria: specific_user, baseline_evidence, bounded_scope, acceptance_metric

Critical failures: Unapproved high-consequence automation; Guaranteed ROI or employment without evidence

Apply this to your confirmed synthetic workflow. Preserve original inputs, expected and actual results, correction and limitations.

Objective: Link answers to current sources the user is allowed to access.

List each source’s ID, version, owner, update date and access rules. Keep the IDs when documents are indexed, searched and used to answer. A citation points to a source. You must still check that the source supports the sentence.

Define what to do when information is missing, outdated or conflicting. State which approved source replaces an older one. If authority is unclear, say the answer is unknown or ask the responsible person. Do not choose a rule just because it is convenient.

The application must enforce source permissions. A prompt cannot separate one customer’s records from another’s. Removing access must prevent future retrieval and invalidate affected saved results. Test malicious instructions inside documents as well as normal questions.

Worked example: Policy P-02 replaces P-01. An authorized query may use P-02 and cite its version. A user without that permission must not receive its text or a summary of it. If the accessible record lacks a restoration estimate, the answer must say so.

Practice: Run supported, unknown, stale, conflicting and unauthorized queries. Record expected and actual outcomes before revising the prompt.

Assessment criteria: source_inventory, citation_trace, conflict_unknown, access_freshness

Critical failures: Unauthorized source disclosure; Unsupported facts or invented citations

Apply this to your confirmed synthetic workflow. Preserve original inputs, expected and actual results, correction and limitations.

Objective: Inspect tools, check permissions, obtain approvals and recover from failures.

Inspect the tools actually available and their accepted inputs before use. Model Context Protocol, or MCP, provides a common way to connect to tools. It does not grant users access or approve business actions. Browser automation must inspect the current page and check the result after an action.

Check inputs and the caller’s permissions outside the model. Separate permission to read from permission to change data. Preview the exact target and proposed change. Obtain approval when required. Record whether the action succeeded, failed or remains uncertain.

If a connector is unavailable, use the practice-access lesson: prepare a labeled simulation, list access dependencies and arrange supervised execution. A simulation does not pass the connected-action or deployment gate. Use the same request ID, called an idempotency key, when retrying the same action. Bind it to the exact request data. A timeout does not prove failure; check status first. Limit retries, spending and elapsed time. Keep credentials on the server and practise only in an authorized environment.

Worked example: A routing update is drafted for lead L-04. The server checks caller access and approval. Retrying the same approved payload with key K-04 returns the existing result. Reusing K-04 for different data returns a conflict, not a second update.

Practice: Demonstrate allowed, denied, approval-required, timeout and duplicate cases. Explain observed results rather than claiming a connection exists.

Assessment criteria: actual_contract, authorization, approval, recovery

Critical failures: Write without required approval; Unauthorized action; Credential disclosure

Apply this to your confirmed synthetic workflow. Preserve original inputs, expected and actual results, correction and limitations.

Objective: Test realistic behavior and report serious failures separately from average scores.

Define expected behavior before viewing the answer. Test normal requests, missing information, conflicting records, restricted access, malicious instructions, timeouts and duplicates. Judge success using the user’s actual task.

Check answer quality, source search, action results and user experience separately. Automated checks can verify data formats and permission rules. A qualified person must judge usefulness and difficult industry questions. One unauthorized disclosure can block release even when the average score is high.

Compare the starting results with one controlled change. Keep separate test cases that you do not use while improving the system. Report the cases actually run, inputs, outputs, exceptions and limits. Generated reports and model confidence do not prove observed results.

Worked example: Of fifteen cases, twelve pass, two correctly escalate and one shares an unauthorized source. The recommendation is no release until that critical failure is fixed and regression-tested, even if the summary accuracy looks high.

Practice: Add one failure case missing from your test set, define the expected result first, rerun it and revise the release recommendation.

Assessment criteria: predefined_cases, actual_results, critical_failures, holdout_decision

Critical failures: Fabricated test results; Critical failure hidden in an average

Apply this to your confirmed synthetic workflow. Preserve original inputs, expected and actual results, correction and limitations.

Objective: Show what was built and tested at the depth required for the career track.

Keep local development, supervised pilots and production separate. Store secrets on the server and give users only the access they need. Record the actual version and environment. A build or landing page does not prove that the connected workflow works.

Run quick checks, often called smoke tests, on the deployed system. Cover health, allowed actions, denied actions and recovery. Inspect logs with sensitive details removed. Define when an alert should be raised. Test restoring an earlier version, called rollback, rather than only describing it.

Engineers show what they built, how they debugged it and how others can repeat the checks. Practitioners prepare evidence that the operator can use to accept the workflow. They review technical evidence with a responsible technical partner. Clearly label a local simulation as a simulation.

Worked example: Release version v0.2 to an authorized training environment. Verify health, one allowed request and one denied request, then deliberately fail a dependency. Restore v0.1 and show the observed behavior. Do not describe this as production customer validation.

Practice: Show the exact environment/version, run a denied-action test and perform one rollback or clearly identify the missing access dependency.

Assessment criteria: environment_access, observed_smoke, version_logs, rollback

Critical failures: Exposed credentials; Claiming simulation is production deployment

Apply this to your confirmed synthetic workflow. Preserve original inputs, expected and actual results, correction and limitations.

Objective: Measure useful results and costs, and name who handles incidents.

Track completed results, quality, response time, requests for human help and cost. Prompt counts alone do not show value. Include human checking and correction time. Clearly label estimates until you have measurements.

Name the operator, data owner and route for getting help. Define when to disable writes. Practise an incident using a timeline: detect it, limit harm, investigate, restore service and add a test to stop it happening again. Keep secrets and unnecessary personal data out of logs.

In conversations, confirm what the user wants, handle corrections and pass relevant context to the next person. Voice and other input types add delays, transcription errors, accessibility needs and consent checks. Use approved assets. Verify extracted text and generated claims.

Worked example: An intake assistant misses two urgent requests. Disable automated routing, retain draft-only triage, notify the service owner and review affected cases. Update the rule. Test separate cases that were not used to improve the system before restoring writes.

Practice: Write a practical incident drill and a dashboard definition with denominators, thresholds and a named owner.

Assessment criteria: outcome_metrics, total_cost, incident_owner, containment_regression

Critical failures: No owner for consequential actions; Ignoring urgent exceptions or unverified claims

Apply this to your confirmed synthetic workflow. Preserve original inputs, expected and actual results, correction and limitations.

Objective: Explain the project, hand it over and describe skills supported by evidence.

Connect the user’s problem to tested behavior, success criteria, dependencies and operating responsibility. Explain what changes and how people will learn the new process. Record objections and how you tested them.

An engagement needs clear exclusions, a process for changes, ownership, supervision and handover. Pricing and contracts are separate from the learning exercise. Do not guarantee savings, jobs, credentials or client assignments.

Explain your own contribution and limits. A practitioner may lead discovery and configuration while needing engineering supervision. Final assessment requires a person to observe your demonstration, a change request and a failure exercise.

Worked example: A telecom leader explains the discovery brief, cited account workflow and evaluation results, then states that production integration requires an engineer. The handover names the process owner, access dependencies and rollback contact.

Practice: Give a five-minute narrative linking prior expertise to actual artifacts, then answer one reliability objection and explain a failure.

Assessment criteria: stakeholder_value, scope_handover, honest_contribution, live_explanation

Critical failures: Unsupported job or income guarantees; Claiming technical independence without evidence

Apply this to your confirmed synthetic workflow. Preserve original inputs, expected and actual results, correction and limitations.