# AISDLC-DE: Deployment Evidence

**Version:** 0.1  
**Status:** Draft for review  
**Publication date:** 2026-09-06  
**Publisher:** LockedIn Labs  
**Cite as:** AISDLC-DE 0.1, DE-1 through DE-7

A passing build describes a candidate. A deployment decision also needs to identify where that candidate will run, what it can reach, who authorized it, and how operation can be contained.

This original companion draft specifies that evidence boundary for AI-assisted software and deployed AI systems. It supplements [AISDLC-CQ](/spec/aisdlc-cq/1.0) without changing its clauses or levels. It defines no certification program and makes no claim that the publisher's systems satisfy these requirements.

## Proposed requirements

MUST and MUST NOT indicate obligations within this proposed draft, using [BCP 14 terminology](https://www.rfc-editor.org/rfc/rfc8174.html). Assessment applies to a named candidate, target environment, policy revision, and observation date. A planning document and an executed observation are different evidence types.

### DE-1: Identify the deployment boundary

**Requirement:** The deployment record MUST identify the artifact digest, target environment, configuration revision, responsible system owner, data classifications, permitted actions, prohibited actions, and authorization expiry. A change in these boundaries MUST trigger review before expanded access is enabled.

**Verification:** Compare the record with deployed configuration and effective permissions.

**Evidence:** Versioned deployment manifest, environment identity, and permission comparison.

### DE-2: Bind provenance and inventory

**Requirement:** Build provenance, resolved component inventory, and verification results MUST reference the exact deployment artifact. The evidence producer's identity and integrity mechanism MUST be recorded. A digest alone MUST NOT be presented as proof of an authorized producer.

**Verification:** Substitute another artifact or an untrusted producer's record and confirm rejection.

**Evidence:** Provenance statement, software bill of materials, trusted-producer policy, and rejection results.

### DE-3: Record what actually executed

**Requirement:** Required checks MUST record their configuration, execution identity, inputs, outcome, and time. Missing, stale, cancelled, or incomplete required results MUST block authorization. Planned checks MUST remain visibly distinct from executed checks.

**Verification:** Remove a result and change a candidate input after verification; attempt authorization.

**Evidence:** Artifact-linked reports, freshness policy, input identities, and failed-authorization records.

### DE-4: Demonstrate recovery

**Requirement:** Before activation, the deployment owner MUST exercise containment and recovery in an approved representative environment. The record MUST include stop authority, access revocation, state reconciliation, recovery limits, and irreversible effects. A rollback command alone MUST NOT establish recovery readiness.

**Verification:** Execute a controlled failure scenario and compare resulting state with recovery criteria.

**Evidence:** Exercise transcript, reconciliation results, elapsed recovery time, and unresolved limitations.

### DE-5: Bind human authorization

**Requirement:** A named authorized person MUST approve the specific artifact and deployment boundary after reviewing required evidence. The decision MUST record restrictions, exceptions, and expiry. Promotion MUST reject a decision for another artifact, an expired decision, or authorization outside the person's delegated scope.

**Verification:** Exercise those three rejection cases.

**Evidence:** Authority reference, signed or otherwise authenticated decision, and enforcement results.

### DE-6: Connect release to operation

**Requirement:** Operation MUST retain a correlation between deployment identity, policy decisions, material actions, and observed outcomes. Monitoring MUST have named recipients and predefined intervention criteria. Runtime model, tool, data-boundary, or permission changes MUST be assessed before existing authorization is reused.

**Verification:** Trace one synthetic action through monitoring and exercise an escalation.

**Evidence:** Redacted correlated event record, alert delivery, disposition, and change assessment.

### DE-7: Preserve usable evidence

**Requirement:** Evidence MUST have access controls, retention periods, integrity protection, and an accountable custodian. Secrets and unnecessary sensitive payloads MUST NOT enter published records. Ownership transfer or retirement MUST include evidence custody and credential disposition.

**Verification:** Have an authorized reviewer reconstruct a decision and test an unauthorized retrieval.

**Evidence:** Reconstruction record, access test, retention policy, and transfer or retirement receipt.

## Sources and limits

[SLSA 1.2](https://slsa.dev/spec/v1.2/) informs the separation of artifacts, provenance, and verification. [CycloneDX 1.7](https://cyclonedx.org/specification/overview/) provides a representation for components, services, dependencies, and inventory completeness. Neither source makes an inventory or provenance statement a guarantee of correct behavior.

The voluntary [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) and [Generative AI Profile](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf) inform lifecycle risk review and deployment evaluation. These references do not endorse this draft or establish legal equivalence.

An assessment should report met, unmet, or unknown for each clause, with evidence references and scope. This draft does not define universal retention periods, recovery times, or evaluation thresholds; the deployment's risk policy supplies those decisions before execution.