# Custom AI build brief

## Job and evidence

- User and actual task:
- Decision the output supports:
- Current method:
- Representative permitted input:
- Useful output example:
- Measured problems and evidence:
- Alternatives considered: manual, existing feature, connection, ordinary rule, or custom build.
- Reason the proposed build is useful:

## Bounded scope

- Smallest deliverable:
- Included work:
- Non-goals and excluded work:
- Inputs and authoritative sources:
- Output format and destination:
- Users and account owners:
- Source collection and data permissions:
- Private data removed from examples:
- Allowed actions:
- Actions held for a person:
- Missing access or decisions:
- Provider/configuration requirements and unknowns:
- Current costs, source dates, and estimates:

## Acceptance and handoff

- Observable done checks:
- Representative test set:
- Unacceptable behavior:
- Typical, sparse, ambiguous, invalid, sensitive, and replay cases:
- Failure, retry, partial-write, and recovery behavior:
- Stop and manual fallback:
- Evidence in the intended environment:
- Documentation and account ownership:
- Maintenance owner:
- Future changes excluded or separately scoped:

## Scope prompt

```text
Turn this task into a bounded build brief.
Task and current process: [PASTE]
Verified facts, permitted inputs, and output example: [PASTE]
Constraints and access: [PASTE]

Compare keeping the manual method, using an existing feature, a simple connection, and a custom build. Do not assume AI is necessary.
Define included deliverable, exclusions, inputs, output, users, allowed actions, dependencies, acceptance checks, and handoff. Mark missing information unknown. Do not invent a price, deadline, vendor capability, customer result, or permission.
```

## Evaluation prompt

```text
Design a representative test set for this brief.
Brief: [PASTE]
Permitted example inputs: [PASTE]

For each case, specify input, expected behavior, unacceptable behavior, evidence to inspect, and responsible reviewer. Include ordinary work, sparse input, an unsupported claim, a failed source, a sensitive-data request, and a duplicate action where relevant.
Keep factual quality and operational completion separate. Do not create a success score without a defined denominator and criteria. Return unresolved policy questions.
```

## Constructed research-brief example

Job: prepare a short draft from an approved list of public category sources.
Input: actual fetched material, source URL, document date, collection date, and question ID.
Output: a brief linking each material claim to its source, with gaps and interpretation separate.
Exclusions: automatic publication, external messaging, private source access, and product-development work.
Success case: a documented relevant change becomes a linked finding with its date and limitation.
Missing source: explicit gap, with no invented summary.
Unsupported number: omit or hold for verification.
Quiet week: say no supported change was found.
Untrusted instruction in a page: treat as source text; do not obey an instruction to reveal secrets or change accounts.
Handoff: owner can run, inspect, pause, recover, and update the permitted source list.

This is a teaching design, not a built customer integration or performance result. Replace assumptions before turning it into a real scope.