POLICY-FIRST AI FEATURE SPEC (TEMPLATE)

Use this template to turn an “AI idea” into something you can ship, operate, and sell to serious customers.

1) FEATURE STATEMENT (ONE SENTENCE)
- What user role is this for?
- What outcome does it produce?
- What system(s) does it touch (docs, CRM, ticketing, code, payments)?

2) ACTORS & IDENTITY
- Acting principal: end-user / service account / delegated role
- Roles involved (examples): support_agent, sales_rep, engineer, admin
- Authentication inputs: SSO? API token? session?
- Delegation rules: can the AI act “as the user” or only “on behalf of” with limited scopes?

3) DATA BOUNDARIES (READ)
- Allowed sources (name each): internal docs, knowledge base, ticket history, CRM objects
- Disallowed sources: list explicitly (HR files, payroll, legal, raw chats, etc.)
- Redaction requirements: what must be removed before sending to a model?
- Retention stance: what must be logged vs. what must be minimized/redacted?

4) ACTION CATALOG (WRITE)
List every external side effect as a named action.
- Action name: e.g., crm.update_contact
 - Resource type: contact
 - Allowed fields: (list)
 - Disallowed fields: (list)
- Action name: email.send
 - Recipient constraints: internal-only? customer domains?
 - Attachments allowed? Y/N

5) POLICY TIERS (ENFORCEABLE)
Define three tiers for each action:
- ALWAYS ALLOW: low-risk actions (typically read, draft, classify)
- ALLOW WITH APPROVAL: actions with meaningful consequence (send, publish, update)
- NEVER ALLOW: actions you will not permit via AI
For approvals, specify who approves (user, manager, admin) and what evidence they see.

6) RUNTIME ENFORCEMENT POINTS
Where will policy be checked?
- Before retrieval (connector/retriever)
- Before tool execution (tool executor/workflow engine)
- Before output (UI/export)
State what happens on deny (block, degrade to draft-only, request approval).

7) EVIDENCE & AUDIT LOG REQUIREMENTS
For every run, record:
- Actor identity + role
- Policy version applied
- Model + configuration (model name, tool list, prompt version)
- Retrieval sources (document IDs/URLs) and redaction events
- Tool calls (name, arguments, results) and approvals
- Final output (or hashed reference if storage is sensitive)
Define retention period and access controls for logs.

8) ADMIN UX REQUIREMENTS
What can an admin configure without engineering?
- Enable/disable tools
- Set approval thresholds
- Restrict data sources by group/role
- Export audit logs
- Incident kill-switch (disable a feature/org-wide)

9) TEST PLAN (NON-NEGOTIABLE)
- Negative tests: attempts to access disallowed data; attempts to execute denied actions
- Prompt injection tests for your retrieval sources
- Regression: policy version change does not silently widen access
- Replay: can you reconstruct “what happened” from logs?

DONE CHECK:
If you cannot answer (a) who can do what, (b) with which data, (c) under what conditions, and (d) what evidence you’ll have later — the feature is not ready to ship.