Post-Pilot Lessons Learned
The signed post-pilot lessons-learned template. Five sections, ten rows each, two reviewers, one signed PDF. Designed to be filled in the 30 minutes after pilot close, then archived into the evidence-room bundle.
Purpose of this template
A lessons-learned document is the most undervalued artefact in a pilot cycle. This template forces a structured reflection without dragging the owner into a multi-day debrief. Five sections, ten rows each, two reviewers, one signed PDF.
- Fill the template within 30 minutes of pilot close. Wait longer and the lessons fade.
- Each row must contain one concrete fact, not a vague aspiration.
- The two reviewers should be the pilot owner and a buyer-side named contact.
- The signed PDF is part of the evidence-room bundle and travels with every future pilot reference.
- If the pilot failed, write that down explicitly. Honest failure rows are the highest-value lessons.
Section 1 - What we said we would do
The first section is the agreed scope from the contract award letter and the day-0 runbook. Use it as the baseline.
| Row | Committed outcome | Owner | Date committed |
|---|---|---|---|
| 1.1 | Work package 1 - evidence and controls delivered. | Owner | Day 0 |
| 1.2 | Work package 2 - public-source integration demo operational. | Owner | Day 0 |
| 1.3 | Work package 3 - assurance and procurement route signed off. | Owner | Day 0 |
| 1.4 | OSCAL-ready control map attached to evidence-room bundle. | Owner | Day 15 |
| 1.5 | Human oversight log maintained for every AI-assisted recommendation. | Owner + Buyer | Day 0 |
| 1.6 | Red-line register signed and reviewed at every decision gate. | Owner | Day 0 |
| 1.7 | Named buyer stakeholder trained to use the audit log. | Owner | Day 30 |
| 1.8 | All pilot pages and evidence artefacts return HTTP 200 from canonical URLs. | Owner | Day 0 |
| 1.9 | Midpoint review held with named buyer contact. | Owner + Buyer | Day 30 |
| 1.10 | Final go or no-go report issued to buyer. | Owner | Day 90 |
Section 2 - What actually happened
The second section is the actual delivery against the baseline. Each row states the gap and the evidence reference.
| Row | Outcome delivered | Gap vs commitment | Evidence ref |
|---|---|---|---|
| 2.1 | |||
| 2.2 | |||
| 2.3 | |||
| 2.4 | |||
| 2.5 | |||
| 2.6 | |||
| 2.7 | |||
| 2.8 | |||
| 2.9 | |||
| 2.10 |
Section 3 - What worked
The third section is the things that worked and should be repeated in the next pilot. Be specific about why each thing worked.
| Row | What worked | Why it worked | Reusable pattern |
|---|---|---|---|
| 3.1 | |||
| 3.2 | |||
| 3.3 | |||
| 3.4 | |||
| 3.5 | |||
| 3.6 | |||
| 3.7 | |||
| 3.8 | |||
| 3.9 | |||
| 3.10 |
Section 4 - What did not work
The fourth section is the things that did not work and should not be repeated. Be specific about why each thing failed.
| Row | What failed | Why it failed | Replacement pattern |
|---|---|---|---|
| 4.1 | |||
| 4.2 | |||
| 4.3 | |||
| 4.4 | |||
| 4.5 | |||
| 4.6 | |||
| 4.7 | |||
| 4.8 | |||
| 4.9 | |||
| 4.10 |
Section 5 - What we will do differently next time
The fifth section is the changes that will be made in the next pilot cycle. Each row should be a concrete, dated commitment.
| Row | Change | Owner | Date to apply |
|---|---|---|---|
| 5.1 | |||
| 5.2 | |||
| 5.3 | |||
| 5.4 | |||
| 5.5 | |||
| 5.6 | |||
| 5.7 | |||
| 5.8 | |||
| 5.9 | |||
| 5.10 |
Reviewer sign-off
Both reviewers must sign before this document joins the evidence-room bundle.
| Reviewer role | Name | Date | Signature |
|---|---|---|---|
| Pilot owner | |||
| Buyer-side named contact |
Where this artefact travels
The signed lessons-learned PDF becomes a permanent part of the evidence-room bundle and is referenced in every future pilot of the same buyer or framework route.
- Reference path: /defoneos-mod-post-pilot-lessons-learned.html with the signed PDF linked as evidence-room artefact.
- Renewal pack: lessons-learned is attached to the renewal upsell playbook for the 30 days before close.
- Framework route pack: lessons-learned is referenced in any framework listing submission as proof of delivery discipline.
- Prime referral pack: lessons-learned travels with any prime referral letter as proof of structured reflection.
- Annual review: lessons-learned is reviewed once a year to identify patterns across multiple pilots.
12-framework crosswalk
Every page in this tick is written as an owner-executable artefact and an audit trail. These mappings are design mappings, not third-party certifications.
| Framework | How this page maps | Honesty status |
|---|---|---|
| EU AI Act | Transparency, human oversight, logging, post-market monitoring, and high-risk discipline when a workflow crosses into regulated public-service use. | Designed control language. Verify per-buyer before external submission. |
| GDPR and UK GDPR | Data minimisation, lawful basis notes, retention windows, subject-access response path, and no personal-surveillance pattern. | Designed control language. Verify per-buyer before external submission. |
| JSP 936 | Assurance case language, operator accountability, safety case evidence, and escalation logging suitable for UK defence AI review. | Designed control language. Verify per-buyer before external submission. |
| JSP 440 | Protective marking, supplier-security posture, evidence handling, and separation of public facts from owner-gated sensitive data. | Designed control language. Verify per-buyer before external submission. |
| NIST AI RMF | Map, Measure, Manage, and Govern rows for every buyer artefact, with clear residual-risk ownership. | Designed control language. Verify per-buyer before external submission. |
| ISO 42001 | AI management-system controls, role ownership, change control, review cadence, and documented competence. | Designed control language. Verify per-buyer before external submission. |
| NIST PQC | Cryptographic-agility language, no false PQC certification claim, and upgrade path for signed evidence bundles. | Designed control language. Verify per-buyer before external submission. |
| NATO STANAG | Interoperability language only, no NATO endorsement claim, and neutral alliance-compatible evidence formatting. | Designed control language. Verify per-buyer before external submission. |
| AUKUS Pillar II | AUKUS-compatible technology framing only, no partnership claim unless a signed letter exists. | Designed control language. Verify per-buyer before external submission. |
| OSCAL | Machine-readable control catalogue and component-definition path for the evidence room. | Designed control language. Verify per-buyer before external submission. |
| Five Eyes export discipline | Public-source and EAR/ITAR awareness note, no controlled technical data in this page. | Designed control language. Verify per-buyer before external submission. |
| C2PA 2.0 | Content provenance, artefact signing, and media lineage notation for decks, screenshots, and demo recordings. | Designed control language. Verify per-buyer before external submission. |
Honesty register
The register below is deliberately explicit so this page stays usable in a UK-sovereign procurement conversation without overclaiming.
- This page is an executable template, not legal advice and not a procurement submission.
- AUKUS-compatible means design compatibility only. No AUKUS partnership is claimed without a signed letter on file.
- DEFONEOS-SEAL is not issued here. Any credential requires the 33-agent BFT council quorum and owner gate.
- No kinetic-targeting, find-fix-finish, kill-order, face-recognition, phone-location, or individual-tracking pattern is included.
- Buyer names and public bodies are routing examples from public procurement context. Nick must verify the current named contact before sending.
- SIGIL anchor is local until the SOV3 ledger endpoint is reachable from this Mac session.
- Generated 2026-07-12T08:35:00Z. File slug: defoneos-mod-post-pilot-lessons-learned.