Protocol Library

Find the evidence a requirement calls for, or set up a review in your assistant.

Human-centered AI Readiness and Decision Protocol. Review choices and evidence at a declared stage; add engineering or research procedures when needed.

Reference / 15 criteria

Search the criteria.

Try a problem such as recovery, a gate name or a criterion ID. Each rule explains what to check and gives examples.

15 criteria shown

HCAI-1.1Bound 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.
Example that 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: Required fields plus accountable human scope review

Link to this rule

HCAI-1.2Observe 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.
Example that 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: Graph and numeric checks plus direct observation review

Link to this rule

HCAI-1.3Connect 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.
Example that 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: Reference, origin and source-kind checks plus human relevance judgment

Link to this rule

HCAI-1.4Include 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.
Example that 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: Deterministic coverage and applicability checks plus human/context-specific review; not an accessibility, fairness, privacy or security certification

Link to this rule

HCAI-2.1Explain form, fit, function and the model behind consequential choices

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. When a software choice needs deeper review, record the relevant system model rather than treating the generated implementation as its own explanation.
How to check: Compare the artifact with its reference material. For a consequential software choice, ask which system surfaces and consequential assumptions the behavior depends on and whether each current model or assumption is supported.
Example that meets the intent: A review form is linked to required intake fields and cancellation rules; its saved-state choice also names the authoritative record and owner.
Common failure: A finished-looking screen or generated code path is accepted without knowing its purpose, reference requirements or the system model it relies on.
Verification: Structured references and decision-surface records plus human interpretation

Link to this rule

HCAI-2.2Trace 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. The context includes applicable consequential choices, system surfaces, first-class assumptions, challenge conditions, linked states, references, dependencies and authority. A material change invalidates the affected check.
How to check: Compare both fingerprints with the record captured when the check ran. Repeat the affected check after a requirement, choice, system surface, assumption, challenge condition or artifact changes; computing a new hash does not constitute retesting.
Example that meets the intent: A cancellation walkthrough records the exact screen revision and the field-preservation result.
Common failure: An agent changes authorization or the assumed source of truth after tests ran, but the old pass is reused.
Verification: Deterministic chain and revision checks plus inspection of execution evidence

Link to this rule

HCAI-2.3Distinguish 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.
Example that 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: Behavior-status and test-level consistency plus human inspection

Link to this rule

HCAI-3.1Cover state transitions, edge cases and recovery

Requirement: Represent connected normal, edge and recovery paths with an entry, resolvable next-state IDs, reachable endpoints, data treatment, ownership and requirement links. Where relevant, review partial completion, repetition, ordering/concurrency, dependency failures and bounded retry/exit behavior.
How to check: Try missing input, empty results, delay, unavailable dependency, cancellation and resumption. For state-changing work, ask what happens when the same operation happens twice, two transitions race, or execution stops halfway.
Example that meets the intent: A repeated invitation accept is idempotent, a revoked invitation cannot become active, and an interrupted email step does not corrupt membership state.
Common failure: The happy path works, but duplicate requests or a partial failure can create contradictory state.
Verification: State/reference checks plus risk-scaled walkthrough or executed challenge evidence

Link to this rule

HCAI-3.2Make system truth and authority explicit

Requirement: For relevant consequential choices, identify authoritative truth, who may mutate it, derived or cached representations, responsibility boundaries and interface guarantees. Review what happens when sources disagree and how people or automated components approve, interrupt, escalate or recover. If AI only created the artifact, say so.
How to check: Ask which record wins when two representations disagree, who can change it, which component owns each side effect, and what the boundary promises on success, timeout or partial completion.
Example that meets the intent: Membership state is authoritative in the membership service; invitation tokens cannot directly grant access, duplicate acceptance is contained, and a named owner can revoke or repair state.
Common failure: UI state, cache and database are all treated as truth, or a component can mutate consequential state without a stated owner or contract.
Verification: Decision-surface, authority and boundary review plus specialist verification when risk demands it

Link to this rule

HCAI-3.3Count 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.
Example that 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: Required fields and arithmetic plus human estimate review

Link to this rule

HCAI-4.1Scale 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.
Example that 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: Deterministic routing plus competent human risk classification

Link to this rule

HCAI-4.2Resolve findings at the required depth

Requirement: Review reference defects, findings, challenged assumptions and unresolved risks. A conflicted required decision surface or failed consequential challenge remains visible until resolved or the scope is changed transparently. 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 and deepened choice. Passing other gates cannot offset a demonstrated contradiction. Verify reviewer independence for moderate/high risk.
Example that meets the intent: A duplicate-payment challenge fails and remains a blocker even when the baseline and happy-path tests pass.
Common failure: A failed challenge is replaced by a plausible AI explanation so the review can proceed.
Verification: Finding status and evidence checks plus reviewer judgment

Link to this rule

HCAI-4.3Limit the next commitment to a coherent slice

Requirement: Record an owner, bounded engineering step, resource limit and next review trigger. For software work, prefer the smallest coherent slice that can expose the important assumption across input, validation, state change or persistence, failure/recovery and observable outcome when those elements apply. Explain any investment despite a nonpositive net estimate; obtain separate owner authorization.
How to check: Ask what one end-to-end slice would produce evidence about the riskiest unresolved reasoning, what the team may not build yet, and when the choice will be reopened.
Example that meets the intent: One engineer-day to prove authorized invitation creation through acceptance, persistence and duplicate/revoked handling; no broader dashboard or production rollout.
Common failure: A favorable review is treated as permission to generate the whole frontend and backend before the key state assumption is tested.
Verification: Recorded bounds, coherent-slice rationale and separate human authorization

Link to this rule

HCAI-4.4Separate 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.
Example that 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: Separate contract fields and arithmetic; no combined score

Link to this rule

HCAI-4.5Preserve 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.
Example that 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: Structural provenance checks plus human permission review; hashes alone do not prove truth

Link to this rule

Tools / Choose only what you need

Choose how you want to review.

Use the guide on its own, connect MCP for the checks, or add the Skill to guide a conversation. The evidence requirements do not change with the tool.

Read or print the guide

Download protocol PDF QUICK-6 worksheet PDF

Connect MCP to your assistant

Add this entry to your assistant's MCP settings, keeping existing servers. Requires uv. The first run downloads the package and dependencies.

{
  "mcpServers": {
    "hcai-readiness-candidate": {
      "command": "uvx",
      "args": [
        "--from",
        "https://www.takyejun.com/static/research/ai-readiness/hard-0.3-preview-1/hcai_readiness_mcp-0.3.0rc1-py3-none-any.whl",
        "hcai-readiness-mcp"
      ]
    }
  }
}

After connecting, ask your assistant: “Start an ai-ready review of this workflow. Ask for missing evidence before evaluating any gate.”

Use the ai-ready Skill

Extract ai-ready into your assistant's Skill directory and invoke ai-ready. Its deterministic runtime requires Python 3.11+ and Pydantic 2. Without the runtime, assessment stays pending.

Download Skill

Start small / Expand where evidence is missing

Review one artifact with the people you have.

Choose a plan, prototype or code revision. Decompress its important choices to purpose, alternatives, tradeoffs, assumptions, evidence and an accountable human decision. When consequence warrants deeper engineering review, externalize only the relevant system truth, state, authority, boundary and timing decisions. Keep assumptions as separate reviewable claims and keep specified, walkthrough, implemented and runtime-tested evidence distinct.

Start Artifact Review Choice review guide Engineering reasoning deepening Optional research layer

The source package includes matching CSV templates, a worked example and a synthetic runtime-AI plan. Run python Source/verify_example.py to check the supplied examples. No model account is required.

Download source and templates Artifact Review MD Complete protocol MD

Reference / Tools and data

Use the tool for your review purpose.

Ask your assistant to start a H.A.R.D. review of one workflow. It gathers the evidence you provide, keeps unknowns explicit and can deepen consequential software choices into system surfaces, assumption lifecycles and bounded challenges. The deterministic engine checks the supplied record; it does not invent evidence or recover private reasoning.

Task	MCP tool
Prepare an artifact review	`artifact_review_template`
Check artifact evidence and choices	`assess_artifact_review`
Start the engineering review	`new_review_record`
Find the next question	`review_next_step`
Inspect a rule or gate	`get_review_criterion`, `get_gate_guide`
Check revision references	`get_validation_targets`
Evaluate the record	`assess_engineering_commitment`
Read the result	`assessment_report`

Schemas and exact source files

Artifact Review schema and canonical CSV contract
Assessment input and result schema
Pilot-run schema and study-review schema
Criterion catalogue, risk depth and context floors

Decision boundaries

PROCEED_TO_ENGINEERING supports a bounded engineering recommendation. REVISE identifies a known failure. INSUFFICIENT_EVIDENCE identifies a missing basis for a decision. The owner authorizes engineering separately.

QUICK-6 stops at the first failed or missing gate. Moderate, high or unknown risk requires FULL. No score can average away a failed critical gate. Evaluator cost, operating oversight and system performance remain separate.

Versions and limitations

Protocol 0.3-preview.1 · MCP 0.3.0rc1 · Skill/contract 0.3.0-rc.1.

Public Preview. Decision compression and implementation outrunning understanding are motivating models, not measured causal effects. Practitioner feedback is not controlled empirical validation. A model suggestion is not verified evidence. A successful software test does not establish operational performance.

Protocol update log Source checksums Attribution