# GPU Acceptance Report — Capordia template v1

Initial state: NOT EXECUTED. An empty box never counts as compliance.

## 1. Reference and decision to be made

- Internal case reference:
- Version of this document:
- Scope of the requested authorization (trial, specific queue, defined production):
- Decision owner and alternate:
- Date and time zone of the decision:
- Final decision: [ ] blocked [ ] refused [ ] accepted within defined scope [ ] accepted with documented reservation
- Reason, limits, and controls justifying the decision:

## 2. Expected result

- Completed unit of work:
- List of expected outputs and business criterion:
- Usual load and representative case selected:
- Volume, precision, batch size, and concurrency:
- Maximum project deadline, if it is a criterion:
- Numerical tolerance or comparison rule:
- Cases deliberately excluded from scope and justification:

## 3. Three levels of evidence

### Manufacturer reference

- Model and variant under consideration:
- Official URL and date consulted:
- Memory stated per card and unit:
- Properties relevant to the workload:

### Environment actually allocated

- Model(s), private survey identifiers, and count visible from the application:
- Survey context (host, container, other):
- Sharing or partitioning, if applicable, and accessible scope:
- System, driver, runtime, and application with versions:
- CPU and system memory required for the project, to be confirmed:
- Volumes, available space, permissions, and paths:
- Network flows, destinations, and access:
- Topology required for the workload, verification method, and exhibit:

Do not infer any property of the machine from the GPU name alone. Keep sensitive identifiers and logs in an authorized location; the public exhibit may be redacted.

### Actual acceptance task

- Identifier and version of the authorized test set:
- Manifest or input fingerprints:
- Code version and parameters:
- Launch command:
- Expected outputs and logs:
- Measurement method, unit, and observation period:
- Failures, repetitions, and initial state:
- Business check and the person who performed it:
- Export check from the final destination:
- Recovery test, if required:

## 4. Responsibilities

| Role | Holder | Alternate | Evidence the role is accountable for |
|---|---|---|---|
| Project owner | | | Criteria and final decision |
| Application owner | | | Versions, launch, load, and recovery |
| Operations | | | Access, inventory, volumes, and transfer |
| Results owner | | | Quality, presence, and readability of outputs |
| Records owner | | | Retrieval and filing of exhibits |

Keep only the information needed for handover here, never secret values.

## 5. Checklist and exhibits

Attach `grille-reception-vierge.csv` after adaptation. Use a stable exhibit reference in each row.

- Authorized location of the evidence folder:
- Naming rule:
- List of redacted exhibits that may be shared:
- Checks not performed and reason:
- Blocking criteria not met:

## 6. Reservations and refusals

| Check | Deviation | Use allowed during the reservation | Action | Holder | Due date | Evidence of clearance |
|---|---|---|---|---|---|---|
| | | | | | | |

An unmet mandatory condition blocks the scope concerned. A reservation does not replace mandatory evidence. Any waiver or removal of a check must be dated and approved for a specific use.

## 7. Handover and closure

- Operations repeated the launch from the procedure:
- Outputs were opened from their storage destination:
- Recovery was repeated if required:
- Migration log reference if necessary:
- Next event requiring a new acceptance:
- Authorized signatory:
- Date and time zone:
- Decision and authorized scope:

Technical acceptance is distinct from order and payment statuses.