# AISDLC-PA: Pod Accountability **Version:** 0.1 **Status:** Draft for review **Publication date:** 2026-09-06 **Publisher:** LockedIn Labs **Cite as:** AISDLC-PA 0.1, PA-1 through PA-7 A pod can ship quickly while leaving its authority unresolved. The failure appears later: nobody owns the rejected gate, the customer handoff, or the decision to stop a deployed agent. This original companion draft defines accountability for a bounded delivery pod, including forward-deployed engineers working across organizational boundaries. It supplements [AISDLC-CQ](/spec/aisdlc-cq/1.0) and [Deployment Evidence](/spec/aisdlc-de-0.1.md). It does not prescribe team size, grant authority, alter CQ levels, or establish certification. ## Operating model A pod is a delivery team assigned an outcome and a defined operational boundary. Relevant responsibilities include product and system ownership, engineering, data ownership, security and privacy, independent verification, human production authority, and operation. One person may hold compatible responsibilities. Role overlap never removes a required separation of permissions or approval authority. MUST and MUST NOT indicate proposed obligations using [BCP 14 terminology](https://www.rfc-editor.org/rfc/rfc8174.html). Each assessment names the pod, system, organizations involved, authority revision, and date. ### PA-1: Publish the pod charter **Requirement:** Before delivery begins, the pod MUST record its outcome, acceptance criteria, system boundary, accountable owner, participating organizations, prohibited actions, and escalation route. The charter MUST distinguish authority granted by the system owner from technical access merely available to an engineer. **Verification:** Compare a representative work item and requested access with the charter. **Evidence:** Approved charter, ownership record, and access-scope comparison. ### PA-2: Assign decision rights **Requirement:** Each material decision MUST have a named accountable person and a defined delegate or escalation path. Decisions MUST include requirement changes, data access, architecture exceptions, release, emergency containment, and acceptance of residual risk. A shared team name MUST NOT substitute for an accountable person. **Verification:** Present one decision from each category and identify who can authorize it. **Evidence:** Decision-rights register, delegation limits, and scenario results. ### PA-3: Protect independent challenge **Requirement:** The pod MUST identify who builds, who independently verifies, and who authorizes promotion. The generation agent MUST NOT change protected acceptance policy or approve its own release. A verifier's finding MUST remain recorded when the builder disagrees. **Verification:** Inspect permissions and exercise a disputed failing check without deleting its result. **Evidence:** Identity map, access policy, preserved finding, and final disposition. ### PA-4: Control organizational boundaries **Requirement:** Work crossing organizational boundaries MUST identify the receiving owner, authorized data exchange, environment access, support expectations, and evidence-sharing limits. Access MUST use individually attributable or explicitly assigned service identities. Customer credentials MUST NOT become a shared pod identity. **Verification:** Trace one access grant and one synthetic handoff across the boundary. **Evidence:** Authorization reference, access record, handoff receipt, and revocation procedure. ### PA-5: Make release a decision **Requirement:** Release authority MUST review the specified candidate and required evidence before approving its permitted operating scope. The decision MUST name restrictions, expiry, and the party receiving operational responsibility. Availability of an engineer MUST NOT determine who has authority to approve. **Verification:** Compare release approval with the authority register and receiving owner's acceptance. **Evidence:** Candidate-linked approval, evidence index, and operational acceptance record. ### PA-6: Rehearse escalation and stop **Requirement:** The pod MUST define and exercise escalation for gate failure, suspected data exposure, unauthorized agent action, and unavailable ownership. Stop authority MUST be explicit and technically usable within its scope. Resumption MUST require a recorded decision after the triggering condition is assessed. **Verification:** Run a controlled scenario from detection through containment and resumption review. **Evidence:** Scenario timeline, contacted owner, intervention result, and resumption disposition. ### PA-7: Transfer accountability deliberately **Requirement:** Departure, contract completion, or ownership change MUST trigger review of active authorization, access, unresolved findings, support obligations, and evidence custody. The receiving owner MUST accept responsibility before the previous ownership arrangement ends; otherwise affected activity MUST be restricted under the continuity plan. **Verification:** Rehearse a pod-member departure and a system-owner transfer. **Evidence:** Accepted handoff, access changes, unresolved-issue register, and continuity decision. ## Sources and assessment limits The voluntary [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) informs lifecycle accountability and risk management. Its [Generative AI Profile](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf) adds consideration of generative AI governance, evaluation, and incident disclosure. This draft's pod-specific clauses are original proposals, not quotations, NIST requirements, or endorsed guidance. Assess each clause as met, unmet, or unknown against actual records and permission tests. A responsibility chart alone cannot establish effective control. This draft does not determine contractual liability, employment duties, staffing ratios, or jurisdiction-specific obligations. No assessment of an operating pod is claimed here.