SAYLOR Translate a project promise into deliverables, responsibilities, environments, tests, milestones, exclusions, and documented acceptance evidence.
The result you're building
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.
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
| Evidence | Likely layer | First decisive check | What the result means |
|---|---|---|---|
| Client says feature was implied | Scope/exclusion | Map request to deliverable, assumption, and change record | Description is ambiguous or required behavior was never resolved. |
| Work passes demo but not production | Environment/acceptance | Compare test environment, data, load, accounts, and dependencies | Acceptance did not specify the real operating context. |
| Final payment disputed | Milestone/evidence | Inspect submission, test, rejection, cure, and acceptance record | Payment trigger is subjective or undocumented. |
| Client delays inputs | Responsibility/ schedule | Check owner, due date, dependency, and pause rule | Timeline assigns output dates but not client prerequisites. |
| Repo delivered, ownership unclear | IP/handoff | Review license/assignment and payment condition | Possession of files is being confused with contractual rights. |
Step-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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
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
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.
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 implied | Description is ambiguous or required behavior was never resolved. | Map request to deliverable, assumption, and change record |
| Work passes demo but not production | Acceptance did not specify the real operating context. | Compare test environment, data, load, accounts, and dependencies |
| Final payment disputed | Payment trigger is subjective or undocumented. | Inspect submission, test, rejection, cure, and acceptance record |
| Client delays inputs | Timeline assigns output dates but not client prerequisites. | Check owner, due date, dependency, and pause rule |
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. |
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