Protocol update log
Last updated: September 24, 2026. Current: 0.1-rc.4-candidate.5. MCP 0.2.0rc5; ai-ready Skill/contract 0.2.0-rc.5.
This is a public record of changes, not a validation claim. Earlier versions remain available. No completed external pilot, adoption, endorsement, or performance improvement is claimed.
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 structure and evidence boundaries of WCAG, 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 criteria structure takes inspiration from WCAG's principles/criteria/techniques hierarchy. It is not a W3C standard, accessibility 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.