Human-Centered AI / Engineering-Handoff Profile
Review the evidence
before engineering.
A six-question review for teams deciding whether to invest in an AI-created or AI-enabled workflow.
Examine the current work, the proposed behavior and the evidence behind it. Designers, builders, business owners and advisors can use the guide without an AI specialization.
0.1-rc.4-candidate.5 · September 24, 2026 · What changed? · Editorial review
Start with a recent case of the work.
An advisor can ask the questions aloud and take notes. Participants can begin without reading the full protocol or filling in technical records.
Owner or advisor?
Bring a recent example of today's work and someone who knows where it gets stuck. Start with time, people and rework.
Designer or builder?
Bring the proposed artifact and its requirements. Show the failure path, the test, and the exact revision tested.
Studying human review?
Use a separate record for experimental judgments. Providing the guide's hints or answer keys can change what the study measures.
Read the research boundaryBegin here: “Walk me through one recent case.”
Where does it start? Who touches it? Where does someone check, fix or chase it? If there is no measurable current-state baseline, stop and observe the work. ROI stays indeterminate.
Read the starting guideWork through the six questions.
Check risk first. Low risk with records available can use QUICK-6. Moderate, high or unknown risk goes to FULL before the short review.
- What happens today? Show the current steps, people, time, touches, failures, review and volume.
- What needs to improve, for whom? Include people affected by the workflow as well as its operators. Connect access, privacy, unequal effects and human control to testable requirements where applicable.
- What happens when things go wrong? Explain edge cases, recovery, data preservation, escalation and human/agent authority.
- What demonstrates the important behavior? Link the exact requirement/context, artifact revision and executed check. Label simulated behavior; changes require a new affected check.
- What work remains for people? Subtract review, correction, escalation and rework before claiming net savings.
- Is that enough to fund the next step? Apply risk depth, retain human evidence-quality review, resolve critical findings, and name the scope, owner and resource limit.
Record gaps when the answer is unknown.
QUICK-6 stops at the first failed or missing gate and marks later gates as not evaluated. Save the record and name the evidence or repair needed. After addressing the gap, continue in a linked FULL review.
The ≤15-minute target remains untested. Session time includes recording answers and explaining the result; preparation is reported separately. Offer breaks and accessible formats as needed.
A polished prototype without a measured baseline
Pause: insufficient evidence.
ROI is indeterminate.
Next: observe a current case.
Owner: the workflow owner.
How the review applies to common problems
These constructed examples describe intended uses. They are not pilot results and do not show that AI causes the defects.
The booking screen loses details after payment fails
The demonstration covers a successful booking, but not a payment failure. Define who notices the failure, which details are preserved and how the user resumes. Revise the recovery path before commitment.
The test report predates the coding agent's latest edit
Compare the tested artifact digest with the current revision. A mismatch blocks the traceability gate; rerun the affected checks. Retain the old report as evidence for the old revision.
The agent can send, but nobody defined approval
Document what it may read, change or send; who can approve or stop it; and how to recover. Use a deeper review when the consequences warrant it.
Checking the AI output consumes the expected savings
In a fictional case, 15 gross minutes saved minus 15 minutes of review/correction/escalation leaves zero net labor savings. Report the zero net savings alongside any recurring cost.
Read all seven scenarios · Inspect a synthetic decision report
The principles and criteria behind the questions
Four principles organize fifteen criteria. Open a principle to find the requirements, ways to check them and examples of failure. A human reviewer must judge whether the evidence satisfies each criterion.
Understand the work before judging the solution
HCAI-1.1 · Bound the task
Requirement: Name the workflow, one unit of work, start and end boundaries, context, AI role, exclusions and a current/manual/non-AI alternative.
How to check: Ask a second person to describe the review's boundaries, then compare their answer with the scope record.
Meets the intent: Review one intake request from receipt to advisor confirmation; exclude live sending.
Common failure: Make our business AI-ready without naming a task.
Verification boundary: Required fields plus accountable human scope review
Decision gate: G2_NEED_REQUIREMENTS. No separate certification is issued.
HCAI-1.2 · Observe the current workflow
Requirement: Retain an observed baseline and a connected current-state map with actors, normal work, exceptions, recovery, time, volume and an endpoint. Mark reported paths separately.
How to check: Follow a recent case through every step; reconcile elapsed time, labor and the sampling window. Inspect where work changes hands or returns for correction.
Meets the intent: A work log supports measured labor; a separate operator account describes an exception not observed in that sample.
Common failure: The owner guesses hours saved without knowing today's steps or work volume.
Verification boundary: Graph and numeric checks plus direct observation review
Decision gate: G1_BASELINE. No separate certification is issued.
HCAI-1.3 · Connect requirements to an actual need
Requirement: Connect each need to an owned, checkable requirement. Use distinct original work or end-user sources at the required risk depth.
How to check: Ask whose difficulty the requirement resolves, what would count as success, and whether two sources share the same origin.
Meets the intent: An operator discussion and a work record independently support preserving data after cancellation.
Common failure: Two summaries of one conversation are presented as two independent customers.
Verification boundary: Reference, origin and source-kind checks plus human relevance judgment
Decision gate: G2_NEED_REQUIREMENTS. No separate certification is issued.
HCAI-1.4 · Include the people who bear the consequences
Requirement: Name affected roles, including non-operators. Screen access/usability, privacy/security, unequal effects and human agency. Link applicable concerns to requirements and validation; justify inapplicable items with an owner and evidence. Human use/control cannot be excluded.
How to check: Ask who might be unable to use, correct, decline or challenge the workflow, and who could be affected without operating it. Inspect the linked success conditions and supporting evidence; a checked box alone is insufficient.
Meets the intent: A requester and an advisor can correct an intake; the requirement specifies retained data, readable error feedback and a human escalation path.
Common failure: The owner saves time, but a requester cannot correct a wrong generated record and nobody evaluated that effect.
Verification boundary: Deterministic coverage and applicability checks plus human/context-specific review; not an accessibility, fairness, privacy or security certification
Decision gate: G2_NEED_REQUIREMENTS. No separate certification is issued.
Make intended behavior and evidence inspectable
HCAI-2.1 · Explain form, fit and function
Requirement: Every requirement names what is represented, how it fits the surrounding workflow, what it must do and the reference material used to judge it.
How to check: Compare the artifact with its reference material to judge whether its role and behavior meet the requirement.
Meets the intent: A review form is linked to required intake fields, advisor responsibilities and cancellation rules.
Common failure: A finished-looking screen is accepted without knowing its purpose or reference requirements.
Verification boundary: Structured references plus human interpretation
Decision gate: G4_TRACEABILITY. No separate certification is issued.
HCAI-2.2 · Trace the exact artifact to a check
Requirement: Each important requirement/artifact pair has an executed check bound to both its exact artifact digest and its requirement/context fingerprint. A change to acceptance criteria, scope, linked states, references, dependencies or authority invalidates the affected check.
How to check: Compare both fingerprints with the record captured when the check ran. Repeat the affected check after a change; computing a new hash does not constitute retesting.
Meets the intent: A cancellation walkthrough records the exact screen revision and the field-preservation result.
Common failure: An agent edits error handling after tests ran, but the old test pass is reused.
Verification boundary: Deterministic chain and revision checks plus inspection of execution evidence
Decision gate: G4_TRACEABILITY. No separate certification is issued.
HCAI-2.3 · Distinguish simulated from implemented behavior
Requirement: Label each requirement's behavior as specified only, simulated or implemented. Do not label a walkthrough of a simulation as an implementation test.
How to check: Identify the connected components and the mocks. Judge functionality from evidence of behavior, independently of visual polish.
Meets the intent: The export button is simulated; the review checks the intended recovery behavior and funds only implementation of that behavior.
Common failure: A mock success screen is presented as proof that a payment or export completed.
Verification boundary: Behavior-status and test-level consistency plus human inspection
Decision gate: G4_TRACEABILITY. No separate certification is issued.
Keep people able to understand and recover
HCAI-3.1 · Cover normal, edge and recovery states
Requirement: Represent connected normal, edge and recovery paths with an entry, resolvable next-state IDs, reachable endpoints, data treatment, ownership and requirement links. Review transition conditions, dependency failures and bounded retry/exit behavior.
How to check: Try missing input, empty results, delay, unavailable dependency, cancellation and resumption where relevant. Document which cases apply.
Meets the intent: A failed save keeps entered data and explains how to retry or return to manual work.
Common failure: The happy path works but a failed save silently discards the user's input.
Verification boundary: State/reference checks plus context-specific human walkthrough
Decision gate: G3_STATES_RECOVERY. No separate certification is issued.
HCAI-3.2 · Make human and automated authority explicit
Requirement: Record what people and automated components may access, change or send. Review approval, interruption, escalation and recovery boundaries. If AI only created the artifact, say so.
How to check: For an agent action, ask who authorizes it, how to stop it, what happens after partial completion and who resolves exceptions.
Meets the intent: A draft-only agent cannot send; an advisor approves changes and can return to a saved record.
Common failure: An agent may delete or message externally without a stated owner, approval boundary or recovery path.
Verification boundary: Required boundary review plus specialist verification when risk demands it
Decision gate: G3_STATES_RECOVERY. No separate certification is issued.
HCAI-3.3 · Count human oversight work
Requirement: Estimate disjoint review, correction, escalation, rework and residual manual minutes with an owner and basis. Distinguish gross from net benefit.
How to check: Subtract every oversight component from gross labor savings. Keep waiting time and labor time separate. Leave missing baseline ROI indeterminate.
Meets the intent: Fifteen minutes of gross savings and fifteen minutes of oversight are reported as zero net time savings.
Common failure: Only generation speed is counted while a person must check and rewrite every output.
Verification boundary: Required fields and arithmetic plus human estimate review
Decision gate: G5_OVERSIGHT. No separate certification is issued.
Make the commitment accountable
HCAI-4.1 · Scale depth before starting
Requirement: Classify six risk dimensions and four consequential-context flags. Use the highest dimension or context floor. Safety/rights impact or irreversible external action sets high; sensitive data or untrusted input to actions sets at least moderate. Any unknown prevents QUICK6.
How to check: Review consequence, reversibility, complexity, importance, impact and mission before choosing the path. Do not lower the classification to fit the meeting's length.
Meets the intent: A consequential allocation workflow goes to FULL even when its interface has only one screen.
Common failure: A simple-looking UI is treated as low risk despite an irreversible outcome.
Verification boundary: Deterministic routing plus competent human risk classification
Decision gate: G6_COMMITMENT. No separate certification is issued.
HCAI-4.2 · Resolve findings at the required depth
Requirement: Review reference defects, findings and unresolved risks. Unresolved critical findings cannot be waived. Add independent review and deeper plans when the risk tier requires them. A recorded human evidence-quality review must address relevance, completeness, authenticity and test adequacy; agent-only assertions cannot replace it.
How to check: Inspect each unresolved finding; passing other gates cannot offset it. Verify reviewer independence for moderate/high risk.
Meets the intent: A critical data-loss defect stays visible even when the baseline is also missing.
Common failure: A critical finding is marked accepted to obtain a favorable readiness result.
Verification boundary: Finding status and evidence checks plus reviewer judgment
Decision gate: G6_COMMITMENT. No separate certification is issued.
HCAI-4.3 · Limit the engineering commitment
Requirement: Record an owner, bounded engineering step, resource limit and next review trigger. Explain any investment despite a nonpositive net estimate; obtain separate owner authorization.
How to check: Ask what the team may build next and what it may not do yet. Retain a separate dated owner decision.
Meets the intent: One engineer-day for a disposable prototype, with no live sending and a review before further work.
Common failure: A gate pass is treated as permission for unrestricted building or deployment.
Verification boundary: Recorded bounds and rationale; authorization remains a separate human act
Decision gate: G6_COMMITMENT. No separate certification is issued.
HCAI-4.4 · Separate effort from performance
Requirement: Record preparation, timed-session and reporting burden. Keep protocol cost, projected operating oversight, reviewer judgments and actual system performance separate.
How to check: Check units and which activity each number measures. Do not infer operational accuracy, safety or readiness from document completeness.
Meets the intent: An expensive evaluation is reported separately from the workflow's projected operating cost.
Common failure: A high checklist score is reported as evidence that the implemented system works.
Verification boundary: Separate contract fields and arithmetic; no combined score
Decision gate: G6_COMMITMENT. No separate certification is issued.
HCAI-4.5 · Preserve evidence and disclosure boundaries
Requirement: Retain exact versions, source origins, digests and previous-run links. Preserve missing and stopped records. Keep private identities/comments out of public materials without permission.
How to check: Check whether another reviewer could reconstruct the run and whether each proposed disclosure is permitted. Retain the old record when creating a new run.
Meets the intent: A new FULL record links to the stopped QUICK6 record; private notes remain outside the public package.
Common failure: A synthetic example is relabeled as an actual pilot or private feedback is published as an endorsement.
Verification boundary: Structural provenance checks plus human permission review; hashes alone do not prove truth
Decision gate: G6_COMMITMENT. No separate certification is issued.
Inspired by WCAG 2.0's layered guidance, not its conformance levels. This author-defined candidate is not a W3C standard, accessibility certification or universal AI-quality standard.
How risk changes the required evidence
Highest of complexity, importance, impact, mission, failure consequence and irreversibility sets depth. Low: at least 1 observed case and 1 need origin. Moderate: at least 3 cases, 2 origins, actual end-user discussion, independent review and validation planning. High: at least 5 cases plus hazard, mission and operational-evaluation planning. Moderate/high require FULL.
These are provisional completeness floors, not representative sample sizes or validated safety thresholds.
What stays separate in the result
Current-state baseline; proposed workflow; protocol evaluation cost and separately operational oversight burden; engineering-handoff evidence; actual post-implementation performance. No combined readiness score. Preparation and session effort are visible. Gross savings, net operating benefit and one-time cost remain distinct.
Consequences can rule out the quick path
Safety/rights effects or irreversible external actions require high-depth FULL. Sensitive data or untrusted input influencing actions require at least moderate FULL. Any unknown context answer prevents QUICK-6, regardless of how simple the interface looks. These are provisional routing floors, not validated risk classifications.
What the software can check
The tools check record structure and decision rules. A human must examine whether the evidence is relevant, credible and adequate. This review must be recorded, although the software cannot authenticate that it took place. The owner authorizes engineering separately, and deployment requires its own evaluation.
Read the deep audit and validation roadmap · Claims and change-control rules
Use the same method with an assistant.
MCP 0.2.0rc5 and ai-ready Skill 0.2.0-rc.5 share the same deterministic gates. The guided path asks one question at a time and produces a readable report that is private by default.
Set up MCP
Requires uv. The first run downloads the versioned wheel and dependencies. It runs locally without a model key; your assistant host can see supplied records. Do not submit confidential data without permission.
{
"mcpServers": {
"hcai-readiness-candidate": {
"command": "uvx",
"args": ["--from", "https://www.takyejun.com/static/research/ai-readiness/rc4-candidate-5/hcai_readiness_mcp-0.2.0rc5-py3-none-any.whl", "hcai-readiness-mcp"]
}
}
}Start with new_review_record, continue with review_next_step, then assessment_report. Get one criterion with get_review_criterion. The tools do not supply evidence or grant authorization.
Set up the ai-ready Skill
The Skill guides the conversation and includes a portable Python engine. Requires Python 3.11+ and Pydantic 2 for deterministic assessment. Without the runtime, it prepares evidence and reports assessment pending.
Download ai-ready SkillExtract the ai-ready folder into your assistant's Skill directory. Follow its included instructions. This does not authorize contacting people or publishing private records.
Guides, worksheets and downloads
Use the conversation worksheet to record the six questions, the reason for the result and the next action's owner. No installation is required; the advisor maintains the detailed evidence record.
Try one bounded external use
Instructions for voluntary use and feedback. No endorsement is requested.
Pilot packet PDFFull profile, package and verification records
Full-profile PDF · Complete candidate package · Software test results · Change-to-test mapping · Download checksums
Evidence and limitations
The protocol proposes a repeatable review of evidence before committing engineering resources. The deep audit identified and corrected software defects. Whether the method improves real decisions still requires comparative evidence; this release does not establish a universal AI standard.
Practitioner correspondence informed refinement. It is not controlled empirical validation. Hillel Glazer approved attribution for his traceability feedback; other themes are summarized without publishing private identities or comments. No endorsement is implied.
The proposed research studies visual fidelity and reviewers' defect detection while AI authorship stays constant. Perceived readiness and confidence are separate judgments. It does not yet establish that AI coding causes these problems or that this protocol prevents them.
No actual external pilot is recorded. Usability, the time target, risk thresholds and effectiveness remain unvalidated. Final rc.4 requires regression checks and recorded bounded end-user/advisor use. The owner separately authorizes engineering; deployment requires separate evaluation.
Frozen history, citation and reuse
rc.3 and the four earlier rc.4 candidates remain available, unchanged. Historical rc.3 PDF · First-candidate package · Migration notes · Candidate.2 package · Candidate.3 package · Candidate.4 package.
Tak, Y. (2026). Human-Centered AI Deployment Readiness Protocol: Engineering-Handoff Profile, 0.1-rc.4-candidate.5. MCP 0.2.0rc5; Skill 0.2.0-rc.5. No candidate DOI is assigned. 10.5281/zenodo.22667623 identifies rc.3 only.
Original text and synthetic data: CC BY 4.0; software: MIT. AI-assisted development. Research Harness v3 is a separate project, not validation evidence for this protocol. Source repository.