# Project discovery brief

## Problem and consequence
- Product or workflow and its users:
- Observed problem, with a recent example:
- Consequence for users or the delivery team:
- What a useful first improvement would look like:

## Current arrangement
- Existing application / stack / integrations:
- Available requirements, tests and operational evidence:
- Team ownership and decision makers:
- Reviewable preview or redacted artifact:
- Data classification and access constraints:

## Constraints
- Fixed date and why it is fixed:
- Scope that must remain unchanged:
- Budget range or spending limit:
- Supported clients, roles and organisations:
- External approvals or specialist reviews required:

## First engagement
- Decision to support: diagnose / test / build / evaluate / hand over
- Proposed smallest useful scope:
- Expected artifact and acceptance criteria:
- Exclusions:
- Who reviews the result:
- What would make further work unnecessary:

## AI workflow, if relevant
- Inputs, desired output and permitted actions:
- Independent examples of good and unacceptable results:
- Human approval and fallback:
- Provider, data handling and operating costs to investigate:

Example — fictional: a team wants reliable invitation releases. The first scope is a focused review of the invitation journeys, role boundaries and test data. The deliverable is a plan, reproducible findings and a summary for the release owner. Billing, a full security assessment and an application rewrite are excluded. The team decides whether a wider automation engagement is justified after reviewing that evidence.

Keep secrets and personal records out of the brief. Describe the approved access arrangement and provide sensitive evidence later through the agreed channel.