Legal

Core posture

Kenshiki Labs is designed to verify consequential AI claims against authoritative sources, not to maximize collection of user data. We minimize what enters the system and keep access scoped to the workflows and actors that require it.

How data is handled

Data handling depends on deployment model, but the same control objective applies across environments: only the minimum data needed to verify a claim should be processed, and that processing should remain attributable and auditable.

• Least-privilege access to governed sources
• Explicit separation between application, model, and source authority
• Traceable evidence lineage for consequential outputs
• Deterministic audit records for review and investigation

Commercial and legal details

Production privacy terms, data processing commitments, and customer-specific handling obligations should be defined in the governing commercial agreement, DPA, or related contract documentation.

Public site use

The public website is informational. It describes Kenshiki Labs' operating model, architecture, and product direction, but it does not by itself create production commitments, warranties, or service obligations.

Commercial engagement

Production use, deployment obligations, support expectations, data handling terms, and service boundaries should be defined in a written agreement between Kenshiki Labs and the customer.

Why this matters

Kenshiki Labs is built for high-stakes environments. Those environments require precise contractual language around responsibility, evidence handling, security scope, and regulatory obligations.

System architecture

Security starts with clear trust boundaries. Kenshiki Labs separates application surfaces, inference pathways, and source authority so governance decisions are not hidden inside a single opaque runtime.

• Explicit trust demarcation between app, model, and evidence layers
• Deployment patterns that support VPC and isolated execution environments
• Policy-aware control surfaces instead of best-effort post hoc monitoring

Access and authorization

Kenshiki Labs uses policy and relationship-aware control patterns to ensure access is evaluated at the moment claims are retrieved, transformed, or emitted.

• Least-privilege access evaluation
• Role and relationship boundaries on sensitive data paths
• Operator-visible enforcement outcomes when authority is missing

Evidence and forensics

Security claims are only useful if they can be examined later. Kenshiki Labs emphasizes deterministic logs, evidence chains, and replayable decision paths so incidents can be reconstructed without guesswork.

How to read this page

Each of the five regime sections below lists specific obligations with three things stacked into one bullet: (1) the obligation in plain language with its article, clause, or function reference; (2) the Kenshiki artifact that satisfies it; (3) the replay path an auditor can walk to verify the artifact independently of Kenshiki. Rows prefixed with SHIPPED are live today and backed by a commit hash on the assurance ledger. Rows prefixed with ROADMAP name the target RFC or milestone.

• SHIPPED → live artifact with a commit hash on /tools/arbv — if the commit does not resolve or the artifact is not produced, the claim is false.
• ROADMAP → target RFC or milestone named — do not treat as current coverage; use the target date to plan procurement timing.
• Partial → primitive exists but not yet wired into the full path — read the specific note; single-tenant semantics often make partial coverage acceptable for canary scope.
• Every replay path is designed to run without Kenshiki's servers — if we go dark, the audit trail still verifies.

Train 1 — EU AI Act (Regulation 2024/1689)

Binding law with extraterritorial reach. Fines up to 7% of global turnover at the parent-group level. High-risk systems (Article 6) must meet the Article 9–17 controls. Most obligations hit in 2026. The artifacts below are what survives an enforcement inspection — not what looks good in a slide.

• Article 9 (risk management system) → Claim Ledger entry per decision with input context, authorized evidence scope, and output state. REPLAY: auditor recomputes `chunk_digest` + `manifest_digest` per retrieved chunk against the pinned `corpus_version_hash`.
• Article 10 (data and data governance) → AuthorizedCorpusView snapshot — signed list of evidence sources the model was permitted to use. REPLAY: verify Ed25519 signature on snapshot + confirm no chunks outside the snapshot appear in the Claim Ledger entry. [Partial — primitive shipped; full pre-filter wiring is RFC-005 T1A-5.]
• Article 11 (technical documentation) → /tools/arbv assurance ledger + Boundary Evidence Records per release. REPLAY: walk the commit hashes in the ledger; reproduce the ARBV run log against the model + policy versions named.
• Article 12 (record-keeping) → Claim Ledger (Ed25519-signed, manifest-anchored) per inference. REPLAY: recompute signature against published public key; verify manifest Merkle root against external timestamp.
• Article 13 (transparency) → governed response envelope carries `verified`, `confidence`, `access_decision`, and `attestation`. REPLAY: GET /v2/signing/keys returns Ed25519 public key; auditor verifies response envelope offline.
• Article 14 (human oversight) → Boundary Gate output states (AUTHORIZED, UNAUTHORIZED, ABSTAIN, EXCLUDED, DEGRADED) per response. REPLAY: query Claim Ledger for all DEGRADED or EXCLUDED outcomes in a window; confirm each had downstream review.
• Article 15 (accuracy, robustness, cybersecurity) → ARBV adversarial conformance suite + BER. REPLAY: auditor selects N cases from BER, re-runs them against the same model + policy versions, compares outcomes. Release-blocking if critical flips (EXCLUDED → AUTHORIZED) are detected. [ROADMAP — release-blocking CI gate targeted for Tier 2.]
• Article 17 (quality management system) → /tools/arbv ledger links every boundary to its spec, suite, attestation, and replay path. REPLAY: auditor walks the ledger; every cell links to a commit or a documented gap.

Train 2 — ISO/IEC 42001 (AI Management System)

First international AI management system standard. Audited by accredited certification bodies. The Kenshiki artifacts below provide the evidence the auditor needs to issue the certification — they are not the certification itself.

• Clause 5.1 (leadership and commitment) → governance charter + /tools/arbv boundary inventory. REPLAY: auditor confirms every authorization boundary has a named owner, a spec, and a review cadence on the assurance ledger.
• Clause 6.1 (actions to address risks and opportunities) → adversarial suite scope + severity classification. REPLAY: auditor reviews BER releases; confirms critical flips are release-blocking and non-critical flips have a treatment plan.
• Clause 7.5 (documented information) → BER archive + Claim Ledger. REPLAY: auditor selects a decision from the Claim Ledger at any point in the retention window; confirms the BER for that release is retrievable and its signature verifies.
• Clause 8.1 (operational planning and control) → ARBV release gate in CI. REPLAY: auditor reviews CI configuration; confirms the gate blocks merge on critical flip detection; reviews override log (should be empty for critical severity).
• Clause 9.1 (monitoring, measurement, analysis, and evaluation) → BER metrics (escape rate, exclusion integrity, containment depth). REPLAY: auditor queries BER archive by release; confirms metrics trend monotonically against targets. [Partial — metrics defined; dashboard published in /tools/arbv roadmap.]
• Clause 10.2 (continual improvement) → assurance ledger delta between releases. REPLAY: auditor diffs /tools/arbv at two consecutive release tags; confirms either improved coverage or documented regression with remediation.

Train 3 — NIST AI RMF 1.0 (and 2.0 in progress)

US federal and enterprise gold standard. Four functions: GOVERN, MAP, MEASURE, MANAGE. Most enterprise programs pass GOVERN and MAP on paperwork; they fail MEASURE and MANAGE because they lack a runtime evidence layer. Kenshiki produces the evidence layer.

• GOVERN — policy invariants encoded in AuthorizedCorpusView + CAA state machine. REPLAY: auditor reads the invariants directly from the primitive's source; confirms formal verification has run on them (absence of contradictions or unsafe paths).
• MAP — corpus inventory (/tools/corpus lists all indexed regulatory nodes with authority tier) + boundary inventory (/tools/arbv lists every authorization boundary). REPLAY: auditor walks both pages; cross-references against the enterprise's AI inventory for coverage gaps.
• MEASURE — BER metrics per release (escape rate, decision margin, containment depth). REPLAY: auditor takes a metric from the current release BER and recomputes it from the raw Claim Ledger entries; confirms match. [Partial — ARBV conformance suite shipping in Tier 2.]
• MANAGE — release-blocking CI on critical flips; signed incident records for any severity-high finding. REPLAY: auditor reviews the override log; confirms no critical flips have shipped to production. If any have, the incident record is signed and includes the remediation commit. [ROADMAP — CI gate targeted Tier 2.]

Train 4 — ISO/IEC 23894 (AI Risk Management)

Technical-controls baseline that bridges traditional IT risk to AI-specific failure modes. The AGORA regulatory corpus crosswalk maps ISO/IEC 23894 controls onto the other four regimes' obligations through a continuously expanding cross-regime edge graph — current scope is the canonical five corpora; ingest is ongoing as new AI governance frameworks land (NIST AI RMF 2.0, DoD RAI updates, state AI laws, ISO 5338/25059/24029, OECD principles, sector-specific frameworks). Every new corpus compounds the graph because edges scale with cross-regime pairs, not with single-regime nodes.

• Clause 6.4 (risk identification) → adversarial suite's semantic fuzzing — searches for boundary flips across meaning-preserving mutations. REPLAY: auditor runs the ARBV Scout model against the published test corpus; compares flip rate against the BER baseline.
• Clause 6.5 (risk analysis) → decision-margin measurements in the BER (how much adversarial pressure the deterministic gate absorbs before diverging from policy). REPLAY: auditor selects a margin measurement; re-runs the underlying test with the pinned model + policy versions; verifies the margin.
• Clause 6.6 (risk evaluation) → severity classification in the BER (critical / high / medium / low per flip type). REPLAY: auditor confirms release policy: critical severity = blocking; high = documented exception required; medium/low = tracked.
• Clause 6.7 (risk treatment) → CAA invariants (authorization logic) + Boundary Gate enforcement. REPLAY: auditor reviews CAA source; confirms invariants match the documented policy; verifies gate rejects flips at runtime via test injection.

Train 5 — US Sector Enforcers (SEC, FTC, DoD)

Less about formal certification, more about defending specific claims in enforcement actions. The SEC and FTC are actively enforcing against "AI washing" — the gap between AI capability claims and what can actually be proven. The DoD Responsible AI Strategy and Implementation Pathway requires traceability and reliability for federal grant and contract AI work.

• SEC AI washing → product capability claims tracked against live artifacts on /tools/arbv. REPLAY: investor or enforcement staff compares every public AI-capability claim against the commit-hash-backed row on the assurance ledger. If a claim has no matching row or the row is ROADMAP, the claim is unsupported.
• FTC deceptive AI practices → Claim Ledger evidence chain per customer-facing decision. REPLAY: plaintiff's counsel subpoenas Claim Ledger entries for a contested decision; auditor verifies Ed25519 signatures offline; confirms output matches what was actually served.
• DoD Responsible AI — traceability → Ed25519-signed chunk lineage + AuthorizedCorpusView snapshot per decision. REPLAY: DoD auditor pins `corpus_version_hash`; recomputes every chunk signature in the Claim Ledger entry; confirms evidence set matches the policy-permitted set.
• DoD Responsible AI — reliability → adversarial conformance + BER continuity across releases. REPLAY: DoD auditor reviews BER archive across the contract period; confirms containment metrics meet the contracted threshold at every release. [ROADMAP — continuous BER publishing targeted Tier 2.]

How to verify

Every replay path above is designed to run independently of Kenshiki. That is the difference between a trust claim and an admissible record. Public verification paths are published at /tools/arbv; per-request signing keys are available at /v2/signing/keys. If any replay path fails to verify as described, the row in this table is false — which is the point.

• Start with /tools/arbv — confirms which boundaries are SHIPPED vs ROADMAP and gives the commit hash for each.
• For any specific decision, retrieve the Claim Ledger entry, extract `manifest_digest` and `chunk_digest[]`, and verify against `GET /v2/signing/keys`.
• For adversarial conformance, the current BER is the source of truth; auditors can rerun specific test cases against pinned model + policy versions.
• If you represent a regulator or certification body and need a different replay protocol, contact Kenshiki and we will publish the protocol on this page.

What this page is not

This page is not a certification, a legal opinion, or a guarantee. Certification is issued by accredited bodies against specific regime standards; legal opinions are issued by counsel against specific facts; guarantees against regulatory outcomes are not within any vendor's authority to issue. What this page is: a row-by-row, artifact-by-artifact, replay-instruction map from regime obligation to Kenshiki-produced evidence — designed to survive the adversarial scrutiny that regime enforcement applies.

• Not a certification — Kenshiki does not issue certs against any of the five regimes.
• Not a legal opinion — counsel interprets regime application to specific facts.
• Not a guarantee — regulatory outcomes depend on facts, jurisdiction, and enforcement posture beyond any vendor's control.
• It is the evidentiary infrastructure. The artifacts survive the audit that leads to the cert, the opinion, or the enforcement action.