The Factory needs a simple boundary between automation and responsibility.
Machines perform repeatable work and produce evidence. Humans define intent, accept risk, approve material changes and remain accountable for consequences.
This policy is the governance overlay for the Prompt Factory process map: the process defines where work happens; the autonomy level defines how it may run; the gate identifies who accepts the next risk.
Automation may increase. Accountability does not transfer.
Five levels of autonomy
Autonomy is not a single switch. It is a bounded permission assigned to a specific activity, version and operating context.
| Level | Meaning | Appropriate use |
|---|---|---|
| A0 | Human performs the activity | Strategic or exceptional decisions |
| A1 | AI assists; human completes | Problem definition and architecture |
| A2 | AI prepares or executes; human approves | Production releases and consequential actions |
| A3 | Autonomous within approved policies | Testing, monitoring, routing and reversible operations |
| A4 | Unsupervised consequential autonomy | Not recommended for the first 10 clients |
Three axes stay separate: the autonomy level defines how work runs; the intervention tier defines approval density by risk; the lifecycle gate defines whether evidence permits progression.
Process and intervention map
The Factory should operate autonomously by default, with human intervention only at decision, risk, ambiguity and accountability points.
| Stage | Autonomous work | Human intervention | Gate | Main KPI |
|---|---|---|---|---|
| 1. Demand intake | Capture request, classify use case, detect duplicates, estimate complexity and risk | Product Owner clarifies the business outcome for new or ambiguous demands | G0 — Demand accepted | Intake lead time |
| 2. Specification | Draft requirements, context, constraints, test cases and success criteria | Process Owner approves scope, expected behavior and business rules | G1 — Specification ready | Requirement completeness |
| 3. Prompt design | Generate variants, select templates, configure models, tools and context | Prompt Engineer decides architecture for complex cases | G2 — Candidate ready | First-pass success rate |
| 4. Evaluation | Run functional, regression, hallucination, latency and cost tests | Domain Expert reviews subjective or business-critical outputs | G3 — Quality approved | Evaluation pass rate |
| 5. Risk and governance | Scan for personal data, secrets, prohibited content, security and policy violations | Security, Legal or Compliance approves sensitive use cases | G4 — Risk accepted | Policy violations escaped |
| 6. Packaging | Version prompt, attach metadata, permissions, documentation and rollback configuration | Release Owner validates audience and production impact | G5 — Release authorized | Release lead time |
| 7. Distribution | Publish to catalog, APIs, agents or workflows; perform canary rollout | Human approval for high-impact production releases | G6 — Production active | Deployment success rate |
| 8. Monitoring | Track quality, adoption, latency, cost, drift and incidents; trigger rollback | Prompt Ops intervenes when thresholds or SLAs are breached | G7 — Operation healthy | Success rate and cost per outcome |
| 9. Optimization | Cluster feedback, propose improvements and run controlled experiments | Product Owner selects improvements and accepts behavior changes | G8 — New version approved | Value uplift per version |
| 10. Retirement | Detect inactivity, obsolete dependencies and duplicated prompts | Business Owner approves deprecation or replacement | G9 — Retired safely | Active prompt reuse rate |
- 01Autonomous demand intakeClassify, deduplicate, estimate
- G0Demand acceptedClarify new or ambiguous outcomes
- 02AI-assisted specificationRequirements, constraints and tests
- G1Specification readyScope and business rules approved
- 03Prompt designVariants, models, tools and context
- G2Candidate readyComplex architecture reviewed
- 04Automated evaluationQuality, latency and cost
- G3Quality approvedSubjective and critical outputs reviewed
- 05Risk and governance scanData, security and policy
- G4Risk acceptedSensitive uses require approval
- 06Automated packagingVersion, metadata and rollback
- G5Release authorizedAudience and impact validated
- 07Controlled distributionCatalog, APIs, agents and canary
- G6Production activeHigh-impact releases remain human-approved
- 08Autonomous monitoringQuality, cost, drift and rollback
- G7Operation healthyPrompt Ops handles breached thresholds
- 09Autonomous optimizationFeedback clusters and experiments
- G8New version approvedMaterial behavior change accepted
- 10Retirement analysisInactivity, obsolescence and duplication
- G9Retired safelyDeprecation or replacement approved
Ten gates, one accountable progression
A gate is not a status meeting. It is a recorded decision over evidence. Each gate identifies the version, results, risks, accountable owner and next permitted state.
Demand accepted
Is the demand real, distinct and outcome-oriented?
Accountable role: Product Owner.
Autonomous evidence
- Request capture and classification
- Duplicate detection
- Complexity and risk estimate
Human intervention
- Clarify the business outcome for new or ambiguous demands
- Confirm accountable ownership
Main KPI Intake lead time.
Specification ready
Are scope, behavior and business rules explicit?
Accountable role: Process Owner.
Autonomous evidence
- Requirements and context
- Constraints and test cases
- Success criteria and operating envelope
Human intervention
- Approve scope and expected behavior
- Validate business rules and exceptions
Main KPI Requirement completeness.
Candidate ready
Is the design coherent enough to evaluate?
Accountable role: Prompt Engineer.
Autonomous evidence
- Prompt variants and templates
- Model, tool and context configuration
- Candidate package for evaluation
Human intervention
- Choose architecture for complex cases
- Resolve ambiguous tool or context design
Main KPI First-pass success rate.
Quality approved
Does the candidate meet the quality threshold?
Accountable roles: Evaluation Engineer and Domain Expert.
Autonomous evidence
- Functional and regression tests
- Hallucination, latency and cost tests
- Comparison with production baseline
Human intervention
- Review subjective outputs
- Decide ambiguous or business-critical cases
Main KPI Evaluation pass rate.
Risk accepted
Are data, security, policy and regulatory risks acceptable?
Accountable roles: Security, Legal or Compliance.
Autonomous evidence
- Personal-data and secret scanning
- Security and prohibited-content checks
- Policy-violation report
Human intervention
- Approve sensitive use cases
- Accept residual and regulatory risk
Main KPI Policy violations escaped.
Release authorized
Is the package safe to promote for its intended audience?
Accountable role: Release Owner.
Autonomous evidence
- Immutable version and metadata
- Permissions and documentation
- Rollback configuration
Human intervention
- Validate audience
- Approve material production impact
Main KPI Release lead time.
Production active
Did controlled distribution activate successfully?
Accountable roles: Release Owner and Customer Administrator.
Autonomous evidence
- Catalog and channel publication
- Canary rollout and smoke tests
- Deployment health signals
Human intervention
- Approve high-impact production releases
- Confirm first activation in a new context
Main KPI Deployment success rate.
Operation healthy
Are quality, SLA, drift and cost within limits?
Accountable role: Prompt Ops.
Autonomous evidence
- Quality, adoption, latency and cost monitoring
- Drift and incident detection
- Preapproved automatic rollback
Human intervention
- Respond when thresholds or SLAs are breached
- Correct, roll back, suspend or escalate
Main KPI Success rate and cost per outcome.
New version approved
Does the proposed change produce meaningful value uplift?
Accountable role: Product Owner.
Autonomous evidence
- Feedback clustering
- Improvement proposals
- Controlled experiment results
Human intervention
- Select improvements
- Accept material behavior changes
Main KPI Value uplift per version.
Retired safely
Can the capability be deprecated without losing control or continuity?
Accountable role: Business Owner.
Autonomous evidence
- Inactivity detection
- Obsolete dependency scan
- Duplicate and replacement analysis
Human intervention
- Approve deprecation or replacement
- Confirm retention of history and audit evidence
Main KPI Active prompt reuse rate.
Intervention policy by risk
Autonomy changes with consequence. The same technical workflow can operate under a different approval pattern when data, regulation, reversibility or customer impact changes.
Low risk
Fully autonomous flow; humans audit a sample.
Medium risk
Human approval at specification and release.
High risk
Domain, security and release approval required; no autonomous production deployment.
Stop first
Automatic suspension or rollback, followed by mandatory incident review.
Humans intervene whenever there is ambiguity, sensitive data, regulatory exposure, irreversible action, quality below threshold, unusual cost, model drift or material customer impact.
Runtime intervention rules
Factory gates control how a capability is produced. This matrix controls what the capability may do after deployment.
| Runtime action | Default autonomy |
|---|---|
| Search approved internal knowledge | Autonomous |
| Summarize or classify information | Autonomous with monitoring |
| Draft emails, reports or proposals | Autonomous draft; human decides use |
| Recommend a decision | Autonomous recommendation; human accountable |
| Update a reversible CRM field | Autonomous if preapproved and audited |
| Send external communication | Human approval initially |
| Publish public content | Human approval |
| Purchase, payment or financial commitment | Human approval |
| Delete records | Human approval |
| Change permissions or credentials | Human approval |
| Sign or accept contractual terms | Human only |
| Health, employment or credit decision | Human-controlled high-risk process |
| Switch to an already-certified model | Autonomous |
| Introduce a new model or tool | Human approval and reevaluation |
Mandatory escalation triggers
The runtime must stop or request human review whenever an execution leaves its approved purpose, evidence or operating envelope.
- Input is outside the approved purpose
- Sensitive data is detected unexpectedly
- An evaluation or confidence rule fails
- Model providers disagree materially
- A tool requests broader permissions
- An action is irreversible
- Cost exceeds the tenant budget
- Quality declines after a model change
- A user reports harm or serious error
- Cross-tenant access is attempted
- An unapproved model, tool or data source is requested
- Regulatory exposure is detected
- Model drift changes expected behavior
- Material customer impact is possible
For critical security events, the platform should block first and investigate second.
Policy for the first 10 clients
Early operation should favor evidence over speed. The autonomy envelope can expand only after the Factory has learned from real performance.
Conservative autonomy posture
- New or ambiguous demands receive Product Owner review at G0
- Medium-risk flows require human approval at specification and release
- High-risk flows require domain, security and release approval, with no autonomous production activation
- Autonomous prompt design remains inside the approved operating envelope
- Automated evaluation with mandatory human sample review
- First production batch reviewed intensively
- Sampling reduced only after sufficient performance evidence
- No autonomous introduction of models, tools or data sources
- Automatic suspension or rollback when critical thresholds fail
The accountability rule
As evidence accumulates, routine and reversible operations can move from A2 to A3. Purpose, risk acceptance, material scope changes and consequential actions stay attached to named people.
This is how the Factory gains speed without confusing execution with authority.
Machines can prepare, test, monitor, route and roll back. Humans remain responsible for why the capability exists, where it may operate and what consequences the organization accepts.