A protection layer for AI-assisted work that separates what a system claimed from what can be proved, preserves evidence and authority state, and can hold, block, quarantine or propose bounded repair when execution, proof, provenance or permission do not match. Reentry stays controlled so repair cannot silently become the owner of truth or the next consequential action.
AI-assisted work can fail in more than one place: a system can claim an action that did not execute, attach proof that does not support the claim, inherit permission it was never granted, or repair one defect while silently changing who owns the next decision.
AI Integrity, Repair & Reentry keeps execution truth, evidence, claim, permission, blocked use, provenance and repair state separate. Deterministic controls can return HOLD, BLOCK, QUARANTINE or REPAIR_REQUIRED instead of allowing a plausible narrative to stand in for proof.
A public repair HTTP surface can expose a mismatch and propose bounded repair, while hash-bound custody and reentry rules preserve what changed and prevent a successful repair from silently promoting itself into release authority.
Each item below is deliberately narrower than a product-readiness or superiority claim.
Deterministic state distinguishes claimed action from supported execution and keeps evidence, permission and claim ceilings separately inspectable before movement.
The Python product and public repair surface have been exercised through repository test/coverage work, container validation, GitHub Actions, security scanning, SBOM/provenance generation and reproducible OCI builds.
OCI artifacts have been published to Azure Container Registry, signed through Key Vault-backed Notation and checked under strict signature verification so artifact identity and release evidence remain independently inspectable.
Confidential-compute work includes Azure ACI, CCE policy generation, private SKR integration and attestation-bound runtime geometry. The completed confidential-runtime evidence does not yet establish a finished MAA/key-release chain.
It does not claim universal hallucination prevention, prompt-injection immunity, compliance certification, provider superiority, a completed attestation/key-release chain, generalized governance efficacy or authority to release consequential actions on its own.
The executed product body includes deterministic integrity states, public repair, container/CI/security evidence, reproducible and signed OCI custody, and confidential ACI/CCE/SKR work. Current bounded engineering remains focused on aligning the app-native repair-to-private-key path with the required non-debug policy geometry without weakening the proof boundary.