The same fact lived in nine hand-kept places and they disagreed about 58
proposals. This makes the file the only authority and everything else a
projection of it.
ONE VOCABULARY, in vocabulary.json, read by the lint, the generator and the
doc site. Three words, each answering "can I rely on this?" and nothing else:
Draft nothing implements it yet, or its own text says the work is ahead
Final the thing it specifies exists in the code
Living governance and process: amended in place, never finished
Eight spellings folded in. `Active` was the one doing real damage: on four Meta
and Process HIPs it meant living, on 48 others it meant shipped, and one word
doing two jobs is why nothing agreed. `Review` and `Last Call` described a
queue rather than a document, and a proposal under review is still one you
cannot build against.
STATUS IS EARNED, not declared. Every Standards Track proposal was checked
against the estate: 235 have their implementation, and eight do not and say so.
HIP-0095 carries a twelve-week plan ending at "mainnet launch" and has no code.
HIP-0525 specifies an all-machine meeting while apps/meet refuses a machine a
seat. HIP-0078 names a prover at a "planned location" that does not exist.
HIP-0114 is the cog.* procedure set, and that procedure set returns nothing.
HIP-0003, HIP-0102, HIP-0305 and HIP-0901 likewise: looked, found nothing.
SIXTEEN TOMBSTONES DELETED rather than statused. A dead document kept alive in
the index is one concept wearing two names. Each successor exists and carries
the text, and the 90 references that pointed at a tombstone now point at it --
whole markdown links at once, so link text cannot outlive its target. Three of
the sixteen were pure compatibility: HIP-0028 specified a migration off a
Bitnami chart, HIP-0029 dual-engine MySQL, HIP-0030 a schema-deprecation
policy. We ship no backwards compatibility, so we do not specify it.
Nine links were already broken and had been since the corpus was renumbered:
short-form ./hip-5.md paths that never existed. Two named the wrong proposal --
one cited "HIP-1: Hanzo Multimodal Models" where multimodal is HIP-0003.
THE GENERATOR REFUSES more often than it writes, because a short table looks
exactly as authoritative as a complete one. Rows must equal files; a shrinking
index must say by how much; a section whose input is missing is an error, not
an omission; nothing is written until all of it validates. Its self-test breaks
the corpus eleven ways and requires each to refuse AND leave README byte-
identical -- a guard that reports after half-writing has protected nothing.
The lint's second implementation of the same comparison is gone.
The site rendered 52 proposals with a fallback grey badge and counted them
toward none of its three stat tiles, because docs/lib/source.ts declared a
status union by hand: it admitted a `Stagnant` no file has ever carried and
omitted the one 52 files did. Five components each kept their own copy of the
colours. All six now read vocabulary.json.
HIP-0200: Responsible AI Principles and Commitments
Abstract
This HIP establishes the foundational Responsible AI framework for Hanzo AI. It defines our commitment to building AI systems that are safe, fair, transparent, and beneficial to humanity. All other AI ethics HIPs (HIP-201 through HIP-249) and sustainability HIPs (HIP-250 through HIP-299) reference this document as the canonical source for Hanzo's responsible AI commitments.
Mission and AI Ethics Thesis
Hanzo AI is committed to democratizing access to AI while ensuring these powerful systems remain under meaningful human control. Our thesis: responsible AI is not a constraint on innovation—it is a competitive advantage that builds trust with users, partners, and regulators. We believe AI should augment human capability, not replace human agency.
Core Principles
1. Safety First
AI systems must be demonstrably safe before deployment. We prioritize:
Harm prevention: Systems must not facilitate illegal activity, violence, or self-harm
Robustness: Systems must degrade gracefully under adversarial conditions
Controllability: Humans must be able to intervene, correct, or shut down AI systems
Testing rigor: Safety evaluations must precede capability expansions
2. Fairness and Non-Discrimination
AI systems must treat all users equitably:
Bias detection: Systematic testing across demographic groups
Outcome monitoring: Tracking disparate impact in production
Remediation: Clear process for addressing discovered biases
Inclusive design: Accessibility and multilingual support
3. Transparency and Explainability
Users deserve to understand AI behavior:
Model cards: Public documentation of capabilities and limitations
Decision explanations: Interpretable outputs where feasible
Training disclosure: Clear information about data sources and methods
Uncertainty communication: Systems must express confidence levels
4. Privacy and Data Protection
User data must be protected:
Data minimization: Collect only what is necessary
Consent: Clear opt-in for data use in training
Retention limits: Delete data when no longer needed
Security: State-of-the-art protection for stored data
5. Human Oversight
AI systems must support human control:
Human-in-the-loop: Critical decisions require human approval
Escalation paths: Clear routes from AI to human support
Override capability: Users can always request human assistance
Audit trails: Complete logs of AI decisions
6. Accountability
We take responsibility for our systems:
Clear ownership: Named individuals accountable for each system
Incident response: 24/7 capability to address safety issues
External review: Regular third-party audits
Public reporting: Transparent disclosure of incidents and mitigations
Material Topics
Safety & Security
Topic
Materiality
Metrics
Jailbreak resistance
Critical
Attack success rate
Hallucination rate
High
Factual accuracy %
Harmful output
Critical
Safety filter effectiveness
System availability
High
Uptime %, MTTR
Fairness & Bias
Topic
Materiality
Metrics
Demographic bias
High
Performance parity across groups
Language bias
Medium
Quality consistency across languages
Socioeconomic bias
High
Accessibility metrics
Privacy & Data
Topic
Materiality
Metrics
Training data consent
Critical
% data with clear consent
PII handling
Critical
Incidents, exposure events
Data retention
High
Compliance rate
Environmental Impact
Topic
Materiality
Metrics
Training emissions
High
tCO2e per model
Inference efficiency
High
Tokens/kWh
Hardware lifecycle
Medium
E-waste metrics
Governance Structure
AI Ethics Board
Role
Responsibility
Chief AI Ethics Officer
Strategic direction, external representation
Model Risk Committee
Approval of high-risk deployments
Safety Team
Red-teaming, incident response
External Advisors
Independent review, academic perspective
Decision Framework
Risk Level
Examples
Approval Required
Low
Minor model updates, bug fixes
Engineering lead
Medium
New capabilities, expanded access
Model Risk Committee
High
New model families, API changes
AI Ethics Board
Critical
Safety-related changes
Board + external review
Metrics and Targets
Safety Metrics
Metric
Current
2025 Target
Measurement
Jailbreak success rate
TBD
<1%
Red team testing
Harmful output rate
TBD
<0.01%
Production monitoring
Safety incident response time
TBD
<4 hours
Incident logs
Fairness Metrics
Metric
Current
2025 Target
Measurement
Performance parity (demographic)
TBD
<5% gap
Benchmark testing
Language quality parity
TBD
<10% gap
Human evaluation
Environmental Metrics
Metric
Current
2025 Target
Measurement
Training emissions (tCO2e/model)
TBD
-30%
Carbon accounting
Inference efficiency
TBD
+50%
Performance monitoring
Verification and Assurance
Internal Testing
Pre-deployment: Full safety evaluation suite
Continuous: Production monitoring and alerting
Periodic: Quarterly red-team exercises
External Verification
Type
Frequency
Provider
Safety audit
Annual
Third-party AI safety firm
Bias audit
Annual
Academic partner
Security audit
Continuous
Bug bounty + penetration testing
Standards Alignment
NIST AI RMF: Risk management framework
ISO/IEC 42001: AI management system (target certification)
OECD AI Principles: Policy alignment
EU AI Act: Compliance preparation
Known Tradeoffs
Capability vs. Safety
Tradeoff: More capable models may be harder to control
Mitigation: Safety investment scales with capability
Disclosure: We will document capability-safety frontier
Transparency vs. Security
Tradeoff: Full transparency may enable adversarial attacks
zeekay
ad5a010f79