Status: assessment artifact, not a replacement for existing AI-HPP concepts
Date: 2026-06-06
Scope: active repository surface (README.md, docs/, spec/, scripts) plus preserved historical material under archive/2026-04-08/moved-to-docs/ where it clarifies intent.
This assessment uses four practical maturity states:
| Maturity | Meaning |
|---|---|
| Emerging | Concept is present, but not yet complete enough for independent implementation or audit. |
| Usable Draft | A motivated team can apply it, but canonical paths, evidence, or test obligations remain incomplete. |
| Review-Ready | Independent reviewers can trace requirements to evidence and repeat checks with limited interpretation. |
| Operational | Versioned requirements, conformance evidence, change control, certification criteria, and governance operations are integrated into one maintained lifecycle. |
The current active surface is intentionally minimal. The archived surface contains richer architecture, certification, schemas, regulator-simulation, and governance material, but the active repository does not yet declare how much of that material is canonical. Therefore, maturity ratings below distinguish between content existence and active canonical maturity.
| Category | Current maturity | Determination |
|---|---|---|
| Reference Architecture | Usable Draft | AI-HPP has a clear active flow model and a richer archived layered architecture, but canonical architectural views and implementation patterns are not yet unified. |
| Safety Standard | Usable Draft | The standard has normative safety concepts and an HUS module, but active requirements are still too compact for independent compliance interpretation across domains. |
| Certification Framework | Emerging | Certification levels and regulator-simulation artifacts exist in archive, but active certification criteria, assessor workflow, and evidence acceptance rules are not canonicalized. |
| Governance Framework | Usable Draft | Governance concepts, controls, adaptive governance, audit logging, and evidence packaging exist, but active governance lifecycle ownership and change-control rules are incomplete. |
AI-HPP currently functions as a usable draft reference architecture. The active architecture defines the primary execution path: input signal, state check, policy check, safety gates, bridge, action, and audit log. The archived reference architecture extends this into layered responsibilities from user and agent interface through safety, policy enforcement, tool authorization, execution, audit evidence, and verification outputs.
- The active architecture is intentionally simple and does not yet include the richer layered model, runtime deployment boundaries, evidence interfaces, certification outputs, or multi-agent governance surfaces.
- The repository has two architecture surfaces: active minimal docs and archived comprehensive docs. External implementers may not know which is authoritative.
- Architecture-to-control traceability is incomplete in the active surface. A reviewer cannot yet move deterministically from each architecture component to specific controls, evidence, tests, and implementation examples.
- Implementation examples exist, but they are not presented as conformance-grade reference implementations.
- Canonical architecture decision record declaring the active reference architecture and archived status.
- Component responsibility matrix for signal, state, bridge, safety gate, policy enforcement, evidence, and review outputs.
- Deployment view for single-agent, multi-agent, tool-using, and successor-system deployments.
- Threat-boundary diagram identifying trust zones, bridge boundaries, escalation points, and audit boundaries.
- Architecture-to-requirement-to-evidence traceability map.
- Minimal reference implementation profile showing required hooks without prescribing product architecture.
To reach Review-Ready maturity:
- Add a canonical architecture map that preserves the current minimal flow while referencing the archived layered architecture as historical input or informative expansion.
- Define each architecture node as an enforcement or evidence point: signal intake, state update, policy evaluation, safety gate, bridge authorization, action, and audit log.
- Publish a traceability table from architecture components to active spec sections, scripts, templates, and sample evidence.
- Add deployment profiles for low-risk assistants, tool-using agents, multi-agent systems, and high-impact systems.
- Mark examples as non-normative unless they satisfy a declared implementation profile.
AI-HPP currently functions as a usable draft safety standard. The active standard defines the core safety model, safety flow, gate outcomes, mandatory logging, and the Human Understanding Standard module. The archived standard adds broader safety and governance modules, including interpretability, zero trust, data provenance, tool execution, vulnerable groups, proportional response, adversarial robustness, graceful degradation, multi-jurisdiction operation, multi-agent behavior, and evidence vault expectations.
- The active standard is conceptually clear but sparse. It does not yet expose enough requirement identifiers, applicability rules, severity levels, test methods, or acceptance criteria for rigorous independent assessment.
- Normative vocabulary is stronger in the HUS module than in the active core safety flow and specs.
- Safety gates are listed, but per-gate required inputs, outputs, evidence fields, failure handling, and escalation criteria are not fully specified in the active surface.
- The relationship between HUS controls and existing safety gates is implied but not formally mapped.
- Domain-specific risk profiles, especially for high-impact actions, vulnerable groups, and autonomous delegation, remain mostly in archived material.
- Active requirement index with stable IDs and normative verbs.
- Applicability matrix for low-risk, commercial, high-impact, multi-agent, and successor-system contexts.
- Safety gate contract for each gate: trigger, required evidence, allowed outcomes, escalation, logging, and review expectations.
- Test procedure catalog for safety gates, semantic drift, bridge authorization, human review, and rollback.
- Failure taxonomy mapped to active requirements and incident response.
- Evidence bundle schema in the active canonical surface or a declared canonical pointer to the archived schema.
To reach Review-Ready maturity:
- Convert active safety concepts into stable, numbered requirements while preserving the simple language model.
- Add an active conformance matrix mapping each requirement to evidence, scripts, and reviewer questions.
- Define required safety gate behavior for risk tiers and bridge types.
- Map HUS metrics and thresholds to existing gates instead of creating a separate parallel safety system.
- Promote or explicitly reference archived evidence-vault and failure-taxonomy artifacts as informative or canonical.
AI-HPP currently functions as an emerging certification framework. The archived certification-level document defines Level 1 research systems, Level 2 commercial AI systems, and Level 3 critical infrastructure systems. The archived conformance levels and regulator-simulation pack provide useful evidence and audit rehearsal material. However, the active repository does not yet present certification as a maintained canonical process.
- Certification levels are archived, not active, so assessors lack an authoritative certification path.
- Level criteria do not yet include all active HUS controls, HUI levels, semantic drift thresholds, human anchoring tests, or reflexive safety obligations.
- There is no active assessor handbook, audit sampling method, evidence acceptance policy, expiration/reassessment cycle, or nonconformity handling process.
- The distinction between self-attestation, independent review, certification, and regulator simulation is not yet formalized.
- Scripts validate repository structure but do not validate certification readiness.
- Active certification model with scope declaration, level criteria, evidence requirements, and assessor roles.
- Certification crosswalk from AI-HPP requirements to HUS/HUI, evidence bundles, and regulator-simulation artifacts.
- Assessment checklist with pass/fail/conditional findings and severity grading.
- Evidence acceptance criteria: provenance, tamper evidence, redaction, retention, reproducibility, and synthetic sample handling.
- Certificate lifecycle policy: versioning, expiry, surveillance review, change-triggered reassessment, suspension, and withdrawal.
- Conformance test harness or validation script for certification packages.
To reach Usable Draft maturity:
- Move or mirror certification-level criteria into the active documentation tree without deleting archived history.
- Declare certification outputs as evidence-based assessment results, not claims of absolute safety.
- Map each certification level to active safety requirements, architecture enforcement points, HUS requirements, and evidence artifacts.
- Add a minimal assessor workflow using the existing regulator-simulation pack as an informative rehearsal package.
- Add a
certification-readinesscheck that verifies the presence of required scope, evidence, logs, and requirement mappings.
To reach Review-Ready maturity after that:
- Define independent-review criteria and conflict-of-interest rules.
- Add sample anonymized assessment reports.
- Introduce versioned certification schemas and machine-readable evidence manifests.
- Define maintenance and recertification requirements.
AI-HPP currently functions as a usable draft governance framework. The repository includes governance controls in archived form, active safety-gate concepts, HUS requirements for human objective preservation, regulator-simulation artifacts, evidence templates, and an adaptive governance annex. The framework is directionally strong but not yet unified into one active lifecycle.
- Active governance ownership, review cadence, decision rights, exception handling, and change-control mechanics are not yet fully specified.
- Archived governance artifacts include strong material, but their non-active status creates ambiguity.
- The active documents do not yet define governance interfaces between policy owners, implementers, auditors, human reviewers, and affected-party review.
- Governance loops for semantic drift, goal retention, incident learning, and reflexive successor-system control are not yet integrated into the existing safety flow.
- Public repository checks focus on structure and links rather than governance process completeness.
- Governance operating model: roles, decision rights, review cadence, escalation, exception lifecycle, and approval thresholds.
- Change-control policy for requirement changes, threshold changes, test changes, and certification interpretation changes.
- Risk register template tied to signals, state changes, bridges, safety gates, and evidence logs.
- Policy exception register and expiry process.
- Incident-to-requirement feedback process.
- HUS governance playbook for objective changes, drift thresholds, human review, successor-system limits, and affected-party impact review.
To reach Review-Ready maturity:
- Add an active governance lifecycle document that references, rather than replaces, the existing control framework and adaptive governance annex.
- Define roles for standard maintainer, implementer, auditor, human reviewer, policy owner, and affected-party advocate.
- Add change-control rules for normative text, thresholds, HUS metrics, certification criteria, and schemas.
- Connect incident handling and regulator simulation outputs to standard updates and corrective actions.
- Define governance evidence required for each risk tier and certification level.
The concepts below should be integrated as extensions of existing signals, state, bridges, safety gates, and audit logs, not as replacements for those concepts.
| Concept | Existing architectural home | Integration pattern | Evidence produced |
|---|---|---|---|
| Human Understanding Standard (HUS) | Safety standard module plus governance/conformance overlay | Keep HUS as a module that defines measurable obligations for systems representing human objectives, planning, delegating, or generating successor systems. Map HUS requirements into safety gates and certification criteria. | HUI level, test scope, objective records, HUS audit report, impact assessments, drift reports. |
| Human Anchoring | State check, policy check, and human review gate | Treat the approved human-defined objective as protected state and policy input. Before planning or bridge execution, verify that the objective representation remains anchored to the approved objective. | Human-defined objective record, objective representation, reviewer approval, anchoring test result. |
| Semantic Drift | Signal monitoring, state update, safety gates, and audit log | Treat drift as a risk signal and state-change condition. Route drift above threshold to delay, review, or block outcomes. | Semantic Drift Score, threshold decision, drift explanation, review disposition. |
| Human Goal Retention | Planning cycle state, delegation boundary, multi-agent controls, and successor-system checks | Measure whether original goals, constraints, priorities, prohibited outcomes, and affected-party assumptions remain represented across planning, delegation, and successor generation. | Human Goal Retention Score, planning-cycle trace, delegation trace, successor benchmark result. |
| Reflexive Safety | Safety gates, bridge authorization, successor-system governance, and change control | Add a reflexive safety gate for systems that can modify prompts, policies, tools, agents, or successor systems. The gate blocks authority expansion or objective mutation without explicit governance review. | Change proposal, authority-delta analysis, successor-system scope, approval record, rollback plan. |
[Input Signal]
|
v
[State Check: objective + anchoring state]
|
v
[Policy Check: AI-HPP controls + HUS applicability]
|
v
[Safety Gates]
|-- policy gate
|-- risk gate
|-- tool authorization gate
|-- human review gate
|-- semantic drift gate
|-- goal retention gate
|-- reflexive safety gate
|
v
[Bridge / Tool / Delegation / Successor-System Boundary]
|
v
[Action]
|
v
[Audit Log / Evidence Bundle / HUS Evidence]
This preserves the existing architecture: HUS concepts become specialized checks and evidence requirements inside the current flow.
HUS belongs as a standard module and conformance overlay. It should remain linked from the active standard and glossary. Its requirements should be mapped into the same gate and evidence model used by the rest of AI-HPP.
Next integration step: add an HUS-to-safety-gate traceability table showing which HUS requirements attach to policy checks, risk gates, human review gates, bridge authorization, delegation, and successor-system controls.
Human Anchoring belongs in the state check and policy check stages. The system should preserve the approved human objective as controlled state and compare each operational objective representation against it before autonomous planning, delegation, bridge execution, or successor creation.
Next integration step: define the required fields for an anchoring record: approved objective, constraints, prohibited outcomes, priority order, affected parties, success criteria, objective representation, reviewer, timestamp, and change history.
Semantic Drift belongs in signal monitoring, state transition validation, and safety gates. Drift is not a replacement for risk. It is a risk signal that determines whether the current objective representation still matches the approved human objective.
Next integration step: define active thresholds that map Semantic Drift Score bands to gate outcomes: allow, delay, review, or block.
Human Goal Retention belongs in planning-cycle state, delegation controls, multi-agent governance, and successor-system validation. It is the continuity test that asks whether the system still carries the human goal through intermediate reasoning, delegated work, and generated systems.
Next integration step: require HGRS evidence for multi-cycle plans, agent delegation, high-impact actions, and any system-generated successor workflow.
Reflexive Safety belongs in safety gates, bridge authorization, governance change control, and successor-system limits. It controls cases where the system can affect its own future behavior, authority, tools, policies, objective representations, or downstream agents.
Next integration step: add a reflexive safety gate contract with triggers such as prompt mutation, tool-scope expansion, policy change, autonomous delegation expansion, self-modification, and successor-system generation.
The integration path should not replace AI-HPP's existing model. The correct integration is:
- Signals remain the event and risk input layer.
- State remains the memory and decision-context layer.
- Bridges remain the controlled external-action layer.
- Safety gates remain the decision and escalation layer.
- Audit logs remain the accountability layer.
- HUS concepts add measurable human-objective preservation checks across those layers.
- Add a canonical-path declaration distinguishing active normative docs, informative docs, and archived historical material.
- Add a traceability matrix covering architecture component -> requirement -> gate -> evidence -> script/check.
- Promote or mirror certification levels into active docs and map them to HUS/HUI.
- Add HUS gate contracts for anchoring, semantic drift, goal retention, and reflexive safety.
- Add governance lifecycle and change-control docs that reference the archived control framework and adaptive governance annex without replacing them.
- Add reviewer checklists for reference architecture, safety standard, certification framework, and governance framework maturity.