# Software, Web & Data AI Operations Route Map

Status: `approval_ready`  
Purpose: choose the correct StackPilot workflow before giving an AI access, code, data, or production authority.

## Start with the work

| Need | Start here | Output |
|---|---|---|
| Plan and implement a code change | Software Developer manual | Spec-to-release evidence desk |
| Design and verify tests | Software QA Analyst & Tester manual | Requirements-to-release QA evidence desk |
| Change a warehouse pipeline/model | Data Warehousing Specialist manual | Warehouse change and data evidence desk |
| Choose an AI app builder | AI App Builder Tools | Workflow-first tool comparison |
| Choose a website builder | AI Website Builder Tools | Ownership/editability decision |
| Design a site/app workflow | Website and app design guides | Page, flow, and proof plan |
| Build a bounded agent | Agent Workflow Builder | Job card, permissions, and proof loop |
| Connect automations | Workflow Automation Tools | Trigger/action/failure/approval map |
| Protect credentials and files | Password, storage, privacy guides | Access and retention setup |

## Shared authority card

- Product/service and owner:
- Repository, data system, website, or platform:
- Exact bounded job:
- Environment and candidate identity:
- Data classification and approved fixtures:
- Business/metric/content owner:
- Security/privacy/accessibility/reliability reviewers:
- Cost/budget owner:
- Release/deploy/rollback authority:
- Customer/public communications authority:
- Prohibited actions:

## Shared AI boundary

AI may draft, organize, compare, map, test-design, summarize retained evidence, flag gaps, and prepare an approval packet.

AI may not obtain secrets; use private/production data in unapproved tools; silently change requirements, source truth, metrics, schemas, thresholds, or approvals; claim execution without evidence; grant access; merge; deploy; run production SQL; alter production; spend; restore/rollback; publish; or message users.

## Route sequence

1. **Define the owner and job.** Name what changes, who owns the truth, and what is out of bounds.
2. **Load the controlled baseline.** Requirements, code/data contracts, designs, policies, standards, versions, hashes, and approvals.
3. **Plan one candidate.** Exact repository/build/config/environment or page/asset version.
4. **Use synthetic or approved test inputs.** Never make private or production data the default prompt material.
5. **Retain proof.** Test receipts, expected/actual, screenshots/traces/logs, checksums, source links, and limitations.
6. **Map consequences.** Users, consumers, dependencies, accessibility, security, privacy, cost, performance, and recovery.
7. **Prepare the exact approval packet.** Name the requested action and authority; stop at `approval_ready`.

## Exact approval packet

```text
APPROVAL PACKET — SOFTWARE / WEB / DATA CHANGE
Asset/system and owner:
Exact candidate/version/commit/build/config/environment:
Requirements, source contracts, design or content baseline:
Data classification and approved fixtures:
Change scope and affected users/consumers/dependencies:
Test plan, receipts, raw evidence and unresolved gaps:
Security, privacy, accessibility and reliability reviews:
Cost/performance evidence and named owner:
Release/deploy/migration/backfill plan and operator:
Monitoring, pause, rollback/restore plan and authority:
Customer/public communication plan and authority:
Known limitations, stale-evidence triggers and expiry:
Requested approver and exact action:
Terminal state: approval_ready
```

Approval of a packet records only its named review. It never creates implied permission for credentials, access, spending, merge, deployment, data changes, rollback, publishing, or messaging.