PAW-HC 0.1People Are Worth Designing For.

The system owner MUSTdefine the human goals the system is intended to support and the people who may be affected by it.

Human-centered requirementsMUST be considered during design, development, testing, deployment, monitoring, and retirement.

Claims about human-centered performanceMUST be supported by documented evidence, testing, or traceable design rationale.

Material limitations, unresolved risks, and populations for which the system has not been adequately evaluated MUSTbe documented.

The project MUSTdocument its intended purpose, users, affected populations, operating environment, major dependencies, and known boundaries.

The project SHOULDmaintain a stakeholder map identifying direct users, affected non-users, operators, developers, maintainers, accessibility stakeholders, and relevant public-interest groups.

Evaluation MUSTaccount for realistic environments rather than only ideal laboratory conditions.

Human needs MUST be identified before finalizing major product requirements.

Projects SHOULD involve representative users and affected communities during requirements, prototype evaluation, and revision.

Users MUST have a documented mechanism to report usability, accessibility, safety, and harmful-behavior concerns.

Material feedback SHOULDbe traceable to a disposition: addressed, deferred with rationale, rejected with rationale, or under investigation.

Applicable interfaces MUSTdefine an accessibility target and the technologies and assistive technologies included in evaluation.

Automated accessibility checks MUST NOTbe the sole basis for accessibility claims.

Where relevant, evaluation SHOULDinclude actual assistive technology and users with relevant access needs.

Projects MUST consider cognitive, language, attention, memory, and executive-function barriers where relevant.

Errors, refusals, authentication failures, and recovery flows MUSTbe evaluated for accessibility.

Material functionality SHOULDremain available through more than one interaction modality where practical.

Key user tasks MUST be explicitly identified.

For key tasks, projects SHOULDmeasure completion time, errors, abandonment, recovery effort, and subjective burden.

Interfaces SHOULD expose complexity progressively rather than requiring users to understand the entire system before completing ordinary tasks.

Users SHOULD be able to recover from common errors without restarting the entire task.

The system MUST clearly identify actions it can take on a user's behalf.

Consequential actions MUSTrequire an appropriate level of human authorization unless a documented exception applies.

Users SHOULD be able to interrupt or stop ongoing autonomous actions where technically feasible.

Material actions SHOULDbe reversible where feasible.

The system MUST NOTconceal that an action was performed by AI when that fact is material to the user's decision.

A documented risk assessment MUSTexist before production deployment.

Material foreseeable failure modesMUST be identified and tested.

When the system cannot reliably complete a task, it SHOULD fail in a way that minimizes downstream harm rather than fabricating success.

Systems operating in high-impact contextsMUST apply heightened review, documentation, and human oversight.

Material uncertainty SHOULDbe communicated in a manner appropriate to the user's context.

Users MUST be informed when interacting with an AI system when that distinction could reasonably affect their decisions.

Material limitations MUSTbe documented in user-accessible language.

For agentic systems, the systemSHOULD provide an understandable record of significant actions taken.

Explanations SHOULDcommunicate relevant reasons, evidence, uncertainty, and limitations without implying certainty the system does not possess.

Projects claiming conformanceMUST maintain an evidence register mapping requirements to artifacts.

Each normative requirement MUSTbe marked implemented, not applicable with rationale, partially implemented, or not implemented.

Public Interest conformanceSHOULD be reviewed by an independent evaluator.

A self-declaration MUSTbe clearly labeled as self-declared andMUST NOT imply third-party certification.

Draft requirements SHOULDbe maintained in a public issue or discussion process.

Changes to normative requirementsSHOULD include rationale and impact analysis.

Major changes MUSTincrement the major or minor version according to documented versioning rules.

Standard maintainers SHOULDdisclose material conflicts of interest.

Governance SHOULD include participation from accessibility, HCI, security, privacy, AI engineering, and affected-user communities.

If CYN-X claims PAW-HC conformance, CYN-XMUST evaluate itself against the same requirements it publishes.

CYN-X SHOULD publish its conformance evidence, failed tests, known limitations, and remediation plans.

CYN-X SHOULD publish the methodology for human-centered benchmarks used to support PAW-HC claims.

CYN-X SHOULD invite independent developers and affected users to challenge its conformance claims.