Protocol update log
Last updated: September 26, 2026. Current: H.A.R.D. Protocol 0.3 · Public Preview.
Human-centered AI Readiness and Decision Protocol. Exact protocol 0.3-preview.1; MCP 0.3.0rc1; Skill/contract 0.3.0-rc.1.
This is a record of changes, not a validation claim. Historical versions remain available. Formative reported use does not establish a conformant independent evaluation, adoption, endorsement or performance improvement.
September 26, 2026: decision decompression and engineering reasoning deepening
H.A.R.D. 0.3 makes explicit a rationale that was only partially represented in preview.3: AI-assisted creation can compress intention into a convincing artifact before responsible people have externalized the consequential system model behind it. The protocol calls this decision compression. This is a motivating model, not a measured causal result.
The existing choice review remains the foundation. 0.3 adds explicit engineering-deepening triage for each consequential choice and, when warranted, structured system surfaces for truth, ownership, state, boundary, contract, failure/recovery and time/ordering. Consequential assumptions become separate review records. It also adds bounded challenge scenarios with explicit evidence levels and a smallest coherent next software slice. These are targeted deepening records, not a seventh gate, extra score or reconstructed chain-of-thought.
| Change | What it does | Evidence boundary |
|---|---|---|
| Decision compression rationale | Explains why the review reopens choices after generation. | Does not establish that AI causes the effect or that H.A.R.D. improves outcomes. |
| System surfaces | Makes relevant source-of-truth, state, ownership, contract and timing models inspectable. | Supported means source-backed within scope, not universal correctness. |
| Challenge scenarios | Asks what condition could disconfirm a consequential choice and binds any assessed result to walkthrough, implemented or runtime-tested evidence. | A generated failure story is not evidence that the failure occurs. |
| Assumption lifecycle | Gives each consequential assumption a stable record with supported, conflicted or unassessed status, consequence-if-false, evidence needed, retained evidence and revisit trigger. | Recording an assumption does not make it true. |
| Coherent next slice | Bounds software investment around one end-to-end assumption test when applicable. | Does not prescribe a specific architecture or authorize deployment. |
| CSV contract 2.1 | Adds assumptions.csv, decision-surfaces.csv and challenge-scenarios.csv with challenge evidence levels, while keeping JSON/MCP/Skill parity. | Old packages and runs remain frozen. |
The six gates and fifteen criterion IDs remain. G3 and G4 are deepened; G6's bounded commitment is clarified for software work. The related fidelity study and independent-evaluation rules remain separate.
Read engineering reasoning, decision review, migration notes and the complete protocol.
September 26, 2026: inspect choices and support small-team artifact review
The author's rationale places choices at the center of the review. Starting from a completed result, reviewers connect purpose, criteria, alternatives, rationale, tradeoffs, verification and remaining human judgment. Documented historical reasons remain distinct from current new explanations. A justified original choice can be retained.
The preview adds a formal artifact_review route for a solo practitioner or small team, including specifications with no code. It does not require a measured baseline or ROI and does not grant an engineering gate pass. QUICK6/FULL retain the six gates, fifteen criteria, risk floors and engineering formulas. Targeted deepening describes additional inspection, not a new validated scoring profile.
| Feedback or rationale | Revision | Evidence limit |
|---|---|---|
| Results conceal choices and expert judgment | Choice records connect purpose, alternatives, rationale provenance, tradeoffs, verification and actual human disposition. | Does not recover private model reasoning or prove improved decisions. |
| Templates and examples diverged | Current templates, complete examples and verification use consistent four-level evidence records. | Historical archives remain unchanged; software checks cover the revised implementation. |
| Artifact population was omitted from aggregation | Required artifact_population accompanies criterion and evaluator population in batch handling. | Stratification alone does not establish a valid comparison. |
| Independent roles are impractical for small teams | Minimum artifact route plus metric-specific eligibility and N/A reasons. | Solo and agent findings are not independent human-performance evidence. |
| Severity and deferred scope were ambiguous | Require applicability, evidence, failure mechanism and consequence; retain proposed versus adjudicated severity. | Private source attachments were not independently examined; no reported finding is asserted as verified. |
The optional companion integration is removed from the active distribution and navigation. Preserved historical releases retain their original contents and identities.
The additional feedback was agent-mediated and lacked the controls required for independent evaluation. It informs usability and consistency fixes. Public summaries omit private names and quotations. The proposed fidelity study remains separate, and no efficacy or deployment claim is added.
Read the migration notes, artifact-review guide, decision review and metric eligibility.
September 25, 2026: Decision replaces Deployment in the full name
The display uses H.A.R.D. as initials. The overview now starts with the missing review layer beneath a polished artifact, using a constructed booking example. Its two hero paths lead to a workflow review and the Developer Library. Rules and installation are maintained in the library, not repeated as competing actions on the overview.
The practical protocol, MCP and Skill explain how to keep the original artifact and create a separate structural view when useful. Experience, architecture, technical evidence and operating responsibility remain connected to the existing gates. This technique is unvalidated and must not become an unplanned intervention in the fidelity study. C31 records this explanation and navigation change; the author's architecture anecdote is context, not empirical support.
The author found Deployment too technical and easy to mistake for release approval. Decision describes what the review actually supports: deciding whether to invest in building a bounded workflow, revise it, or gather missing evidence. The public name remains H.A.R.D. Protocol 0.3, with Public Preview shown separately.
| Identity | Preserved first preview | Current naming revision |
|---|---|---|
| Full name | Human-centered AI Readiness Deployment Protocol | Human-centered AI Readiness and Decision Protocol |
| Exact protocol | 0.2-preview.1 | 0.2-preview.2 |
| MCP package | 0.2.0rc7 | 0.2.0rc8 |
| Skill and contract | 0.2.0-rc.7 | 0.2.0-rc.8 |
| Optional companion | 0.1.0-preview.1 | 0.1.0-preview.2 |
Six gates, fifteen criteria, risk depth, formulas and evidence requirements are unchanged. Decision still means a bounded engineering recommendation, not operational approval. New runs record the new exact versions; old runs are not automatically relabeled. Existing package names, commands, ai-ready invocation and API identifiers remain supported. No new pilot, endorsement or empirical result is claimed.
Read the naming migration notes, change manifest and preserved first-preview package. C30 records the acceptance checks. The historical rc.3 DOI does not identify either 0.2 preview.
September 24, 2026: HARD Protocol 0.2 Public Preview
The project now uses the short name HARD Protocol and the full name Human-centered AI Readiness Deployment Protocol. The public version is 0.2, with Public Preview shown separately. This is a naming and presentation change, not deployment approval or new empirical evidence.
| Identity | Previous release | Current release |
|---|---|---|
| Public name | HCAI Engineering-Handoff Profile | HARD Protocol 0.2 |
| Public status | Candidate | Public Preview |
| Exact protocol | 0.1-rc.4-candidate.6 | 0.2-preview.1 |
| MCP package | 0.2.0rc6 | 0.2.0rc7 |
| Skill and contract | 0.2.0-rc.6 | 0.2.0-rc.7 |
Six gates, fifteen criterion IDs, risk thresholds, calculations and evidence requirements are unchanged. Existing commands, API tool names, resource URIs and the ai-ready invocation remain. New runs record the new exact compatibility set; historical runs are never relabeled. The existing release gate still requires genuine bounded external use before an author can consider a finalized release.
The website address and repository stay the same. Candidate.6 and all earlier originals remain unchanged. C29 in the change manifest maps this transition to verification. The migration notes explain the public and execution versions. The historical rc.3 DOI does not identify this Public Preview.
Preserved candidate.6 package.
September 24, 2026: candidate.6 corrects the project framing
At the author's request, removed an inaccurate external accessibility-standard comparison from the current page, protocol and supporting materials. The project is an author-defined HCAI engineering-commitment review. It does not derive its authority or criteria from that comparison.
The current audit and reading copy of earlier log entries have also been corrected; frozen originals remain unchanged. The six gates, fifteen criteria, risk rules, calculations and evidence requirements are unchanged. C28 in the change manifest maps this correction to tests. No new empirical result or standard status is claimed.
Preserved candidate.5 package.
September 24, 2026: candidate.5 punctuation revision
Removed em dashes and en dashes from all current reader-facing protocol content, including numeric ranges and the current presentation of historical log entries. Ranges use the word “to”; title separators use colons. The original candidate.4 files and earlier releases remain frozen. Decision rules, values, evidence and permissions are unchanged.
The Skill now follows the same punctuation rule for its authored reports. Supplied evidence and quotations are not rewritten. Regression checks cover source documents, generated reading pages and bundled tool text. See C27 in the change manifest and the current test record.
Preserved candidate.4 package.
September 24, 2026: candidate.4 editorial revision
The current documents and public page have been edited using Academic Humanize v2.0.0. The revision replaces repeated slogans and contrast formulas with direct explanations, clarifies the cost paragraph against the existing formulas, and aligns the MCP questions, reports and Skill instructions with the revised guides.
Why rc.4 changed
This revision responds to the author's request for more natural, readable prose. It adds no practitioner feedback and changes no gate, risk threshold, required evidence or calculation. Citations, reported values, permission restrictions and research limitations remain. The release is still a candidate with no recorded external pilot.
Candidate.3 has been preserved alongside rc.3 and the earlier candidates. C26 in the change manifest records the editorial scope and integrity tests. The exact protocol and tool identities advance together so a run can identify which text and software package it used; old runs must not be relabeled.
Read the editorial review, current test record and release status. The candidate.3 package remains unchanged.
September 24, 2026: candidate.3: challenge the pass, not only improve the presentation
A deeper audit compared the candidate with the scope and evidence boundaries of NIST AI RMF, human-AI interaction guidelines and the SSDF AI profile. It also reproduced three false positives in candidate.2: an altered acceptance criterion, an unrelated proposed-state destination, and an empty action-boundary inventory could each preserve PROCEED_TO_ENGINEERING.
Why rc.4 changed
The practitioner themes remain requirements-first evaluation, traceability (Hillel Glazer, attribution approved), measured current work, realistic review burden and actual end-user use. This revision deepens those themes through reproducible software findings; it does not claim new practitioner approval or external validation.
- Validation now binds both artifact and requirement/context revisions. Retesting is required; a newly computed hash is not a new test.
- Proposed workflows need connected transitions and reachable exits. Authority limits cannot be an empty list.
- Four context questions set minimum risk depth. Self-labeling a consequential workflow “low risk” cannot bypass those floors.
- New HCAI-1.4 covers affected people, access/use, privacy/security, unequal effects and human agency. Applicable concerns require linked requirements; exceptions need justification.
- A recorded human quality review is required. Every result distinguishes structural checks, supplied human judgment, unverified authenticity and separate owner authorization.
- Pilot records preserve routing and skipped gates. A simple worksheet supports the conversation without exposing the whole schema.
- A public audit, validation roadmap and claims/change-control rules explain what would justify stronger future claims.
There are now four principles and fifteen criteria. Existing IDs are retained; C19 to C25 in the manifest map the audit changes to acceptance tests. rc.3 and both earlier candidates stay frozen. This remains a candidate with no recorded external pilot.
Read the deep audit, claims and governance, worksheet, current test record, change-to-test manifest, and release status.
Preserved candidate.2 package.
September 24, 2026: candidate.2: make the review usable and inspectable
The first candidate corrected the decision boundary but still asked too much of the reader: technical records were more developed than the actual guided experience. Its current-state summary did not require a connected step map; tests were linked to artifacts without explicitly recording the revision tested; preparation effort could remain hidden.
Why rc.4 changed
| Feedback theme | Concrete change | Evidence boundary |
|---|---|---|
| Requirements-first, risk-scaled evaluation | Requirements and acceptance criteria precede tests; risk routes before the quick review; operational deployment remains separate. | Correspondence informed design, not validation. |
| Hillel Glazer: reference material and form/fit/function traceability | Inspectable requirement/artifact/test chains, exact tested revisions, reference material, and expandable details. | Attribution approved; no endorsement implied. |
| SMB current-state and adoption | Connected current-workflow map, six plain questions, one next action, visible stops, and preparation/session time. | The 15-minute target and usability remain untested. |
| Review/correction burden | Gross and net benefit remain separate; nonpositive benefit needs an explicit investment rationale. | Scenario estimates are not measured operating performance. |
| Actual end-user discussion and use | Distinct work/discussion origins; general references do not count; a short voluntary pilot packet captures actual use and comprehension. | Outreach and interest are not pilots. |
Other correspondents' identities and comments remain private. A separate permission-controlled audit maps the original emails to these public themes.
What is new beyond the first candidate
- A one-page starting guide, role-appropriate entry points, six questions, and seven constructed scenarios.
- Four principles and fourteen stable, inspectable HCAI criteria, each with a check and pass/failure examples.
- Explicit human/agent action boundaries and labels for specified, simulated, and implemented behavior.
- A guided MCP/Skill path, private readable reports, exact-revision traceability, and revision-linked stopped runs.
- A separate reviewer-study record: requirement judgments, confidence and perceived readiness are not engineering gate results.
- Usability fields for first use, confusing questions, difficult evidence, facilitator prompts and understanding of the next action.
- Preserved rc.3 and first-candidate artifacts; no silent replacement or final-release promotion.
The guide organizes its HCAI requirements into principles, criteria and practical checks. Its organization is not certification or proof of universal usability.
What still needs evidence
Actual bounded end-user/advisor use, accessible-use testing, observed completion and preparation time, evidence-gathering burden, and whether the decision/next action is understood. Controlled effectiveness and the proposed visual-fidelity experiment require separate designs. A passing software suite cannot answer these questions.
See the test record, change-to-test manifest, and release status.
September 24, 2026: first rc.4 candidate
Introduced the current-state gate, six mandatory gates, risk-tier depth, separated review/operating costs, engineering-only decisions, permission-aware feedback, pilot contracts, and synchronized MCP/Skill logic. This was a software-tested candidate, not an empirically validated release.
Preserved first-candidate package.
Historical rc.3
Original protocol and earlier tools remain frozen. The historical DOI identifies rc.3, not any rc.4 candidate. Research Harness v3 is a separate project.