Before taking ownership of an AI-built app, record what keeps it running after the demonstration ends. That includes services, accounts, scheduled work, external APIs and recovery procedures. The code repository is important, but it cannot by itself establish that your team can operate, pay for and recover the application.
Use the dependency record below to connect each live resource to an owner and a check. These practices also apply to conventionally built software. The AI-specific concern is straightforward: a successful agent-assisted build still needs an accountable operational handover.
- 01Separate ownership from access.A named maintainer may not control the account, billing or credentials.
- 02Inspect background dependencies.A browser demonstration can miss scheduled jobs, expiry dates and recovery requirements.
- 03Distinguish plans from results.A restore procedure and a successful restore test are different evidence.
01 — Practical guideRecord one operational dependency at a time
Treat each deployed resource in each environment as a record. Two databases hosted by the same provider can have different owners and recovery requirements. Separate production from staging, and identify optional dependencies by the feature they support.
Package inventories and service catalogs remain useful. The CycloneDX 1.6 schema already represents services as well as components. The handover question is whether those records connect to actual control and operating evidence, not whether a software bill of materials can contain services.
| Dependency | Record before acceptance | Evidence to request |
|---|---|---|
| Data store | Environment, owner, access, backup and recovery order | Receiving-account access plus separately recorded recovery evidence. |
| External API | Configured endpoint/version, quota, retry policy and fallback | Configuration and the outcome of an agreed representative operation. |
| Credential | Safe reference, consumer, scope and lifecycle owner | Authorized metadata review; keep the secret value out of the document. |
| Scheduled work | Job, timing/timezone, target, retries and failure signal | Configuration and a retained run outcome. |
| Billing | Account owner, currency, fixed/usage units and renewal | Authorized billing records; separate measured costs from estimates. |
| Delivery pipeline | Release identity, build dependencies and deploy procedure | Trace the accepted application back to its code and configuration. |
02 — Practical guideSeparate the people responsible from the permissions they hold
Record technical responsibility, account administration and billing ownership. One person may fill all three roles, but the roles answer different questions. Who fixes a failure? Who can grant or revoke access? Who receives the invoice or notices an expiring credit?
The Backstage catalog format distinguishes declared ownership from runtime authorization. A name in a catalog is not proof that the person can operate the resource. Ask the receiving owner to verify the access needed for the agreed duties.
Keep credentials in the appropriate secret store. The handover record should point an authorized maintainer toward the relevant procedure without embedding a key, recovery code or password. Even architectural metadata may be sensitive; keep the real record access-controlled.
The OWASP secrets-management guidance supports recording purpose, consumers, contacts and lifecycle information. It does not justify applying the same rotation interval to every credential. Record the policy that actually governs the resource.
03 — Practical guideFind work the demo does not show
An app may look complete while relying on jobs that run overnight, callbacks configured in another account or an API key that belongs to the builder. Ask what executes without a person visiting the page. For each recurring operation, record its destination and how someone learns that it failed.
A schedule alone is insufficient. Some schedulers can deliver an execution more than once; others impose different concurrency or retry rules. The receiving team needs the actual implementation’s behavior and the application’s response to a repeat. Do not describe every scheduler as exactly once.
An application built with an AI coding agent need not call an AI model at runtime. Add model identifiers, routing and inference billing only when the application uses them. Otherwise, they describe the development process rather than a live dependency.
Our CI/CD reference covers release identity and promotion. Use that evidence to identify the deployed revision, then continue the handover into the accounts and recurring work that remain after deployment.
04 — Practical guideKeep recovery objectives separate from restore evidence
A backup location is a starting point. The team also needs to know which service comes back first, how much lost data is acceptable and how quickly the critical workflow must recover. Those are desired outcomes. Record separately whether a restore was attempted, which revision it used and what happened.
NIST’s updated contingency-planning guide distinguishes recovery planning, testing and maintenance. We use those concepts here; this editorial record does not certify compliance with the publication or any regulation.
Consider a hypothetical database entry marked backup configured. If no restore has been exercised, the recovery result remains unknown. The appropriate next action is a scoped recovery test in a suitable environment, not rewriting the field to recovery verified.
The same discipline applies to migration. An export button or configurable connection string does not establish that another service preserves schema, identity behavior and callbacks. Keep a proposed replacement plan distinct from a tested move.
05 — Practical guideUse evidence states instead of a handover score
The blank runtime dependency record includes the fields needed to start. Link existing catalogs and inventories rather than copying every package into another spreadsheet. Choose a stable identifier so configuration changes can be traced over time.
Use declared when the builder supplies a statement, inspected when a source or configuration has been reviewed, and exercised when an operation has a retained outcome. Add unknown and not applicable with an explanation. These are editorial labels; they are not certification levels.
| Record group | Required detail | Change that triggers review |
|---|---|---|
| Identity and relationship | Resource, environment, feature, caller and dependency links | Adding, removing or changing a runtime dependency. |
| Control and credentials | Technical owner, administrator, billing owner and safe secret references | Account, personnel, privilege or credential lifecycle changes. |
| Operations | Job behavior, quotas, fallback and monitoring destination | Scheduler, API version, retry or alert changes. |
| Economics | Billing unit, measured period, forecast assumptions and renewal | Pricing, credit, usage or contract changes. |
| Recovery and exit | Order, procedure, objective, test result and migration constraints | Architecture, backup or restore-process changes. |
| Provenance | Evidence reference, observer, date, status and unresolved action | Any fact changes or loses its supporting evidence. |
06 — Practical guideAccept the revision and its unresolved exceptions
Start with the workflows the receiving team must support. Reconcile the declared dependencies with authorized configuration and service records. Then agree which safe operations will be exercised and which recovery checks need a separate test environment. Keep account transfers, credential revocations and billing changes as explicit actions.
A hypothetical handover can legitimately contain exercised access, inspected configuration and an unknown renewal date. That is more informative than a single complete checkbox. Name the unresolved issue, its consequence and the person responsible for closing it.
For exported supporting files, use our file-acceptance reference . For the separate question of permitting coding agents inside an organization, use the enterprise deployment playbook . The delivered application’s ownership should not be confused with the coding agent’s access.
Our AI transformation service can help define a handover around the workflows your business needs to retain. Keep the accepted code revision and dependency-record revision together so future maintainers know what was actually reviewed.
Evidence and scope
- As-of date
- September 12, 2026. September 9 is the editorial allocation; this research was reviewed later.
- Method
- A proposed operational dependency record based on pinned primary documentation and recovery guidance. The field groups and evidence states are editorial designs; examples are hypothetical.
- Limitations
- No private account, billing record or customer application was inspected. No access transfer, credential rotation, scheduler replay or recovery experiment was performed.
07 — Next stepMake the receiving team’s next action possible.
Make the receiving team’s next action possible.
Choose the critical workflow, identify each dependency it needs, and connect the record to an owner and evidence. Accept the exact revision with named exceptions, then update the record when the operating environment changes.