diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS new file mode 100644 index 0000000..003219d --- /dev/null +++ b/.github/CODEOWNERS @@ -0,0 +1,26 @@ +# AltmanAI organization-wide default code ownership +# +# CODEOWNERS identifies accountable reviewers. It does not replace testing, +# security review, legal review, or the explicit human authorization required +# for governance-critical changes. + +# Default accountable owner +* @altmanAI + +# Organization governance and public trust controls +/GOVERNANCE.md @altmanAI +/AI_SYSTEMS_POLICY.md @altmanAI +/AI_SECURITY_STANDARD.md @altmanAI +/REPOSITORY_STANDARD.md @altmanAI +/SECURITY.md @altmanAI +/CONTRIBUTING.md @altmanAI +/CODE_OF_CONDUCT.md @altmanAI +/SUPPORT.md @altmanAI +/RELEASE_GOVERNANCE.md @altmanAI +/AI_SYSTEM_CARD_TEMPLATE.md @altmanAI + +# Shared GitHub automation, issue forms, and contribution controls +/.github/ @altmanAI + +# Public organization profile +/profile/ @altmanAI diff --git a/.github/ISSUE_TEMPLATE/ai-system-change.yml b/.github/ISSUE_TEMPLATE/ai-system-change.yml new file mode 100644 index 0000000..7e23b95 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/ai-system-change.yml @@ -0,0 +1,140 @@ +name: AI system change or evaluation +about: Propose a material change to an AI model, agent, prompt, tool, data flow, evaluation, or human-control boundary. +title: "[AI SYSTEM] " +labels: + - governance +body: + - type: markdown + attributes: + value: | + Use this form for material AI-system work. Do not include secrets, personal data, proprietary credentials, or unremediated vulnerability details. + + - type: input + id: system + attributes: + label: System or component + description: Name the affected model, agent, application, workflow, prompt, tool, API, or evaluation. + placeholder: DailyPilot planning agent + validations: + required: true + + - type: dropdown + id: lifecycle + attributes: + label: Current lifecycle status + options: + - Proposed + - Experimental + - Internal testing + - Beta + - Production + - Deprecated + - Archived + validations: + required: true + + - type: dropdown + id: change_class + attributes: + label: Change class + options: + - Routine and reversible + - Material capability or behavior change + - Security, privacy, or permission change + - Governance-critical change + - Regulated or high-stakes use + validations: + required: true + + - type: textarea + id: objective + attributes: + label: Authorized objective + description: State the human-defined problem, intended user value, and explicit non-goals. + placeholder: Describe the bounded objective and what this work must not do. + validations: + required: true + + - type: textarea + id: behavior + attributes: + label: Proposed behavior or capability + description: Explain what changes, what remains unchanged, and how outputs or actions will differ. + validations: + required: true + + - type: textarea + id: authority + attributes: + label: Human authority and control + description: Identify required approvals, confirmation points, override paths, appeals, escalation, and shutdown or rollback controls. + validations: + required: true + + - type: textarea + id: data + attributes: + label: Data and privacy review + description: Identify data sources, personal or sensitive data, retention, access, consent, logging, and data-minimization controls. + validations: + required: true + + - type: textarea + id: security + attributes: + label: Security and tool-use review + description: Cover permissions, credentials, external services, prompt injection, data exfiltration, unsafe tool use, supply-chain risk, and least privilege. + validations: + required: true + + - type: textarea + id: evaluation + attributes: + label: Evaluation plan and acceptance criteria + description: Define reproducible tests, baselines, failure cases, thresholds, reviewers, and evidence required before release. + validations: + required: true + + - type: textarea + id: limitations + attributes: + label: Known limitations and uncertainty + description: State unsupported use cases, likely failure modes, unresolved questions, and claims that must not be made. + validations: + required: true + + - type: textarea + id: paihi + attributes: + label: P.A.I.H.I. review + description: Address Proof, Alignment, Integrity, Humanity, and Impact. + placeholder: | + Proof: + Alignment: + Integrity: + Humanity: + Impact: + validations: + required: true + + - type: textarea + id: rollback + attributes: + label: Monitoring, incident response, and rollback + description: Explain how harmful drift, misuse, failures, or unintended impact will be detected, contained, corrected, and documented. + validations: + required: true + + - type: checkboxes + id: attestations + attributes: + label: Submission attestations + options: + - label: I have not included secrets, credentials, personal data, or private vulnerability details. + required: true + - label: Capability and readiness claims are labeled accurately and supported by evidence. + required: true + - label: Material AI assistance will be disclosed in the implementation pull request. + required: true + - label: Governance-critical work will not merge without attributable accountable-human approval. + required: true diff --git a/AI_SYSTEM_CARD_TEMPLATE.md b/AI_SYSTEM_CARD_TEMPLATE.md new file mode 100644 index 0000000..a9b874e --- /dev/null +++ b/AI_SYSTEM_CARD_TEMPLATE.md @@ -0,0 +1,170 @@ +# AltmanAI AI System Card + +> Use this template for models, agents, AI-assisted features, automated decision workflows, and systems that can invoke tools or affect users. Replace all instructional text before release. + +## 1. System identity + +- **System name:** +- **Repository or product:** +- **Version:** +- **Lifecycle status:** Proposed / Experimental / Internal / Beta / Production / Deprecated / Archived +- **Accountable human owner:** +- **Technical owner:** +- **Last reviewed:** +- **Next required review:** + +## 2. Authorized purpose + +### Intended objective + +Describe the human-authorized problem this system addresses and the useful outcome it is designed to produce. + +### Intended users + +Identify users, operators, reviewers, and affected stakeholders. + +### Explicit non-goals + +State what the system is not designed, authorized, or validated to do. + +### Prohibited uses + +List disallowed domains, decisions, actions, data uses, or deployment contexts. + +## 3. System description + +- **Models or providers used:** +- **Prompts, policies, or routing logic:** +- **Tools and external services:** +- **Human inputs and approvals:** +- **Outputs and actions:** +- **Persistence, memory, or state:** +- **Deployment environment:** + +Include a data-flow or architecture diagram when the system is material, multi-component, tool-using, or production-facing. + +## 4. Capability boundaries + +### Supported capabilities + +List only capabilities supported by reproducible evidence. + +### Unsupported capabilities + +Identify functions the system may appear able to perform but is not authorized, reliable, or validated to perform. + +### Known limitations + +Describe uncertainty, hallucination risk, non-determinism, coverage gaps, language or accessibility limitations, model/provider dependencies, and foreseeable failure modes. + +## 5. Human authority and recourse + +- **Who defines objectives?** +- **Who can authorize consequential actions?** +- **What requires confirmation before execution?** +- **How can a user challenge, correct, or appeal an output?** +- **How can an operator pause, disable, or roll back the system?** +- **What decisions must never be delegated solely to the AI system?** + +Meaningful human control must be operational, not ceremonial. Reviewers must have sufficient information, time, authority, and practical ability to intervene. + +## 6. Data governance and privacy + +- **Data sources:** +- **Personal or sensitive data involved:** +- **Legal or consent basis where applicable:** +- **Data minimization controls:** +- **Retention and deletion:** +- **Access controls:** +- **Logging and observability:** +- **Training or provider data-use settings:** +- **Cross-border or third-party processing:** + +Do not include secrets, credentials, private personal data, or exploit details in a public system card. + +## 7. Security and misuse resistance + +Address, where applicable: + +- least-privilege permissions; +- credential and secret handling; +- prompt injection and indirect prompt injection; +- data exfiltration; +- unsafe or unauthorized tool invocation; +- identity, authentication, and authorization failures; +- dependency and supply-chain risk; +- malicious inputs and adversarial use; +- rate limits, abuse controls, and anomaly detection; +- sandboxing, isolation, and environment boundaries; +- incident response and kill-switch procedures. + +## 8. Evaluation record + +### Evaluation objectives + +Define the claims being tested and why they matter. + +### Test sets and scenarios + +Document representative, edge-case, adversarial, accessibility, privacy, and failure-recovery tests. + +### Baselines and thresholds + +State comparison baselines, acceptance thresholds, and release-blocking conditions. + +### Results + +Provide dated, versioned, reproducible evidence. Distinguish measured results from estimates or qualitative judgment. + +### Independent or human review + +Identify reviewers, review scope, unresolved disagreements, and any domain-specific expertise required. + +## 9. Human-impact review + +Consider: + +- dignity and respectful treatment; +- autonomy and informed choice; +- accessibility and inclusive use; +- privacy and contextual integrity; +- fairness and disparate impact; +- overreliance, dependency, and deskilling; +- emotional or psychological effects; +- recourse and error correction; +- effects on workers, communities, and vulnerable users. + +## 10. P.A.I.H.I. assessment + +- **Proof:** What evidence supports the system's claims and release status? +- **Alignment:** How does the system match the authorized objective and AltmanAI mission? +- **Integrity:** What uncertainty, limitations, assistance, conflicts, or unresolved risks are disclosed? +- **Humanity:** How are dignity, agency, privacy, accessibility, safety, and meaningful review preserved? +- **Impact:** What useful outcome occurred or is expected, and how will it be measured? + +## 11. Monitoring and change control + +- **Operational metrics:** +- **Safety and quality indicators:** +- **Drift detection:** +- **User feedback and complaint channels:** +- **Incident thresholds:** +- **Review cadence:** +- **Material-change triggers:** +- **Rollback procedure:** + +A material change to the model, provider, prompt architecture, data flow, permissions, tools, intended use, or risk profile requires renewed review. + +## 12. Release decision + +- **Decision class:** Routine / Material / Governance-critical / Regulated or high-stakes +- **Release decision:** Approved / Conditionally approved / Rejected / Retired +- **Conditions or restrictions:** +- **Accountable approver:** +- **Approval date:** +- **Authorization record or Master Ledger reference:** +- **Rollback owner:** + +### AI assistance disclosure + +Identify material AI assistance used to design, implement, test, document, or review this system. Human reviewers remain accountable for verification and release decisions. diff --git a/RELEASE_GOVERNANCE.md b/RELEASE_GOVERNANCE.md new file mode 100644 index 0000000..0915e2c --- /dev/null +++ b/RELEASE_GOVERNANCE.md @@ -0,0 +1,229 @@ +# AltmanAI Release Governance Standard + +## Purpose + +This standard defines the minimum evidence, review, authorization, and rollback requirements for releasing AltmanAI software, AI systems, documentation, standards, datasets, models, agents, and public claims. + +The objective is not to eliminate all risk. It is to make release decisions deliberate, evidence-based, reversible where possible, and accountable to an identifiable human owner. + +## Core rule + +> No material release is complete merely because code was merged or deployed. + +A release is complete only when its status, evidence, limitations, ownership, monitoring, and rollback path are documented accurately. + +## Release classes + +### Class 0 — Documentation-only routine change + +Examples: + +- typo corrections; +- broken-link repairs; +- non-substantive formatting; +- clarification that does not alter policy, capability, or obligations. + +Minimum gate: + +- focused review; +- link and accuracy check; +- no unsupported claims; +- no sensitive information introduced. + +### Class 1 — Routine and reversible software change + +Examples: + +- low-risk maintenance; +- internal refactoring with no intended behavior change; +- minor user-interface adjustment; +- dependency update with understood impact. + +Minimum gate: + +- tests or reproducible validation; +- compatibility review; +- security and privacy consideration; +- documented rollback path; +- changelog or release-note update where user-visible. + +### Class 2 — Material capability or behavior change + +Examples: + +- new product capability; +- material algorithm, prompt, model, provider, routing, memory, or data-flow change; +- new external integration; +- change to user-facing outputs or recommendations; +- new automation or tool invocation. + +Minimum gate: + +- linked issue or authorized objective; +- AI System Card or equivalent system documentation where applicable; +- evaluation plan and recorded results; +- human-impact, security, and privacy review; +- known limitations and prohibited uses; +- monitoring and rollback plan; +- accountable-human approval. + +### Class 3 — Governance-critical, high-impact, or difficult-to-reverse change + +Examples: + +- changes to governance, ownership, authorization, security, privacy, or public accountability controls; +- access to sensitive data or privileged tools; +- consequential recommendations or actions affecting rights, safety, employment, education, health, finance, housing, legal matters, or essential services; +- production deployment with broad user or organizational impact; +- material public claims about safety, performance, adoption, partnerships, certification, funding, or compliance. + +Minimum gate: + +- all Class 2 requirements; +- explicit decision record; +- named accountable approver; +- independent or domain-qualified review where necessary; +- abuse, misuse, adversarial, and failure-recovery testing; +- incident-response ownership and escalation path; +- staged rollout or justified exception; +- explicit authorization record, including **All Clear for Impact** when required by governance policy. + +## Universal release gates + +Every release must answer the following questions proportionately to its risk: + +1. **Objective** — What human-authorized problem does this release solve? +2. **Evidence** — What tests, demonstrations, sources, evaluations, or review artifacts support it? +3. **Status** — Is it proposed, experimental, beta, production, deprecated, or archived? +4. **Limitations** — What does it not do reliably or safely? +5. **Security** — What new permissions, dependencies, attack surfaces, credentials, or tool-use risks exist? +6. **Privacy** — What data is collected, processed, retained, shared, or exposed? +7. **Human authority** — What requires human approval, override, correction, or appeal? +8. **Impact** — Who benefits, who may be affected, and what negative effects are plausible? +9. **Monitoring** — How will failures, misuse, drift, or unintended effects be detected? +10. **Rollback** — How can the release be disabled, reverted, contained, or corrected? +11. **Ownership** — Who is accountable after release? +12. **Communication** — Are public claims accurate, scoped, and supported? + +## AI-system release requirements + +A model, agent, AI-assisted feature, or automated workflow must not be promoted to production status solely because it performs well in a demonstration. + +Before production release, document where applicable: + +- model and provider identity; +- prompts, policies, routing, tools, and memory architecture; +- intended users and prohibited uses; +- capability boundaries and unsupported functions; +- data sources, retention, access, and provider data-use settings; +- permission and least-privilege boundaries; +- prompt-injection, exfiltration, unsafe-tool-use, and abuse testing; +- representative, edge-case, adversarial, accessibility, and recovery evaluations; +- human confirmation points, overrides, appeals, and shutdown controls; +- monitoring, incident thresholds, and rollback ownership; +- material AI assistance used in development and review. + +Use `AI_SYSTEM_CARD_TEMPLATE.md` as the default documentation structure. + +## Evidence quality + +Acceptable evidence may include: + +- automated tests; +- reproducible manual test procedures; +- evaluation datasets and versioned results; +- screenshots or demonstrations tied to a version; +- security review notes; +- architecture and data-flow diagrams; +- accessibility checks; +- incident simulations; +- dependency and license review; +- citations to authoritative sources; +- dated decision records. + +Marketing language, intuition, an isolated successful run, or an AI-generated assertion is not sufficient evidence by itself. + +## Required release record + +Each material release should record: + +- release name and version; +- date and repository commit or tag; +- release class; +- accountable owner and approver; +- linked issue, pull request, and decision record; +- validation summary; +- known limitations; +- security and privacy impact; +- monitoring and rollback plan; +- user-facing changes; +- unresolved risks or follow-up work; +- P.A.I.H.I. assessment or reference. + +## Staged release + +Prefer staged deployment for material or high-risk releases: + +1. local or isolated validation; +2. internal testing; +3. limited beta or controlled cohort; +4. monitored expansion; +5. general availability only after evidence supports expansion. + +Skipping stages requires a documented rationale and accountable approval. + +## Release blocking conditions + +A release must be blocked when: + +- critical evidence is missing or cannot be reproduced; +- capability or readiness claims are materially unsupported; +- secrets, credentials, private data, or unlicensed material are exposed; +- a known critical vulnerability is unresolved without an approved containment plan; +- required human approval or domain review is absent; +- rollback or containment is not feasible and the residual risk is unjustified; +- legal, privacy, security, accessibility, or licensing obligations are unresolved; +- the system's actual behavior conflicts with its authorized purpose; +- important limitations are concealed or misrepresented. + +## Emergency changes + +Emergency remediation may use an abbreviated process only when delay would create greater harm. + +The accountable owner must still: + +- define the emergency and scope; +- minimize the change; +- preserve evidence; +- validate the containment or fix; +- document temporary exceptions; +- conduct retrospective review promptly; +- complete missing release records after stabilization. + +Emergency status is not a permanent exemption from governance. + +## Deprecation and retirement + +A deprecated or retired system should document: + +- reason for deprecation; +- replacement or migration path, if any; +- user communication; +- data retention or deletion consequences; +- shutdown date; +- residual dependencies; +- archival and accountability records. + +## P.A.I.H.I. release review + +- **Proof** — Is the release supported by reproducible evidence? +- **Alignment** — Does it match the authorized objective and repository purpose? +- **Integrity** — Are status, uncertainty, limitations, assistance, and unresolved risks represented honestly? +- **Humanity** — Are dignity, agency, privacy, accessibility, safety, and meaningful recourse preserved? +- **Impact** — What useful outcome is expected, and how will positive and negative effects be observed? + +## Accountability + +AI systems may assist with implementation, testing, analysis, documentation, and review. They do not independently authorize releases or assume corporate accountability. + +The named human approver remains responsible for ensuring that the release record is accurate and that required expertise, evidence, and controls are present.