Capstone Final Dossier Template
What you hand to the client and to whoever maintains the network after you. Assume a competent reader who was not in the room and cannot ask questions — anything only you know is lost.
1. Cover and summary
| Field | Entry |
|---|---|
| Client, site | |
| Prepared by, date, version | |
| Status (as-built/proposed) |
Executive summary — six lines, no jargon. What was built, what it now does that it did not, what was found and fixed, what is open.
2. Requirements traceability
Every requirement from the brief, with the evidence that closes it. "Met" with no pointer to evidence counts as not met.
| # | Requirement | How it is met | Evidence (file/§) | Status |
|---|---|---|---|---|
3. Topology diagrams
Physical — every device by name and location, the ports and cables joining them, the riser, uplinks and access points.
Logical — segments, gateways, where routing happens, where the internet edge and translation sit, which segments talk to which. Traffic, not furniture.
Both diagrams here, titled, dated, with a legend.
4. Addressing
The as-built table. If the build differs from the design by one address, this table wins and the difference is noted.
| VLAN | Name | Network | Usable range | Gateway | DHCP scope | Notes |
|---|---|---|---|---|---|---|
5. Configuration record
One block per device: hostname, role, management address, and the configuration that matters — VLANs, ports, trunks, routing, address services, translation, wireless and firewall rules. Paste real configuration, not a description; mark later changes.
| Device | Role | Management address | Config file / section |
|---|---|---|---|
6. Verification evidence
The completed checklist, the ping matrix and every captured output, captioned with the requirement each proves, in checklist order.
7. Fault reports
One form per fault, written so someone else could repeat the diagnosis. The interesting part is not the fix but how you narrowed it down.
Fault report 1
| Field | Entry |
|---|---|
| Ticket as received (words + time) | |
| Isolation - what worked, what did not | |
| What changed | |
| Probable cause | |
| Fix applied (one change at a time) | |
| Verification (complaint gone) | |
| Prevention note |
Fault report 2
| Field | Entry |
|---|---|
| Ticket as received | |
| Isolation - what worked, what did not | |
| What changed | |
| Probable cause | |
| Fix applied | |
| Verification | |
| Prevention |
Fault report 3
| Field | Entry |
|---|---|
| Ticket as received | |
| Isolation - what worked, what did not | |
| What changed | |
| Probable cause | |
| Fix applied | |
| Verification | |
| Prevention |
8. Security review
| # | Control | State | Evidence or gap |
|---|---|---|---|
| 1 | Guest isolated from every internal segment | ||
| 2 | Cameras have no route to or from the internet | ||
| 3 | Default credentials changed everywhere | ||
| 4 | Management restricted; unreachable from guest/internet | ||
| 5 | Wireless and guest SSID security as designed | ||
| 6 | Unused switch ports disabled/parked | ||
| 7 | Remote access encrypted and authenticated | ||
| 8 | Firmware current; config backups kept off-device |
State: met, partial, not met. Close with what remains weak, why it was accepted and what fixing it would take.
9. Assumptions and limitations
Carry the design log forward with what the build taught you and what you could not test.
10. Handover
- Where the documentation lives, who holds the master copy, and how credentials are stored and rotated.
- The three things most likely to break first, and the first check for each.
- What is updated here when the network changes — same sitting, not later.
Network Essentials · Capstone · Turning Point Academy — backbone: Al-Doori, Network Essentials, Ch. 1-15.