Make Freelance Deliveries Reviewable
Last updated: 2026-07-163 min read
A freelancer can make one delivery reviewable with a bounded handoff record: agreed scope, immutable change reference, exact checks and observed outcomes, open limits, and a named decision. It documents work; it does not guarantee code quality, acceptance, payment, or a legal outcome.
Contents
Start with the agreement and the accountable roles
The useful unit is one delivered change, not a general assurance about a developer. Before work starts, identify who confirms the task and exclusions, who prepares the change, who reviews it and who can accept it under the contract. A contractor may perform several of those activities, but the record should not imply independent review when none occurred.
BSI/ANSSI recommends checking generated source code and keeping developers able to reproduce it. That technical guidance supports recording checks; it does not define a client acceptance standard or establish quality. Acceptance criteria remain specific to the task and agreement.
Use a handoff template that cannot impersonate a result
The sample contains placeholders, including failed and not-run states. Copy its structure, then fill it from the real commit, command output and review decision. Link receipts rather than replacing them with a summary that says everything passed.
Illustrative handoff template - not proof of quality
handoff-template.mdtext/markdown
Illustrative sample · no client outcome# Handoff · <change ID> · <date>
## Agreed task
Goal: <observable goal>
Scope: <agreed paths and exclusions>
Criteria: <testable criteria>
## Observed change
Commit/diff: <immutable reference>
Files: <observed list>
## Checks executed
Command: <exact command>
Outcome: <passed | failed | not run>
Receipt: <reference or "not available">
## Limits and open items
- <not checked, reason, accountable role>
## Handoff decision
Prepared by: <contractor/role>
Reviewed by: <name/role or "no independent review">
Decision: <accepted | changes requested | open>Read every field at its actual support level
Scope records what was agreed, not whether the requirement was complete. A commit identifies the delivered version, not authorship or correctness. A check receipt covers its command, environment and criteria, not every quality property. A decision records accountability, not a waiver or independent assurance.
Field, owner and evidence boundary
| Task | Change | Checks | Decision | |
|---|---|---|---|---|
| Accountable role | Client/employer confirms need and scope; contractor records itEditorial control mapping · 2026-07-16Roles follow the contract and working model; the sample assigns no legal role. | Contractor references the delivered commit/diffEditorial control mapping · 2026-07-16Roles follow the contract and working model; the sample assigns no legal role. | Runner records; reviewer assesses adequacyEditorial control mapping · 2026-07-16Roles follow the contract and working model; the sample assigns no legal role. | Contractually named acceptance or review roleEditorial control mapping · 2026-07-16Roles follow the contract and working model; the sample assigns no legal role. |
| Can establish | Agreed goal and boundariesEditorial control mapping · 2026-07-16Applies only to the referenced record. | Which version and files were handed overEditorial control mapping · 2026-07-16Applies only to the referenced record. | Which command produced which observed outcomeBSI/ANSSI - AI coding-assistant recommendations (2024) · 2026-07-16Technical guidance to check generated code; not a client promise or quality guarantee. | Who recorded which status and whenEditorial control mapping · 2026-07-16Applies only to the referenced record. |
| Does not establish | Not that the requirement is complete or correctEditorial control mapping · 2026-07-16Additional review or contractual assessment remains necessary. | Not defect-free code or authorship of every lineEditorial control mapping · 2026-07-16Additional review or contractual assessment remains necessary. | Not complete quality, security or complianceEditorial control mapping · 2026-07-16Additional review or contractual assessment remains necessary. | Not a liability waiver, legal effect or independent assuranceEditorial control mapping · 2026-07-16Additional review or contractual assessment remains necessary. |
A defensible handoff provides
- Agreed scope
- Immutable change reference
- Observed check outcomes
- Explicit limits and decision
It does not promise
- Defect-free code
- Faster acceptance or payment
- Reduced liability or disputes
- Superior quality over competitors
Fit the record to the delivery workflow
Store the handoff beside the immutable change or in the client-approved delivery system. Keep technical detail available through linked receipts while making scope and open items readable. The deeper evidence-report structure explains how task, change, validation and decision records relate without turning one artifact into proof of the whole system.
Reality Graph can retain those records as part of a run, and keep every run of a project in one local workspace so a delivery is not reconstructed from memory months later. The same limit applies: generated output is useful only when it references real execution, preserves failures and names the person or role making the decision.
FAQ
- How can a freelancer make delivered code quality reviewable?
- Attach a bounded handoff record to a real change: the agreed task and exclusions, immutable commit or diff, exact checks and observed outcomes, anything not checked, and the named review or acceptance decision. The record makes those facts reviewable; it does not prove defect-free code or replace the client's acceptance process.
- Who owns each part of the handoff?
- The client or employer confirms the need, scope and contractual acceptance role. The contractor records the delivered change and checks actually run. The named reviewer or acceptance role records the decision. The exact allocation follows the contract and working model, not this template.
- Does a passing test record prove code quality?
- No. It establishes that named commands produced recorded outcomes for a referenced version and environment. It does not establish complete correctness, security, maintainability, compliance, authorship or suitability beyond the covered criteria.
- Should the record contain only passing checks?
- No. Failed, skipped and unavailable checks are material facts. Pre-filling successful outcomes or hiding omissions turns a useful handoff into an unreliable assertion.
- Does a handoff record reduce liability or payment disputes?
- That cannot be promised. It can preserve agreed scope and observed work, but contractual effect, acceptance, liability and payment depend on the agreement, governing law and facts. Seek legal advice for those questions.
- Do freelancers need special software for this?
- No. A Markdown record and immutable repository references can work. Automation is useful only when it preserves the same truth standard: real execution, visible failures, explicit omissions and a named decision.