# Start your AI project specification

Preparation workflow, 5 October 2026 edition. Kit examples are fictional. No completion time or business outcome is promised.

Start with `08-dossier.pdf`: six pages covering the completed case, acceptance, proposals and time calculation. Then open `08-modele.docx` in your word processor and work on a copy: three pages bring together the requirement, tests and supplier response.

The `.md` files are supporting material readable in a text editor; the longer template expands each section. Open `.csv` files in a spreadsheet. Do not replace unknowns with zero.

## Prepare the first working session

Bring together the person handling the cases and the person authorising access to the tools. Prepare one representative request, its expected output, an incomplete case and an ambiguous case. Use fictional files or files authorised for sharing. You do not need to select a model for this session.

1. Complete the first page of `08-modele.docx`: outcome, scope and data. Use the longer `08-modele.md` for further guidance. If colleagues expect different outputs, resolve that before requesting an implementation quotation.
2. Work through `08-cas-test.md`. Adapt its seven cases to your data and record requirements in `08-recette.csv`. Decide expected results before testing; leave observations empty until a test has actually run.
3. Complete operation and exit arrangements. Name who handles a case when the tool or approver is unavailable. Include access dependencies in the schedule.
4. Give every unknown an owner and a due date. Ask suppliers to price its resolution explicitly if it belongs to their scoping work.
5. Send suppliers the same version and attachments. Use `08-comparer-offres.md` to record responses without treating promises as evidence.

## What can you request now?

| Dossier state | Useful next request |
|---|---|
| Outcome or sources still undefined | Scoping work with explicit deliverables and boundaries; implementation fixed prices cannot yet be assumed comparable |
| Outcome and sources described, some assumptions unresolved | A conditional proposal pricing scoping and naming implementation assumptions |
| Scope, permissions, exceptions, acceptance and responsibilities sufficiently defined | A pilot quotation tied to this version, with exclusions, dependencies and itemised prices |

An empty field for write permission, sharing authorisation or an approval decision-maker blocks that part of the work. Unknown volume can justify pricing several scenarios; actual volumes still require measurement. These rules prepare a discussion, not purchasing certification.

## Check that someone can understand it without you

Give a copy to a colleague who did not write it. Ask them to find the expected output, a prohibited action, the handling of an ambiguous customer and the decision-maker after an outage. If they need to ask you, clarify the document. Keep the questions they encounter. This is a reader exercise, not a business-owner study already performed to validate this guide.

## Files to send

- The completed, dated and versioned template.
- An authorised input and expected output, including the reference records needed to interpret them.
- Acceptance cases, blocking criteria and responsible people.
- Open questions, volume assumptions and access constraints.
- A request to respond using the common comparison grid.

Keep a validation dataset separate from examples used to tune the solution. This educational kit teaches the method; it is not that independent business dataset.