Files
CASAN/docs/architecture/CASAN_ASSURANCE_KERNEL.md
T

142 lines
6.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# CASAN Assurance Kernel
Status: implemented contract layer, version `1.0.0` (2026-08-02).
## Purpose and maturity
CASAN now has a framework-independent wire contract and deterministic policy
primitives outside the native Bash topology. The native harness remains
operational and is the first compatibility adapter; the Agentic Bridge is the
second adapter. This is an incremental extraction, not a rewrite of H1–H7.
CASAN may describe this layer as an **Assurance Kernel contract and policy
foundation with two conforming adapters**. It must not claim that every legacy
loop, graph, report, or third-party runtime has migrated to the kernel.
## Boundary
```text
Execution runtime
-> runtime adapter
-> canonical Assurance Kernel envelope
-> deterministic policy / verification / evidence services
-> runtime-specific enforcement mechanisms
```
The kernel does not execute models. It does not infer security decisions from
model output. Runtime-specific data is allowed only under a namespace such as
`casan.runtime.casan-native-harness` or `casan.runtime.agentic-bridge`.
## Canonical contract
The canonical source is
`packages/casan-harness/schemas/assurance-kernel.schema.json`. It is JSON Schema
Draft 2020-12 and uses `schema_version: 1.0.0`.
The envelope defines:
- `ExecutionRun`: identity, parent, scope, environment, runtime, mode, goal,
timestamps, status, risk summary, evidence manifest and correlation.
- `ExecutionStep`: causal position, actor/action/resource, context references,
policy decisions, tool invocation, verification, evidence and outcome.
- `Actor`: human, agent, child agent, model, tool, service account, runtime,
approver or policy engine with issuer, trust and authentication evidence.
- `Delegation`: authority, resource scope, expiry, maximum depth, parent,
revocation and approval.
- `ContextItem`: origin, trust, content hash, transforms, compression lineage,
instruction/data classification and injection scan.
- `Action` and `ResourceAccess`: canonical class, operation, authority,
side-effect level, resource and environment.
- `PolicyDecision`: versioned policy, structured decision, reason codes, risk
facts, enforcement point, engine identity, time and evidence reference.
- `RuntimeConstraint` and `RuntimeCapabilities`: honest limits and supported
cancellation/intervention mechanisms.
- `VerificationRequirement` and `VerificationResult`: expected versus actual
result, evidence, independence and failure severity.
- `Claim`, `EvidenceItem` and `TraceLink`: bidirectional claim support,
integrity metadata, producer, artifact, validation, retention and typed links.
- `Approval` and `Intervention`: explicit decisions and runtime support status.
- `Outcome`: four independent results for execution, assurance,
certification and business effect.
## Deterministic kernel services
The stdlib-only Python implementation is under
`packages/casan-harness/kernel/`.
`policy.py` provides:
- Machine-readable action classification from
`config/action-classes.json`.
- Effective risk as the maximum of content, action, resource, identity and
environment risk.
- H2 registry configuration validation and fail-closed dependency decisions.
- Single-step failure-policy selection with `halt`, `quarantine`,
`require_approval` and `record_only`.
- Production trust capability evaluation.
`contracts.py` provides builders and an enforcement-boundary verifier. The
verifier rejects unsupported schema versions, invalid actor/step references,
observed-only certification, broken claim/evidence links, evidence digest
tampering, delegation cycles and excess delegation depth.
`taxonomy.py` separates `RuntimeControl.Hn`, `ReadinessCheck.Hn`,
`ReportDimension.Hn` and `CertificationClaim.Hn`. A legacy `Hn` remains a
display alias only and never authorizes cross-category interpretation.
`supervision.py` negotiates interventions against declared runtime
capabilities. Unsupported pause, rollback, cancellation, authority reduction
or quarantine returns `unsupported`; it never reports a fictitious success.
## Action policy
The action registry includes read, write, delete, database mutation,
migration, deployment, release, credential access, identity/permission change,
external network side effect, infrastructure modification and unknown actions.
High-impact actions have a high minimum risk, require an identified actor,
explicit approval and evidence. Benign text cannot reduce that floor. Unknown
shell operations also fail toward high risk. H2 registry enforcement and H5
approval remain separate defense-in-depth decisions.
## Outcome semantics
The following states are deliberately distinct:
```text
execution_result = success | failed | cancelled | quarantined | ...
assurance_result = passed | failed | degraded | not_evaluated | ...
certification_result = certified | non_certified | ineligible | ...
business_result = achieved | not_achieved | partial | not_evaluated | ...
```
A telemetry append can succeed while `execution_result=failed`. A failed
side-effecting command defaults to `halt` in enforce/production mode and cannot
produce a successful completion or normal certification.
## Evidence integrity and trust
Canonical evidence metadata is linked to claims and carries a SHA-256 digest.
This detects local mutation and broken references. It is not, by itself, an
external trust root or WORM guarantee. Production certification separately
requires external signing and an external immutable anchor.
## Compatibility rules
- New envelopes use semantic version `1.0.0`; incompatible schema changes
require a new major version.
- Additive runtime fields belong under a namespaced `extensions` object.
- The native and Agentic Bridge formats remain readable and are dual-emitted
with canonical envelopes during migration.
- Legacy evidence is not silently reinterpreted as kernel-validated evidence.
- Observe-mode and unsafe-development-bypass runs are never certified.
- Audit chain format v1 remains verifiable while new records use v2 fields.
## Claims and residual limits
CASAN can claim deterministic shared action policy, canonical execution and
evidence contracts, and cross-runtime conformance for the native harness and
Agentic Bridge. It cannot yet claim universal runtime adoption, complete
multi-runtime supervision, external infrastructure availability, or
data-backed H1–H7 dossiers beyond the reports actually backed by evidence.