Know what your AI can do. Prove what matters.
Explore how HAIEC helps enterprises discover consequential AI capabilities, evaluate authority and security evidence, govern deployment decisions, monitor changes and verify outcomes. Follow the diagrams to see what can be established, what still needs proof and who makes the next decision.
An executive guide, eight architecture views, two evidence cases and a practical starting path. Choose a view, then select any element for its purpose, business value and evidence limits.
Use the reader paths or tabs. No diagram represents a required enterprise onboarding sequence.
Select any card for its value, method and limitations. Unknown or unassessed never means safe.
Manufacturing uses synthetic source records; telecom is an archived workshop case. Target enforcement needs a real connected control and receipt.
HAIEC helps connect an AI system’s possible business impact, approved authority, qualified checks and accountable next action—without hiding what remains unknown.
Start with your AI system, your goal, or the evidence you already have. Each HAIEC capability works independently with the information it actually needs.
HAIEC connects to existing engineering and security systems, checks the origin and coverage of evidence, and supports independent assurance, governance and operational workflows.
Inspect a conceptual agent-to-consequence path. HAIEC keeps different kinds of proof separate, and identifies exactly where evidence stops before anyone makes a consequential decision.
Connect specialist security producers to precise evidence and controls. A cataloged check is a possibility; a completed, qualified test is an outcome.
Security checks, assurance dispositions, human approvals and actual deployment gates are separate facts. HAIEC helps make their relationship reviewable.
Monitoring is useful only when the source, baseline and observation scope are explicit. HAIEC can connect qualified signals to review, rather than pretending silence means safety.
Four tools listed in the hypothetical baseline.
One additional tool appears in this fictional current snapshot.
Framework obligations help define what matters. HAIEC connects applicable controls to source evidence, tests, accountable decisions, and visible gaps.
HAIEC separates the authority and decision layer from the actual customer execution point. Evidence of an enforced action must come from the real target, not a dashboard indicator.
Station 217 shows a real persisted HAIEC evaluation of synthetic manufacturing evidence, with a separately simulated operating response. The distinction is part of the lesson.
Scoped archive results show how HAIEC differentiates satisfied, not-satisfied and evidence-incomplete outcomes in a telecom workshop environment.
Token bars share a 0–120,000 scale; dashed line = 60,000-token policy threshold. Both runs are historical test results, not evidence a provider blocked a request.
A scoped evaluation should be judged by qualified findings, explicit unknowns and accountable next steps—not by a requirement to find a vulnerability.
Supported with qualifying inputs: scoped source evaluation, findings, independent evidence facets and reports.
Requires explicit integration: continuous telemetry coverage, operational policy gates and native action interception.
Not implied: certified compliance, universally guaranteed AI safety, proven zero-risk operation or automatic kill-switch protection.
Each view keeps demonstrated capability, illustrative material and evidence gaps separate. Use the interactive explorer above to inspect the same content element by element.
Start with an AI system, a business decision, or evidence you already have. Six independent jobs — Discover, Evaluate, Authorize, Monitor, Protect, Verify — address AI risk without a mandatory sequence.
Does not prove: Registering a system or job is not proof that every agent, tool or effect has been discovered.
Optional source connections (code, API & MCP, runtime, identity, human evidence) cross a trust boundary that binds, admits and qualifies records before independent assurance, governance and operations lanes use them.
Does not prove: A connected source is not qualified evidence, and an assessment disposition is not target-side enforcement.
A conceptual agent-to-consequence path shows how a valid API call can still violate business authority, and how five independent evidence planes (Requested, Policy Authorized, Effectively Granted, Code Capable, Observed) plus DAI keep different kinds of proof separate.
Does not prove: The teaching example stops at the first unestablished join — a named tool is not a verified path.
Specialized producers (AI AppSec, MCP tenant isolation, authorized runtime tests, LLMVerify) only support a claim after a check is registered, applicable, qualified, executed and produces a finding.
Does not prove: Cataloged rules and framework mappings are not executed tenant evaluations or coverage guarantees.
GitHub App remote assurance, scoped IDE/MCP tools and a limited local/CI runner feed four independent release facts: scan result, assurance disposition, human review and an actual CI gate.
Does not prove: A HAIEC BLOCK is not a pipeline stop unless a customer-owned gate is explicitly configured.
Qualified telemetry, identity/tool inventory, provider usage and source health comparisons support bounded investigations — with fictional examples showing why silence is not safety.
Does not prove: Received telemetry is not proof of execution or absence of unseen actions.
Framework obligations map to applicable controls, qualified evidence, executed tests and accountable human decisions — the "control passport" anatomy shows each readiness state separately.
Does not prove: Framework mapping is not certification; a control card is not an effective control.
The governance lane (policy, guard decision, human review) is separated from the customer target lane (native PEP, dispatch, effect witness) by a protection truth ladder from NOT_WIRED to EFFECT_VERIFIED.
Does not prove: No general production target-native adapter is established; configured controls are not verified blocks.
Real persisted HAIEC evaluations over synthetic manufacturing evidence: an approved work order (WO-217-4802) diverged from the recorded target (WO-217-4803), producing an overall REVIEW finding (MFG-EFF-001). A separate browser simulation illustrates an operational response — it is not target-native enforcement.
Open Station 217 case ↗ · Judge guide ↗A participant-published archive of scoped control tests: C16 token thresholds (satisfied at 35,559; not satisfied at 106,829 against a 60,000 limit), C9 performance runs, and C7 audit coverage at 9/10 — missing evidence reported, not hidden. Not organizer certification.
Explore the evidence archive ↗