Evidence before engineering commitment.

1. Can we quantify today's work? Capture the current path and people, cycle and labor time, touches, failures, review, rework and volume. No measured baseline means insufficient evidence and indeterminate ROI.
2. Whose need does the change address? State the outcome and connect it to owned requirements with measurable acceptance criteria.
3. What happens at the edges? Define normal, edge and recovery paths, data preservation, dependencies and responsibility.
4. Can we trace the behavior? Connect each important artifact to its requirement, form/fit/function references and an executed walkthrough or test.
5. Who checks and corrects AI output? Estimate review, correction, escalation, rework and remaining manual effort before trusting gross savings.
6. What engineering step is justified? Apply risk depth, resolve blocking findings, and record a resource ceiling, owner and next review trigger.

ACurrent-state baseline

Observed time, people, handoffs, errors, review, escalation, rework and volume. Compare proposed work with a measurable starting point.

BProposed workflow

End-user needs, requirements, states, edge cases, recovery, owners, acceptance criteria and dependencies.

CEvaluation and oversight burden

Record the time and cost of running this protocol. Separately estimate the human review and correction burden of operating the proposed workflow.

DEngineering-handoff evidence

Trace requirements to artifacts and validation. Retain reference defects, reviewer findings, unresolved risks and the bounded decision record.

EOperational system performance

Measure after implementation in realistic use. Documentation and upstream gate results do not establish this layer.

These are provisional minimum evidence floors, not validated safety thresholds or statistically representative sample sizes. The full profile may require more evidence for the actual context.

• Requirements first: make the intended workflow testable before committing engineering resources; separate the later deployment decision.
• Current state before ROI: require a measured baseline and include the human effort created by AI output.
• Traceability beyond appearance: Hillel Glazer's feedback emphasized requirements, validating tests and reference material for form, fit and function. Attribution is approved; no endorsement is implied.
• A usable short path: provide advisor-led QUICK-6, visible stops and risk-based escalation.
• Actual use as the next evidence stage: collect a bounded end-user/advisor session with permission, time, gate outcomes and feedback. Keep private correspondence private.

Other feedback themes are reflected in these design changes without publishing private identities or comments. Correspondence, meeting invitations and software tests are distinct from controlled empirical validation.

Actual external pilot records are currently empty. Promotion to final rc.4 requires passing regression checks and recorded bounded external use reviewed by the author.

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

Every run records protocol, MCP, Skill and contract versions plus evidence digests. Agent reviews remain separate from human observations. A qualifying recommendation still requires the owner's recorded engineering authorization.