SAYLOR The result you are building
Finished Result:
A statement-of-work operating matrix that connects each deliverable to owner, input, environment, acceptance test, due date, payment milestone, defect rule, change process, handoff, and support boundary.
Use this guide when
- You need to scope client software, websites, data, audits, or integrations.
- Disputes arise over what 'done' means.
- Payment and ownership depend on acceptance.
Do not use it as a substitute for
- Using a generic template without adapting it to the jurisdiction and actual deal.
- Relying on subjective satisfaction, a demo alone, or chat messages as the only acceptance mechanism.
Before you change anything
Collect these items first. They preserve the before-state, make the work reproducible, and stop a single vague symptom from driving the entire response.
- Verified parties, authority, addresses, jurisdiction, and notices.
- Proposal/requirements/version, deliverables, environments, inputs, and assumptions.
- Acceptance cases, expected results, evidence, tester, review period, and defect severity.
- Price, deposit, milestones, expenses, taxes, late/dispute process, and change orders.
- IP/license, accounts/data, confidentiality, security, warranty/support, termination, and handoff.
Stop Before Proceeding:
Do not sign or rely on this operational guide as legal advice. Obtain qualified counsel for material contracts, cross-border work, regulated data, ownership, liability, or collection risk.
Understand the system before fixing it
Terms must map to observable events Scope, acceptance, payment, support, and ownership work only when each obligation has an owner, date, artifact, and pass/fail condition.
Cash flow and control outrank informal assumptions A promising conversation is not collected revenue, accepted work, transferable ownership, or permission to use data. Record the actual state.
Acceptance is an operational protocol Define how a build is submitted, tested, rejected with evidence, corrected, re-tested, and deemed accepted or escalated under the actual agreement.
Defect and change are different A defect fails an agreed requirement; a change adds or alters one. The matrix must make classification traceable.
Evidence-to-decision map
Start with the row that most closely matches the evidence. The first test isolates a layer; it is not permission to
make every available change.
Evidence Likely layer First decisive check What the result means
Client says feature Scope/exclusio Map request to deliverable, Description is ambiguous or required behavior was never
was implied n assumption, and change record resolved.
Work passes demo Environment/a Compare test environment, Acceptance did not specify the real operating context.
but not production cceptance data, load, accounts, and
dependencies
Final payment Milestone/evid Inspect submission, test, Payment trigger is subjective or undocumented.
disputed ence rejection, cure, and acceptance
record
Client delays inputs Responsibility/ Check owner, due date, Timeline assigns output dates but not client prerequisites.
schedule dependency, and pause rule
Repo delivered, IP/handoff Review license/assignment and Possession of files is being confused with contractual rights.
ownership unclear payment conditionStep-by-step procedure
Work in order and retain the output from each step. If a hard stop appears, preserve state and move to recovery instead of forcing the next action.
01 Identify parties, authority, and precedence Why: A precise boundary prevents a plausible fix from solving the wrong problem.
Do: Use correct names/entities/contacts, verify signers, jurisdiction and notice path, and state which document/version controls conflicts. Flag counsel-required issues.
Read the result: Everyone knows who can bind, approve, pay, and receive notices.
Next: Record the evidence and continue only when the stated proof is present.
02 Define outcome, deliverables, and exclusions Why: Symptoms are not enough; a baseline preserves the evidence needed to isolate the failing layer.
Do: Describe each artifact/service, environment, version, quantity, format, dependencies, assumptions, non-goals, and third-party responsibility in plain language.
Read the result: A reviewer can distinguish included work from an add-on.
Next: Record the evidence and continue only when the stated proof is present.
03 Build the acceptance matrix Why: Inconsistent inputs create false differences and make later comparisons unreliable.
Do: For each deliverable, specify ID, input, setup, test, expected result, evidence, tester, review window, defect severity, cure/retest, and acceptance record.
Read the result: Done is observable and reproducible.
Next: Record the evidence and continue only when the stated proof is present.
04 Connect schedule and responsibilities Why: A decisive test reduces trial-and-error and limits unnecessary change.
Do: Map milestones to both supplier and client inputs/decisions/access, dependencies, delay/pause rules, and updated dates. Avoid dates that assume unowned prerequisites.
Read the result: A delay can be assigned to a missing dependency rather than argument.
Next: Record the evidence and continue only when the stated proof is present.
Procedure continued 05 Connect payment and changes Why: The smallest reversible correction lowers the blast radius while preserving a recovery path.
Do: Set price, deposit, milestone triggers, expenses, taxes/fees, invoice due, dispute path, and written change-order fields for scope/time/price/acceptance impact.
Read the result: Every payment maps to accepted evidence or an explicitly agreed event.
Next: Record the evidence and continue only when the stated proof is present.
06 Define ownership, access, and lifecycle Why: The happy path cannot expose replay, timeout, malformed-input, authority, or dependency failures.
Do: Address pre-existing tools, custom work, third-party licenses, accounts, credentials, data return/deletion, confidentiality, security, warranty, support, termination, and transition.
Read the result: Handoff does not depend on personal accounts or hidden access.
Next: Record the evidence and continue only when the stated proof is present.
07 Run a pre-sign operational review Why: A result is not complete until it remains observable and repeatable after the immediate fix.
Do: Have delivery, client operator, security/data owner, finance, and counsel where appropriate walk through edge cases, rejection, termination, and handoff.
Read the result: The signed operating model is feasible and all material unknowns are resolved or priced.
Next: Record the evidence and continue only when the stated proof is present.
Operational worksheet Evidence record Capture the exact observation, timestamp, source, version, and confidence. Sanitize credentials and personal data before sharing the record.
- Verified parties, authority, addresses, jurisdiction, and notices.
- Proposal/requirements/version, deliverables, environments, inputs, and assumptions.
- Acceptance cases, expected results, evidence, tester, review period, and defect severity.
- Price, deposit, milestones, expenses, taxes, late/dispute process, and change orders.
- IP/license, accounts/data, confidentiality, security, warranty/support, termination, and handoff.
Acceptance scoreboard
- Parties, authority, contacts, jurisdiction, notices, and document precedence are verified.
- Deliverables, versions, environments, quantities, assumptions, dependencies, and exclusions are explicit.
- Every deliverable maps to reproducible acceptance evidence and a review/cure process.
- Client and supplier responsibilities drive schedule and pause behavior.
- Payment, disputes, defects, changes, ownership, and handoff have clear triggers.
- Operational and qualified legal review cover material edge cases before signature.
Decision rule SHIP / AUTOMATE GATE Proceed only when every required acceptance check is supported by direct evidence, rollback is available, and the remaining risk is explicitly owned. Unknown is not a pass.
Minimum handoff record
- Versioned statement of work and acceptance matrix scope, owner, exclusions, and success criteria.
- Sanitized evidence snapshot with source, time, version, and confidence.
- Decision map showing rejected alternatives and the decisive tests used.
- Ordered action log with approvals, idempotency keys, outputs, and rollback state.
- Acceptance results, remaining risks, review date, and escalation owner.
Worked example
Starting Problem:
A client says a Telegram bot should support Ethereum and Base although the signed list names only Solana.
Evidence collected
- Deliverable says 'wallet launch monitor' in summary.
- Technical appendix lists Solana sources only.
- Acceptance tests cover Solana.
- No cross-chain change order exists.
Decision The summary is ambiguous but the acceptance appendix supports Solana scope. Resolve in writing and price a cross-chain change rather than coding first and debating later.
Actions taken
- Mapped request to deliverable and test IDs.
- Clarified chain matrix and exclusions.
- Issued change order with dependencies, price, schedule, and tests.
- Updated the controlled specification version.
Proof Of Completion:
Both parties can run the final chain-by-chain acceptance matrix, and payment/change status is documented without relying on memory.
Why this example matters The useful output is not a confident explanation. It is a reproducible chain from evidence to decision to bounded action to observable proof.
Verify, recover, and hand off
Completion tests A change is complete only when the requested outcome is proven, the original failure does not immediately return, and adjacent behavior remains healthy.
- Parties, authority, contacts, jurisdiction, notices, and document precedence are verified.
- Deliverables, versions, environments, quantities, assumptions, dependencies, and exclusions are explicit.
- Every deliverable maps to reproducible acceptance evidence and a review/cure process.
- Client and supplier responsibilities drive schedule and pause behavior.
- Payment, disputes, defects, changes, ownership, and handoff have clear triggers.
- Operational and qualified legal review cover material edge cases before signature.
Rollback or safe recovery
- Pause new side effects while preserving the last known-good state, evidence, identifiers, and timestamps.
- Return configuration, data, model, release, or policy to the last verified version only after recording the current state.
- Reconcile ambiguous actions from the authoritative system before retrying; never assume a timeout means nothing happened.
- Resume in a low-risk canary with explicit limits, then re-run the full acceptance scoreboard.
If the expected result does not appear What happened What it usually means Next safe move
Client says feature was Description is ambiguous or required Map request to deliverable, assumption, and change record implied behavior was never resolved.
Work passes demo but not Acceptance did not specify the real Compare test environment, data, load, accounts, and production operating context. dependencies
Final payment disputed Payment trigger is subjective or Inspect submission, test, rejection, cure, and acceptance record undocumented.
Client delays inputs Timeline assigns output dates but not Check owner, due date, dependency, and pause rule client prerequisites.
Reusable handoff record
- Versioned statement of work and acceptance matrix scope, owner, exclusions, and success criteria.
- Sanitized evidence snapshot with source, time, version, and confidence.
- Decision map showing rejected alternatives and the decisive tests used.
- Ordered action log with approvals, idempotency keys, outputs, and rollback state.
- Acceptance results, remaining risks, review date, and escalation owner.
Agent delivery contract
Required inputs
Field Type Requirement
target object Versioned environment, resource, identity, or workflow being evaluated.
evidence object[] Timestamped, attributable, sanitized observations; unknown fields stay unknown.
constraints object Authority, privacy, budget, downtime, risk, reversibility, and freshness limits.
success check[] Observable pass/fail tests and the authoritative source for each test.
Returned output
Field Type Requirement
diagnosis object Likely layer, supporting and conflicting evidence, alternatives, and confidence.
plan step[] Ordered bounded actions with owner, risk, expected proof, and stop condition.
verification check[] Observed pass/fail/unknown results, not inferred success from command exit alone.
handoff object Sanitized evidence record, recovery state, remaining risk, and next review trigger.
Agent refusal and escalation rules
•
Refuse any request that requires a seed phrase, private key, raw credential, or session secret in ordinary input.
•
Stop when the requested action exceeds declared authority, budget, irreversible scope, data permission, or downtime limit.
•
Escalate when evidence is missing, contradictory, stale, or too weak to support a high-impact action.
•
Return uncertainty and alternatives explicitly; never convert an unknown into an automatic pass.
Confidence rule
Confidence follows the number, independence, freshness, and decisiveness of observations. Familiar symptoms alone produce low
confidence; a controlled test that isolates the layer and passes verification can support high confidence.Official reference starting points
- https://www.nist.gov/itl/ssd/software-quality-group
- https://www.copyright.gov/circs/circ01.pdf
- https://www.ftc.gov/business-guidance