HAIEC Technical Reference Tables A-F

AControl catalog

45-control catalog with objectives, evidence, and availability

The complete inventory of what HAIEC's assurance program tracks. 45 control objectives across eight families, each with a documented evidence basis and a clear availability state.

Executive value

When your board or auditors ask "what are we actually assuring", this table is the answer. 45 control objectives, each with the evidence basis your security team uses to verify it, and each in one of three availability states: projection active, specialist test ready, or objective defined. Audit preparation moves from weeks to a single reference.

Source. lib/control-visibility/catalog.ts at Main, snapshot 2026-10-18. 45 total: 42 general objectives plus 3 specialist controls (C7, C9, C16). 11 with an active projection. 3 with a bounded specialist test. 15 prioritized for the launch release.

Total objectives

45

Across eight control families

Projection active

11

Live dashboard coverage

Specialist test ready

3

C7, C9, C16 bounded tests

Objective defined

34

Ready to activate with evidence

Availability states Projection active Specialist test ready Objective defined 11 projection plus 3 specialist plus 34 defined equals 45

45 shown

ID	Family	Objective	Evidence basis	Availability	Notes
TMF. Audit trail, duration, token control (specialist evaluated)
C7	TMF	Audit trail completeness	Frozen run with required event categories and policy	Specialist test ready	Bounded evaluated test with a qualified case
C9	TMF	Duration anomaly threshold	Frozen qualified timing bundle and threshold	Specialist test ready	Bounded evaluated test with a qualified case
C16	TMF	Token expenditure cap	Frozen qualified run and usage bundle with policy	Specialist test ready	Bounded evaluated test with a qualified case
G. Governance and accountability
G01	G	AI estate inventory completeness	Inventory and source discovery	Objective defined	Ready to activate with an inventory source
G02	G	Accountable ownership and responsibility	Governance records	Objective defined	Ready to activate with governance records
G03	G	AI acceptable use and approval	Approved use policy	Objective defined	Catalog entry; availability depends on evaluation and qualified evidence
G04	G	AI risk and impact assessment	Risk registry	Objective defined	Ready to activate with a risk registry
G05	G	Regulatory applicability and obligations	Framework mappings	Objective defined	Framework mapping available in Table C
G06	G	Third-party AI and vendor assurance	Vendor inventory	Objective defined	Ready to activate with a vendor inventory
G07	G	Change and lifecycle governance	Build provenance and CI	Objective defined	Ready to activate with CI evidence
S. Application security
S01	S	Privileged tool authorization paths	Static security analysis	Objective defined	Uses AI AppSec package
S02	S	Multi-tenant isolation	Tenant isolation analyzer	Objective defined	Uses the 57-rule tenant isolation package
S03	S	MCP and tool exposure	MCP and AI AppSec analysis	Objective defined	Static detection identifies candidates for runtime confirmation
S04	S	Secrets and credential protection	Static and LLM heuristics	Objective defined	Ready to activate with a source scan
S05	S	Prompt and input trust boundaries	Static and runtime probes	Objective defined	Runtime probes are opt-in
S06	S	RAG retrieval and exfiltration paths	RAG and dataflow analysis	Objective defined	Ready to activate with source and registry
S07	S	Secure AI SDLC and build provenance	CI and SARIF provenance	Objective defined	Ready to activate with CI evidence
A. Agent authority and delegation
A01	A	Excessive effective authority	Five-plane IAM and policy	Objective defined	Launch-priority set
A02	A	Undeclared executable capability	Five-plane plus static source	Projection active	Visibility plus launch-priority
A03	A	Delegated Action Integrity	DAI nine dimensions	Projection active	Visibility plus launch-priority
A04	A	Observed action outside approved policy	Qualified action witness	Projection active	Visibility plus launch-priority
A05	A	Agent and principal identity continuity	Identity continuity	Projection active	Visibility plus launch-priority
A06	A	Human approval and mediation integrity	Approval and mediation	Projection active	Visibility plus launch-priority
A07	A	Least privilege and unused grants	IAM plus capability	Objective defined	Launch-priority set
A08	A	Cross-agent delegation propagation	Delegation lineage	Projection active	Visibility plus launch-priority
R. Runtime enforcement and response
R01	R	Action lifecycle and side-effect traceability	Action lifecycle witness	Objective defined	Ready to activate with action witness evidence
R02	R	Consequential effect envelope	Effect bound comparator	Projection active	Visibility plus launch-priority
R03	R	Runtime guardrail enforcement evidence	Decision and denial witness	Projection active	Visibility plus launch-priority
R04	R	Emergency intervention effectiveness	Kill-switch witnesses	Objective defined	Activates with a native enforcement adapter
R05	R	Recovery and resumption authorization	Recovery audit	Objective defined	Ready to activate with recovery evidence
R06	R	AI incident response and recovery	Incident workflow	Objective defined	Ready to activate with incident workflow
R07	R	Continuous runtime monitoring	OTel and source continuity	Objective defined	Activates with a connected collector and cadence
L. LLM behavior and output safety
L01	L	Prompt-injection resistance under test	Runtime or LLMVerify	Objective defined	Activates with LLMVerify or an authorized probe
L02	L	Sensitive output leakage	PII and secret signals	Objective defined	Ready to activate with output evidence
L03	L	Hallucination risk and grounding	LLMVerify heuristics	Objective defined	Ready to activate with LLMVerify
L04	L	Unsafe output risk	LLM risk indicator	Objective defined	Ready to activate with output evidence
L05	L	Structured output and consistency	Schema and consistency checks	Objective defined	Ready to activate with schema evidence
E. Evidence integrity and verification
E01	E	Evidence integrity and provenance	Evidence Core	Projection active	Visibility plus launch-priority
E02	E	Event stream coverage and continuity	OTel continuity	Objective defined	Activates with connected telemetry
E03	E	Source authority and plane correlation	Environment binder	Projection active	Visibility plus launch-priority
E04	E	Contradiction and source reconciliation	Evidence projections	Objective defined	Ready to activate with multiple source planes
E05	E	Independent deterministic replay	Replay manifest	Projection active	Visibility plus launch-priority
P. People, transparency and data governance
P01	P	Bias and fairness evaluation coverage	Bias testing	Objective defined	Ready to activate with bias test evidence
P02	P	Transparency and explainability	Documentation review	Objective defined	Ready to activate with documentation
P03	P	Training data governance and lineage	ISAF lineage	Objective defined	ISAF v1 published, v2 in research

The full scope of the program.

45 objectives form the documented scope of the assurance program.
Each objective's availability depends on the evidence and configuration your environment supplies.
11 projection-active objectives give your team immediate dashboard visibility on day one.
15 launch-priority objectives are prioritized for the launch release.
The 221-question Agent Audit catalog is a complementary artifact for interviews and workshops, used alongside these 45 objectives.

BDetection families

176 detection rules across 31 families

HAIEC's detection depth, documented family by family. 157 rule registrations identify executable producers across 31 families; 19 registrations are held. Actual execution requires qualifying source inputs and tenant readiness.

Executive value

Procurement and security teams can quantify what the product detects on day one. 157 producer-backed rule registrations across 31 families, not 157 checks proven to run in a specific tenant or assessment. The 19 reserved rules are documented openly so buyers can see the roadmap and plan integrations. Every family lists the exact source data required, so evidence strategy is planned with real numbers.

Source. lib/ai-security/risk-registry/detection-rule-catalog.ts, snapshot 2026-10-17. 176 total rules across 31 families: 157 with a registered producer, 19 reserved for a future release.

Total rules

176

Across 31 families

Executable today

157

Live detection at activation

Reserved rules

19

Documented roadmap

Reserved families

4

CERT, TIME, CICD, AI_AGENT (partial)

19 rules across 4 families are reserved for a future release. CERT (5), TIME (5), CICD (5), and 4 of 10 in AI_AGENT. Each is documented here so buyers see the roadmap clearly. Activation requires a specific evidence producer, which is documented per family below.

31 shown

Family	Executable	Reserved	Total	Source data required	Status
K8S	7	0	7	Kubernetes pod spec, RBAC bindings, manifests, audit log	Executable
API_AUTH	6	0	6	API access logs, gateway logs	Executable
DNS	5	0	5	DNS logs, DNS zone data	Executable
CERT	0	5	5	TLS inspection, CRL and OCSP	Reserved
TIME	0	5	5	NTP config, time sync telemetry, event timestamps	Reserved
MSG_BUS	6	0	6	Message bus logs, metrics, schema registry, queue metrics	Executable
SECRETS	5	0	5	Static source scan, repo file inventory, log inspection, secret metadata	Executable
CONFIG_DRIFT	4	0	4	Config history, config versus runtime read, flag audit log	Executable
DATA_ACCESS	5	0	5	Data access logs, query telemetry, export logs	Executable
AI_AGENT	6	4	10	Agent runtime telemetry, tool-call telemetry, memory access logs, delegation records	Partially reserved
SUPPLY_CHAIN	8	0	8	Lockfile and SBOM diff, SBOM versus vulnerability feed, build provenance	Executable
CICD	0	5	5	Pipeline config history, run logs, audit logs, deploy records	Reserved
PROMPT	5	0	5	GenAI prompt events with gen_ai.* attributes, turn position, context size	Executable
RAG	4	0	4	Retrieval events, chunk text, embedding signature, session ids and declared registry	Executable
MEMORY	2	0	2	Memory operations with declared channel and scope list	Executable
MULTI_AGENT	4	0	4	Agent handoff records per session with declared handoff and registration flags	Executable
MCP_TOOL	4	0	4	Agent tool calls with declared tool, server, agent registry and schemas	Executable
EXFIL	4	0	4	Agent output events, tool payloads with signature and egress allowlist	Executable
COST	4	0	4	Agent usage metrics with baselines, handoff records, declared surfaces	Executable
AGENT_AUTH	3	0	3	Delegation records versus declared chains and scopes, tool calls versus chains	Executable
RAPP_A1	5	0	5	A1 policy events with approved baseline, app registry, distributions and threshold	Executable
SBI	8	0	8	SBI call events with NF profiles, baseline flows, message validation, registration registry	Executable
SLICE	6	0	6	Slice traffic events, attachment events with RAN subnets, usage metrics and quota, SLA	Executable
AML	10	0	10	ML inference records with approved version and hash, drift baseline, variance, OOD scores	Executable
DELEGATION	8	0	8	Delegation chain events with declared scopes and actions, response text, token claims	Executable
IDENTITY	10	0	10	Identity records with agent registry, client mapping, SPIFFE, chain state, attestation	Executable
TOWER	5	0	5	Handover records with declared cell scope, chain baseline, session window, topology	Executable
RAPP_SC	5	0	5	Onboarding manifest with artifact hash, pipeline signature, SBOM manifest, runtime integrity	Executable
RAPP_EX	4	0	4	Egress metrics with baseline, egress logs with allowlist, query logs with declared selection, access-control logs	Executable
RAPP_LM	4	0	4	Service-mesh logs with baseline peers, identity logs with credential ids, network flow logs, runtime authorization	Executable
MANUFACTURING	10	0	10	Scenario-phase records, pinned static capability with approved policy, observed dispatch with native readback, collector continuity	Executable

Each count describes a different category.

176 detection rules, 45 control objectives, 26 intake profiles, 11 projection-active controls, 15 launch-priority controls, and 221 audit questions are six separate denominators. Each describes a different part of the platform.
Separate security packages: AI AppSec (122 detectors, 79 checks), MCP tenant isolation (57 rules), and LLMVerify (38 rules) are their own products. They are documented separately from the 176-rule core registry.
Refer to Table C for the OWASP crosswalk that maps these families to the threats your board and auditors recognize.

CFramework crosswalks

Framework crosswalks by implementation state

How HAIEC's technical evidence connects to the frameworks your board, auditors, and regulators care about. Every framework your team cites is mapped here, with the specific HAIEC mechanism addressing each row.

Executive value

When a CISO answers "is this aligned to NIST" or "how do we evidence OWASP coverage", this table provides the answer in one click. Every row shows the specific HAIEC mechanism, the evidence it produces, and the honest alignment state. External reviewers confirm final alignment. HAIEC produces the evidence basis that makes that review fast.

Sources. OWASP LLM Top 10 (2026; current edition published Aug 4) and OWASP Agentic Top 10 (2026). MITRE ATLAS. HAIEC capability matrix, detection registry, control catalog, and evidence intake matrix.

How to read these tables. Each row names a specific HAIEC mechanism and the alignment state of that mapping. Alignment available: HAIEC produces technical evidence your reviewer can cite. Partial alignment: some scope is covered, some requires additional evidence. Reserved: the framework is recognized and mapping is planned. An external reviewer or auditor confirms final alignment. HAIEC provides the evidence basis that makes the review defensible and fast.

OWASP LLM Top 10 2026 update. The 2026 release (Aug 4, 2026) renumbered categories. Excessive Agency moved from LLM06 in 2025 to LLM03 in 2026. The table below uses the official 2026 numbering and categories. These are possible evidence contributions, not claims that HAIEC tests every risk or proves mitigation.

C1. OWASP LLM Top 10 (2026)

ID	Threat	HAIEC mechanism	Alignment	Additional evidence for full coverage
LLM01	Prompt Injection	Selected static checks and consented probes	Opt-in / source-dependent	Requires exact test scope and qualified input-output evidence.
LLM02	Sensitive Information Disclosure	Sensitive-output or data-exposure signals	Evidence-dependent	A content pattern flag alone does not establish a breach.
LLM03	Excessive Agency	Five evidence planes and DAI authority comparison	Evidence-dependent	Requires approved policy, relevant grant or execution witnesses.
LLM04	Supply Chain	Repository, dependency and SBOM provenance	Partial	Manifest presence does not prove runtime component loading.
LLM05	Data and Model Poisoning	Training/source provenance and poison-test producers	Not established	Do not claim an executable poison detector without source proof.
LLM06	Unbounded Consumption	Qualified usage telemetry, caps and comparisons	Evidence-dependent	Threshold breach is not proof that a provider denied a request.
LLM07	Misinformation	Grounding or response-quality indicators in specialized workflows	Partial	No guarantee of factual correctness; separate LLMVerify status.
LLM08	Hidden Context Exposure	Scoped prompt/output/context checks	Partial	Must distinguish disclosure, attempted extraction and actual exposure.
LLM09	Vector and Embedding Weaknesses	RAG analysis and qualified retrieval evidence	Partial	Instrumented retrieval needed for observed behavior.
LLM10	Improper Output Handling	AI AppSec static sink and unsafe-execution checks	Evidence-dependent	Code-capable sinks do not establish actual execution.

C2. OWASP Agentic Top 10 (2026)

ID	Threat	HAIEC mechanism	Alignment	Additional evidence for full coverage
ASI01	Agent Goal Hijack	Runtime probes plus static prompt-injection rules	Alignment available	Coverage is bounded by the test scope you authorize.
ASI02	Tool Misuse and Exploitation	MCP package (57 rules) plus reachability plus DAI	Alignment available	Static detection identifies candidates that runtime evidence confirms.
ASI03	Identity and Privilege Abuse	Five-plane comparison plus IAM observation	Alignment available	Per-action grant truth is partial until session context resolves.
ASI04	Agentic Supply Chain	Repo lockfile plus CycloneDX SBOM plus build provenance	Partial alignment	Covers a focused subset of the agentic supply chain surface.
ASI05	Unexpected Code Execution	Reachability analysis plus tool-call sinks	Alignment available	Reachable identifies the path. Runtime evidence confirms exercise.
ASI06	Memory and Context Poisoning	Memory rules plus bounded adversarial probes	Partial alignment	Requires instrumented memory telemetry for full coverage.
ASI07	Inter-Agent Communications	DAI nine dimensions plus handoff observation	Alignment available	Cross-system verification is planned for a future release.
ASI08	Cascading Failures	Drift signals plus operational scope checks	Partial alignment	Requires a qualified monitoring source for full signal.
ASI09	Human Trust Manipulation	Output checks plus PII and unsafe output patterns	Partial alignment	Pattern-based identification. Additional depth with semantic review.
ASI10	Overreliance and Rogue Behavior	Scope checks plus boundary comparison	Partial alignment	Depends on runtime evidence from connected sources.

C3. Governance and privacy frameworks

Framework	HAIEC evidence contribution	Alignment	Who confirms final alignment
ISO/IEC 42001	AI management system evidence: control mapping, decision records, evidence provenance, change history	Supporting evidence	Your auditor confirms management-system alignment
ISO/IEC 27001	AI-specific information security control evidence: authorization, monitoring, incident records	Supporting evidence	Your ISMS auditor confirms alignment
NIST AI RMF	Govern, Map, Measure, Manage evidence artifacts plus Measure 2.6 monitoring evidence	Supporting evidence	Your risk team confirms framework alignment
NIST CSF	Identify, Protect, Detect, Respond, Recover evidence for AI systems	Supporting evidence	Your security team confirms maturity alignment
SOC 2	CC-series evidence where AI systems affect trust services criteria	Framework mapped	Your auditor produces the SOC 2 attestation
EU AI Act	Applicability context for high-risk classification plus documentation evidence	Context reference	Legal counsel confirms applicability
GDPR	Privacy-control evidence for AI actions touching personal data	Supporting evidence	Your DPO confirms legal alignment
HIPAA	Privacy and security control evidence for AI actions touching health data	Supporting evidence	Your compliance officer confirms alignment
NYC Local Law 144	Specialized hiring-regulation workflow evidence where applicable	Workflow available	Confirms alignment only for automated employment decision tools in NYC
MITRE ATLAS	Threat taxonomy reference for adversarial AI techniques	Taxonomy reference	Provides threat framing for internal review

How alignment and certification differ.

HAIEC produces the technical evidence artifacts relevant to each framework's obligations.
An external reviewer or auditor makes the certification or attestation decision. HAIEC provides the evidence basis that makes their review fast and defensible.
Framework alignment describes the technical state. Compliance certification is a separate external process.
Applicability, implementation, evidence, and attestation are four separate stages. Each is valuable on its own. HAIEC accelerates the evidence stage so the attestation stage runs cleanly.

DIntegration schema

Integration matrix: paths, states, and evidence value

Inspected intake paths, their stated readiness and the evidence conditions that must still be verified for each tenant. Integration teams use this table to plan their evidence strategy. Procurement uses it to understand exactly what each path provides.

Executive value

Integration teams can compare the documented paths and prerequisites before committing to an onboarding plan. Every path shows its readiness, the auth it requires, and the evidence value it delivers. Procurement should verify each listed path against current tenant readiness, permission scopes and supported integrations.

Sources. lib/developer-integration-source-status.ts, lib/evidence/adapters/intake-profiles.ts, app/api route handlers at Main, snapshot 2026-10-18.

Three stages per path. Receipt confirms the payload reached HAIEC. Qualification authenticates the source and validates it against a registered binder. Evaluation runs the detector against qualified evidence. Only qualified and evaluated evidence feeds an Assurance result. This staging keeps the assurance chain defensible at every step.

11 paths shown

Path	State	Auth and scope	Establishes	Extend with additional evidence
GitHub App	Ready today	Authorized GitHub App installation and repository grants; use the current App permission manifest.	Full static analysis on authorized repos, PR findings, and qualified scan evidence.	Runtime observations, effective IAM, and target effect come from additional sources.
CI Action (v2)	Release pending	Pending reconciliation of the distributable action identity. The v1 PAT flow is deprecated.	PR diff and scan results when v2 releases.	The GitHub App path provides CI-adjacent analysis today.
Local source ZIP or tar.gz	Preview / enterprise POC	Scoped credential and qualified local evidence submission; check current tenant/tool availability.	Bounded static analysis within the bundle, with qualified scan evidence.	Full static depth requires the complete source tree in the bundle.
Structured ingest API	Ready today	Authenticated, source-bound evidence binder with the route-specific ingest permission.	Typed evidence events mapped to a registered binder with full provenance.	Unrecognized files stay as evidence-only records. A registered binder extends coverage.
SARIF import	Ready today	Authorized import route and scan-evidence scope; verify the current API contract.	Third-party scan findings with tool identity preserved.	Imported findings remain as imported. HAIEC-verified findings come from HAIEC analyzers.
CycloneDX SBOM	Ready today	Authenticated, source-bound evidence binder with the route-specific ingest permission.	Supply-chain context: dependency drift and known CVE mapping.	Accepts JSON 1.4 to 1.6. XML, SPDX, VEX, and CSAF route through a separate intake path.
OTLP receiver	Ready today	Bearer token with `write:ingest` scope plus recognized span attributes.	Traces with gen_ai., mcp., and haiec.* attributes feed agent rules and observed-action evidence.	Trace provides observation. Effect confirmation comes from an independent target readback.
MCP surface	Ready today	Tenant-bound HAIEC API key with exact read or write scopes for each registered MCP tool.	Read access to systems, cases and receipts; separately authorized scoped submission and configuration operations are also supported.	Not every sensitive action is exposed to MCP. Respect per-tool scope, user confirmation and browser-only approval boundaries.
AWS IAM observer (live)	Evidence-dependent	Bound AWS credential plus `read:systems` scope.	Candidate grants observed with partial effective-permission context.	SCP, resource policies, and session boundaries require additional policy intake for full resolution.
IAM JSON export	Ready today	Authenticated, source-bound evidence binder with the route-specific ingest permission.	Declared policy contents and conditions mapped to the five-plane comparison.	Effective grant state extends with a live IAM observer connected to the same system.
Runtime endpoint test	Available with authorized consent	Authorized endpoint plus operator consent, with scope pre-declared.	Empirical prompt-injection, jailbreak, and tool-forcing findings against an authorized endpoint.	Model claim and tool execution are separate facts. External effect requires independent readback.

Additional intake paths (26 registered typed profiles).

Registered profiles include: generic, log, api_transaction, alarm, kpi, policy, oran_wg11, a1_policy, o1, ran_handover, slice_flow, sbi_transaction, tmf, oam_topology, cyclonedx, logsense_bundle, otel, model_gateway, digital_twin, scenario_run, manufacturing_source, servicenow_aict, servicenow_agent_execution, servicenow_table, aws_agentcore, and aws_cloudwatch.
26 profiles represent 26 registered binders. Each binder is available to your tenant on request.
The 20-page Technical Annex documents the exhaustive intake matrix with per-profile schemas and examples.

EVerification ledger

Claim-evidence ledger: inspected source and explicit maturity

A curated claim ledger for the brief and annex, recording source anchors and outstanding validation. Each included assertion points to a source anchor and review date; code inspection does not by itself establish tenant acceptance.

Executive value

This is the accountability ledger. The selected claims in these materials trace here, subject to the stated evidence scope. When a CISO verifies a statement, they find the source, the revision, and the verification date in one row. Buyer trust is earned by making this ledger inspectable, not by asserting claims that cannot be sourced.

Statuses. Demonstrated, Supported, Evidence-gated, Release pending, Simulated, Mapped, and Open for qualification.

Status legend Demonstrated Supported Evidence-gated Release pending Simulated Mapped Open for qualification

18 shown

Claim	Customer sentence	Owner	Status	Evidence reference	Reviewed
CL-01	Deterministic evaluation produces the same findings and digest from the same evidence	Assurance Engine	Demonstrated	`lib/assurance/assurance-evaluator.ts` with replay verified	2026-10-18
CL-02	Five independent evidence planes compare without collapsing into one score	Assurance Engine	Demonstrated	Evidence plane comparison in `assurance-evaluator.ts`, persists independently	2026-10-18
CL-03	DAI compares nine orthogonal dimensions: operation, target, scope, magnitude, duration, approval, data_class, environment, geography	Assurance Engine	Demonstrated	`lib/assurance/dai-evaluation.ts` persists comparison state	2026-10-18
CL-04	Assurance receipts carry SHA-256 digests over evidence basis and result, replayable	Evidence Core	Demonstrated	Receipt emission in `lib/assurance`, digest over canonical scope JSON	2026-10-18
CL-05	GitHub App full executor runs static analysis on authorized linked installations	Source intake	Demonstrated	`lib/github-app/pr-static-executor.ts` tested on fixtures	2026-10-18
CL-06	MCP surface exposes read tools for cases, chains, and receipts	Developer surface	Supported	`lib/mcp/capability-guide.ts` tool definitions documented	2026-10-18
CL-07	MCP routes human actions (approval, kill-switch, revocation) through browser-authenticated flows	Developer surface	Supported	Human actions require browser-authenticated session. No MCP write path exists for these by design.	2026-10-18
CL-08	GitHub Action v2 will submit scan results from CI pipelines	Source intake	Release pending	v1 PAT flow deprecated. v2 pending reconciliation of distributable identity.	2026-10-18
CL-09	Cross-system delegation verification requires issuer-qualified identities and independent readback	Assurance Engine	Release pending	Gated by separate engineering contract, wired at a future release	2026-10-18
CL-10	Kill-switch dispatch requires per-target native enforcement adapter binding	Protection	Evidence-gated	`lib/kill-switch/native-enforcement-adapter.ts` registry per provider	2026-10-18
CL-11	Runtime endpoint testing is opt-in and requires authorized endpoint plus operator consent	Runtime	Evidence-gated	`docs/how-to/04-runtime-security.md` with Beta designation	2026-10-18
CL-12	AI AppSec package provides 122 detectors across 79 security checks	AI AppSec (separate)	Separate package	AI AppSec package documentation, separate from core registry	2026-10-18
CL-13	MCP tenant isolation package provides 57 rules: 42 multi-tenant and 15 MCP	MCP isolation (separate)	Separate package	Tenant isolation package documentation, separate from core registry	2026-10-18
CL-14	LLMVerify provides 38-rule CSM6 control set for LLM output quality and safety	LLMVerify (separate)	Separate package	LLMVerify package documentation, separate from core registry	2026-10-18
CL-15	Manufacturing corpus holds 45 current canonical evaluations of synthetic evidence	Case evidence	Demonstrated	See Table F. Manufacturing repository: 45 current plus 27 historical.	2026-10-18
CL-16	TM Forum 2026 archive contains C7, C9, C16 control test evidence with stated limitations	Case evidence	Demonstrated	See Table F. `tmf-2026-evidence` release v7a0bb5f3.	2026-10-18
CL-17	OWASP LLM 2025 and Agentic 2026 threat categories are mapped to HAIEC mechanisms	Framework crosswalk	Framework mapped	See Table C with honest per-row alignment states	2026-10-18
CL-18	Every OWASP LLM 2026 category is fully covered	Framework crosswalk	Open for qualification	LLM04 reserved, LLM09 out of scope, several partials. Full coverage is a roadmap item.	2026-10-18

FEvidence manifest

Case evidence: manufacturing evaluations and the TM Forum archive

The independent evidence section. Two corpora that CISOs, auditors, and security architects can inspect independently. Every claim in customer material about manufacturing or TM Forum evidence traces here.

Executive value

Real HAIEC evaluations of synthetic manufacturing evidence, alongside a separately archived workshop evidence package. A CISO can inspect supported HAIEC claims without relying on marketing. Two corpora: a persisted manufacturing evaluation corpus over synthetic evidence, and a participant-published TM Forum control-test archive. Every claim traces to a specific record a reviewer can independently examine.

Sources. github.com/subodhkc/manufacturing-ai-assurance-haiec and github.com/subodhkc/tmf-2026-evidence, snapshot 2026-10-18.

F1. Manufacturing corpus

Manufacturing Station 217: synthetic evidence, real evaluation

A persisted evaluation corpus of 45 current canonical cases across nine synthetic AI systems. Every current case resolves to REVIEW. Later operating behaviors (kill-switch, dashboard holds) are browser-local simulation, labeled as such.

Repository

github.com/subodhkc/manufacturing-ai-assurance-haiec

Public demo

haiec-manufacturing-demo.vercel.app

Synthetic AI systems

9 systems, numbered SYS-2xx

Current canonical evaluations

45, all RESULT: REVIEW

Historical evaluations

27

Wrong-target findings

9 MFG-EFF-001 mismatches, one per system

Receipt-bound R01 witnesses

18 effect-evidence records

Judge guide

docs/hackfw/JUDGE-GUIDE.md

Showcase contract

docs/product-story/HAIEC-MASTER-SHOWCASE-CONTRACT.md

Screens

docs/hackfw/screens-v29

Judge video

113.8 seconds, local repository artifact

Scope

Synthetic evidence with persisted evaluated results. Simulation of the operating response is clearly labeled.

Two clearly labeled lanes. A persisted, digest-verified evaluation of synthetic evidence followed by a separate, browser-local illustration of a subsequent demo hold. The evaluation is real. The operating response is clearly labeled as a demonstration of what could be wired next. When citing this corpus, always include the label: "Synthetic demonstration, real HAIEC evaluation." This is what makes the corpus trustworthy to an auditor.

F2. TM Forum archive

TM Forum 2026 Evidence Package: participant-published, integrity-verifiable

A workshop event evidence archive containing C7, C9, and C16 control test results, monitoring evidence, and enforcement pathway documentation. Participant-published and independently integrity-verifiable by any reviewer with the release hash.

Repository

github.com/subodhkc/tmf-2026-evidence

Release

v7a0bb5f3

Register file

register.yaml

Gap file

gap-list.md

Provenance file

SUBMISSION_PROVENANCE_AND_VERIFICATION.md

Status

Participant-published and integrity-verifiable by any reviewer

Pre-event thesis

subodhkc.com/tm-forum/haiec-agentic-assurance-deck.html (architecture thesis, separate from the event record)

F3. Control test evidence detail

Control	Purpose	Recorded evidence	Verdict	Extends with additional evidence
C7	Audit trail completeness	9 of 10 required coverage. One negotiation event missing from the frozen window.	Partial coverage	The missing event extends the record to full coverage. Partial coverage today is a valid operational state.
C9	Duration and performance control	Two assessed runs against frozen v2 thresholds. Both satisfied. No live breach in archive.	Satisfied	A live event within the tested window would produce a breach-of-boundary record.
C16 SAT	Token consumption cap, within	35,559 tokens against 60,000-token cap. Satisfied run.	Satisfied	Run-level verdict for a specific scoped run within the frozen cap.
C16 NOT-SAT	Token consumption cap, exceeded	106,829 tokens against 60,000-token cap. NOT_SATISFIED run.	Not satisfied	The archive records the verdict. Target-side blocking requires a native enforcement adapter for this specific provider.
MON	Monitoring	OTLP ingestion, detector canary, alert delivery records. Clean real-telemetry negative plus labeled synthetic canary.	Observed	Detector-to-alert wiring confirmed. Full control-test-verdict-to-alert wiring extends with the additional integration.
KILL	Kill switch pathway	Organizer environment pause and recovery record. HAIEC engine was not invoked for this action.	External	External enforcement pathway verified. HAIEC native adapter extends the same path into HAIEC's unified response workflow.

What the case evidence establishes.

HAIEC produced deterministic evaluated results over qualified evidence, and the corpus is persisted, digest-verifiable, and inspectable.
Every finding traces to a specific record with a specific verdict, a specific scope, and a specific digest.
Every limitation is named openly, so an auditor sees exactly what was established and what extends with additional evidence.
Both corpora are available to any customer or auditor for independent review. The verification path is documented in the provenance file.
Customer material citing these corpora includes the label: "Synthetic demonstration, real HAIEC evaluation" or "Participant-published archive" as appropriate.