SAYLOR Deliver completed software with acceptance evidence, deployment instructions, credential boundaries, ownership records, support terms, and a recoverable release package.
The result you're building
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.
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
| Evidence | Likely layer | First decisive check | What the result means |
|---|---|---|---|
| Client says incomplete | Acceptance scope | Map claim to SOW acceptance test/version | Run recorded test; change request separate from defect. |
| Repo shared before payment | Commercial control | Review access/download/release terms | Preserve evidence, limit future delivery/support within contract; no sabotage. |
| App runs only developer machine | Reproducibility | Clean build/deploy from package | Missing config/global dependency/manual step. |
| Credentials mixed | Ownership/security | Inventory account owner and secret location | Transfer/rotate through authorized channel 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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 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
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.
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 incomplete. | Reproduce clean and fill exact missing dependency. |
| Scope dispute | Acceptance tests/exclusions ambiguous. | Map to SOW; document defect vs change; use 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