Client deliverables and example outputs

The deliverable is a reviewed explanation of the business record and the next decision. A client should be able to understand it without learning the application’s database structure. Keep the structured files available for reviewers who need traceability.

Package choices

What is in an approved client ZIP

client-report.html is the readable report. It uses a self-contained print layout and can be opened without the application. Use the browser’s Print / Save as PDF function for a paper copy.

report.json is the structured frozen packet. It contains the company scope, report audience and purpose, selected record fields, source revision, coverage and limitations.

record-register.csv is a concise index of type, title, version, state and record ID. READ-ME.md explains the audience and manual-delivery boundary. checksums.json lists SHA-256 hashes for the other UTF-8 files and the report record hash. A checksum detects changed bytes; it is not an independent approval signature or proof of who sent a file.

Raw source text, recordings, passwords, invitation tokens and person email fields are excluded by the client-report serializer. An advisor can still accidentally include sensitive details in a free-text summary or selected analysis. Inspect those fields before approving.

The supplied Northstar examples

The portable handbook’s example index contains three actual API-generated client ZIPs and their readable HTML reports: executive, weekly and audit. It also contains the confirmed-work internal package and an agent-proposal internal package. The training manifest identifies the fictional company and the record states used to produce them.

These files were generated by creating a separate sandbox company, enrolling fictional participants through the local API, submitting and accepting exact confirmation responses, reviewing work and handoffs, recording manual cases, and approving the report audience/content. They were not hand-drawn mockups. No real participant decision or customer result is asserted.

The example shows four roster people, three Human confirmed tasks, one complete manual case, one case needing attention, and an Inconclusive outcome. The fictional median changed from ten to eight hours but missed a seven-hour target, with unmatched cohorts and missing staffing information. This is the kind of limitation the client should see clearly.

Example executive message

“We have documented the standard-order flow and clarified the receiving checks between intake, credit review and release. The reviewed record identifies one incomplete case that needs Jamie’s attention. Incomplete intake remains a candidate explanation for delay; the current practice observations do not establish causation. We recommend collecting a matched cohort before expanding the change. All release decisions remain with people.”

For the supplied training packet, retain the explicit notice that all people and observations are fictional. In a real engagement, replace the language only with claims supported by that client’s reviewed sources and actual measurements.

A useful delivery checklist

1. Confirm the named audience and purpose match the agreed engagement scope.
2. Confirm the company, date, source revision and selected records are correct.
3. Check that claimed confirmations and observations match their current states.
4. Explain missing coverage, conflicting sources, confounders and open decisions.
5. Remove unnecessary personal or sensitive details from authored narrative.
6. Preview the exact packet and record the approval rationale.
7. Download, open and inspect the readable report and register.
8. Deliver through the approved channel and record recipient, version and date.
9. Keep the original ZIP and checksums with the distribution record.
10. Regenerate and review a fresh report after material source changes.

The application performs the binding and state checks. The advisor remains responsible for the business meaning of the narrative, appropriate audience, and actual delivery decision.

Suggested delivery meeting

Allow 30–45 minutes. Begin with the client’s desired outcome and the bounded scope. Show the work description and evidence only to the depth needed for the decision. Explain the strongest remaining uncertainty. Compare the prediction with observations, then agree the next action, owner and review date.

Use the graph to answer a relationship question, not as a decorative proof that the company is understood. Use the report’s selected records when the audience needs a stable reference. Finish with a written list of commitments and the limits of any proposed automation.

Handoff to an implementation team

Provide the relevant confirmed-work or agent proposal package along with the approved scope, source policy and unresolved authority questions. The implementation team needs a separate accepted identity/permission model, exact target resources/actions, approval chain, runtime adapter and operational controls before any live execution.

Do not distribute the complete development repository as the ordinary client report. Source code and technical runbooks are a developer/operator handoff. Do not include .env, database backups, encryption keys, raw recordings or commercial reference documents in a public repository or generic client packet.