# INCU Process Manifest Template

**Status:** Reusable draft template<br>
**Governing standard:** [`INCU Master Constitution`](../INCU_Master_Constitution.md)<br>
**Runtime effect:** None<br>

> Use this template for any consequential workflow involving more than one
> component. A process is only as authorized as its least-authorized step.
> An approved process manifest never bypasses missing authority in a
> participating component manifest.

## Objective
- Business/user/system outcome
- A2HA parent ticket or project reference
- Completion definition and acceptance criteria

## Participants
- Orchestrator
- Required agents/tools/automations
- Human accountable owner
- External systems touched

## Sequence
1. Input and grounding
2. Analysis / planning
3. Approval checkpoint
4. Execution
5. Verification
6. Record in A2HA
7. Recovery / rollback

## Authority model
- Which participant can propose, approve, execute, verify, and record each step
- Required approvals and escalation routes

## Evidence model
- Evidence required at each transition
- Storage location and retention

## Failure model
- Retry limits
- Rollback plan
- Blocked state behavior
- Human escalation

## INCU activation
- Likely friction points
- Appropriate engagement levers
- Standard action-card and restart behavior

---

## Completion rules

- Every participating consequential component requires its own valid,
  in-scope component manifest.
- A process manifest cannot bypass a missing component-level authority.
- Every consequential execution step must name required evidence.
- Every external or irreversible action must name the exact approval gate.
- Completion cannot be claimed without the required verified evidence.
- This template does not itself grant authority, activate participants,
  or authorize execution.