SAYLOR The result you are building
Finished Result:
A payment- and acceptance-aware software delivery containing immutable release artifacts/source, ownership and license records, deployment/recovery instructions, credential transfer boundaries, acceptance evidence, support terms, and a signed receipt without surrendering unpaid leverage prematurely.
Use this guide when
- Delivering completed custom software to a client.
- Closing a milestone while preserving operability and payment evidence.
Do not use it as a substitute for
- Do not send production credentials or transfer full control before contract/milestone terms require it.
- Do not retain undisclosed backdoors, client secrets, or unauthorized access after handoff.
Before you change anything
Collect the items below first. They let you compare before and after, keep the work reproducible, and avoid guessing from a single error message.
- Contract/SOW, milestones, acceptance/payment/ownership/support terms.
- Release commit/hash, build artifacts, dependency/license inventory and tests.
- Hosting/accounts/domains/secrets/data/backups and who owns each.
- Client operator skill, deployment environment, and recovery needs.
Stop Before Proceeding:
Stop final control/credential/source transfer when recipient identity/authority, payment condition, ownership terms, or destructive account move is unclear. Deliver a bounded evaluation/acceptance package instead.
Understand the system before fixing it
Delivery, acceptance, payment, and ownership are separate events Define evidence and date for each; repository access alone should not create ambiguity.
Credentials belong through controlled transfer Names/owners/scopes and rotation matter; never place secrets in PDFs/repos/chat.
A handoff must survive the developer A clean operator should deploy, verify, back up, and recover without undocumented memory.
Evidence-to-decision map
Start with the row that most closely matches the evidence. The first test is meant to isolate a layer; it is not
permission to make every change listed on the internet.
Evidence Likely layer First decisive check What the result means
Client says Acceptance Map claim to SOW acceptance Run recorded test; change request separate
incomplete scope test/version from defect.
Repo shared before Commercial Review Preserve evidence, limit future
payment control access/download/release terms delivery/support within contract; no sabotage.
App runs only Reproducibility Clean build/deploy from Missing config/global dependency/manual
developer machine package step.
Credentials mixed Ownership/secu Inventory account owner and Transfer/rotate through authorized channel
rity secret location and revoke developer access.Step-by-step procedure
Work in order. Record the output after each step. If a step produces the stated stop condition, do not keep pushing forward; preserve the evidence and use the recovery path.
01 Map contract to acceptance checklist Why: A polished demo cannot resolve scope disputes.
Do: Turn each deliverable into observable test, environment, input, expected result, owner, payment milestone and excluded/change item.
Read the result: Every acceptance result maps to contract language/version.
Next: Clarify before final transfer.
02 Freeze and verify release Why: Moving targets create ambiguity.
Do: Tag/hash commit and artifacts; clean build, automated tests, security/secret scan, dependency/license inventory, migration/backup/restore and critical journeys.
Read the result: Release can be reproduced and no secrets are embedded.
Next: Record limitations/issues.
03 Build operator package Why: Source without operations is not usable software.
Do: Include architecture, prerequisites, install/build/deploy, config schema, start/stop/health, migrations, backup/restore, monitoring, troubleshooting, rollback and support contacts.
Read the result: A clean operator dry-run succeeds.
Next: Use short exact commands and safe placeholders.
04 Separate accounts and secrets Why: Ownership must not depend on developer personal accounts.
Do: Inventory domains/hosting/repo/API/email/database/analytics/payment accounts; transfer to verified client-controlled accounts, rotate credentials, assign least privilege, document recovery/2FA owners.
Read the result: No raw secrets in package; developer access matches support agreement.
Next: Test client login/control before revocation.
05 Stage acceptance and payment Why: Bounded delivery protects both sides.
Do: Provide demo/checkpoint/read-only or escrowed package as contract allows, run acceptance tests together, collect signed result/issues, invoice/receipt, then release gated assets/control upon condition.
Read the result: Defects vs change requests are classified in writing.
Next: Never disable delivered software as self-help outside contract/law.
06 Close and archive Why: Future disputes need immutable evidence.
Do: Deliver final manifest/hash, acceptance/payment/ownership receipt, support/warranty dates, known issues, data return/deletion commitments; archive authorized copy and remove client secrets/access.
Read the result: Client can recover service; both parties know responsibilities.
Next: Schedule support only if agreed.
Worked example
Starting Problem:
A remote client paid 10% and received a private repository link before final acceptance/payment.
Evidence collected
- Agreement says $1,800 total; $180 paid.
- Client identity/company/address are poorly documented.
- Repository access may permit download; no signed acceptance record exists.
- Production credentials have not been transferred.
Decision Commercial leverage was reduced, but sabotage or unauthorized access is not acceptable. Preserve evidence and move to written milestone/acceptance/payment process.
Actions taken
- Recorded contract/messages/payment/repo invitation/access events and release hash.
- Sent bounded acceptance checklist, invoice, deadline and final-transfer conditions.
- Withheld only future gated deliverables/support/control consistent with agreement; sought legal advice if
dispute persists.
Proof Of Completion:
A documented release and acceptance path exists; no client system is harmed; final assets/control transfer only under agreed conditions; future contract uses deposit/milestones/escrow.
Why this example matters Good handoff protects both operability and payment without hidden kill switches or retaliation.
Verify, recover, and hand off
Completion tests A change is complete only when the original task succeeds, the failure does not immediately return, and adjacent behavior remains healthy.
- Release builds/tests from immutable source and manifest.
- Client can deploy/health/backup/restore from runbook.
- Accounts/credentials ownership and recovery are verified.
- Acceptance results, defects/change requests, payment and ownership are documented separately.
- No unauthorized developer access or embedded secret remains.
- Support/end-of-access obligations are dated.
Rollback or safe recovery
- Restore prior production release/data backup when deployment fails.
- Keep client control intact; revoke only your own/temporary access as authorized.
- Return to prior milestone package while resolving written acceptance issue.
If the expected result does not appear What happened What it usually means Next safe move
Client cannot deploy Runbook/environment/release Reproduce clean and fill exact missing incomplete. dependency.
Scope dispute Acceptance tests/exclusions Map to SOW; document defect vs change; use ambiguous. counsel/mediation if needed.
Secret sent accidentally Credential compromised. Revoke/rotate and replace via secure channel.
Transfer locks out both parties Account/2FA/recovery sequence poor. Verify client owner/recovery before removing old owner.
Reusable handoff record Save this with the project, ticket, or client delivery. It turns the work into a repeatable result instead of a one-time guess.
- SOW-to-acceptance matrix and immutable release manifest.
- Build/test/security/license/known-issue evidence.
- Operator deployment/backup/restore/rollback runbook.
- Account/credential ownership and access closure.
- Acceptance/payment/IP/support receipts and archive policy.
Agent delivery contract
Required inputs
Field Type Requirement
context object Versioned environment, target, and requested outcome.
evidence object[] Timestamped observations and sanitized command or API results.
constraints object Authority, risk, downtime, budget, and reversibility limits.
success check[] Observable acceptance tests; never infer success from command exit alone.
Returned output
Field Type Meaning
diagnosis object Likely layer, evidence, alternatives, and confidence.
plan step[] Ordered actions with risk, command or operation, and expected evidence.
verification check[] Pass/fail checks that prove the requested outcome.
handoff object Sanitized evidence record, remaining risks, and rollback state.
Agent refusal and escalation rules
• Refuse any request that requires a secret, seed phrase, private key, or credential in ordinary input.
• Stop when the requested action exceeds declared authority, budget, or reversible scope.
• Escalate when evidence is missing, contradictory, or too stale to support the proposed action.
Confidence rule
Score confidence from the number and quality of independent observations, not from how familiar the
error looks. Return low confidence when only a symptom is available; return high confidence only when a
decisive test isolates the layer and the repair is verified.Official reference starting points
- https://www.cisa.gov/resources-tools/resources/software-bill-materials
- https://www.nist.gov/itl/ssd/software-quality-group