HAIO · Human + AI Orchestration
Capability Graph — revelation, not ranking
A Capability Graph tells the person you serve what the product will do for them and where they keep control: which data signals feed decisions, what decision paths are possible, and how to stop or approve each action.
What a Capability Graph is
A Capability Graph tells the person you serve what the product will do for them and where they keep control: which data signals feed decisions, what decision paths are possible, and how to stop or approve each action.
- A Capability Graph maps capabilities, data signals, decision paths, and guardrails tied to verifiable evidence.
- Each capability is a node that links to the raw signals it depends on, the decision logic or model step that acts on those signals, the audit evidence that demonstrates the action occurred, and the policy or guardrail that limits or guides that action.
Design principle: present evidence, not ranking
This is not a scoring or ranking system. Presentations should avoid any ordering that implies competition or leaderboards.
- The graph should present evidence and explanation rather than ranking or scoring.
- The graph shows evidence and explanation for each node: what triggered it, what proof exists, and who consented to make it visible.
Consent as a first-class node
Every time the graph shows data flow or a decision path, it also shows a consent node where consent was requested, granted, or revoked.
- Consent must be represented as a node with timestamped records and controls for grant and revocation.
- Consent nodes record timestamped evidence, a short human-readable explanation, and the controls the person you serve can use to change that consent.
- Showing consent next to the capability makes control discoverable, not hidden.
Evidence and auditability
Attach verifiable evidence to nodes so people can inspect what happened and how it was verified.
- Evidence can be tied to cryptographic verification or tamper-evident logs to support auditability.
flowchart LR
A[Demonstrated action] --> B[Cryptographic verification]
B --> C[Capability node]
C --> D{Consent-gated visibility}
D -->|consent present| E[Visible to requester]
D -->|consent denied| F[Hidden / logged-only]
How to read one
Scan the graph to understand capabilities, their evidence, and the consent controls exposed.
- Scan for capability names.
- Open the evidence link and check the verification method.
- Look for the consent node and the controls it exposes.
- If HUMΛN review is required, the graph marks that step and links the review record.
What to do next
Start with a single capability page that documents the signals, the decision path, the evidence you will collect, and the exact consent controls exposed to people you serve.
- Replace opaque promises with links to verifiable evidence and clear consent points.
Build with HUMΛN
Builders