SAYLOR Sell and deliver files, guides, code, data, templates, or media with version identity, access control, license clarity, integrity, updates, refunds, and customer support.
The result you're building
A digital-product release pipeline that binds payment/order to the correct licensed artifact, verifies checksums and access, protects sensitive files, supports updates and revocation rules, and records delivery without misleading ownership claims.
Use this guide when
- You sell PDFs, code packages, datasets, templates, models, media, or agent outputs.
- Customers need a download or access after payment.
- Versions, third-party assets, licenses, or updates can cause confusion.
Do not use it as a substitute for
- Assuming a download transfers copyright or unrestricted resale rights.
- Using permanent public links or embedding purchaser credentials/secrets inside the product.
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.
- Product owner, title, version, artifact hash/size/type, release notes, and source manifest.
- Owned/third-party/open-source components, license compatibility, attribution, and resale/use terms.
- Price/order/payment/refund/tax/access duration/device/user/business rights.
- Delivery identity, signed/scoped link, expiration, download result, support, and update policy.
- Wrong-file, tamper, duplicate payment, link sharing, revocation, update, restore, and refund tests.
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.
Access, ownership, and license are different
A customer may own a physical copy or receive a download while copyright and granted use remain governed by the license and agreement.
The artifact is the product record
Bind title/version/hash/size/type/manifest to the order and receipt so support and disputes concern the same bytes.
Evidence-to-decision map
| Evidence | Likely layer | First decisive check | What the result means |
|---|---|---|---|
| Customer downloads wrong version | Catalog/release | Compare order product/version to artifact digest | Mutable path or stale catalog points to a different file. |
| ZIP contains secret file | Release hygiene | Scan manifest, archives, history, and generated output | Build package includes development or client material. |
| Buyer claims commercial use | License/checkout | Review displayed and accepted license version | Rights were missing, unclear, or changed after purchase. |
| Paid order has no download | Fulfillment | Correlate payment, order, entitlement, and delivery event | Payment and access are not an atomic/reconcilable workflow. |
| Public link spreads | Access model | Inspect link scope/expiry and referral pattern | Delivery uses bearer link with excessive lifetime or no entitlement check. |
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 — Define the product and rights
Why: A precise boundary prevents a plausible fix from solving the wrong problem.
Do: State title, outcome, included files/data, version, prerequisites, limitations, support, updates, refund policy, and personal/commercial/redistribution rights in plain language.
Read the result: A buyer can understand both value and prohibited use before payment.
Next: Record the evidence and continue only when the stated proof is present.
Step 02 — Audit ownership and dependencies
Why: Symptoms are not enough; a baseline preserves the evidence needed to isolate the failing layer.
Do: Inventory original content, contractors, client material, open-source software, fonts, images, trademarks, datasets, and required attribution or license notices.
Read the result: Every shipped component has a documented right and compatible obligation.
Next: Record the evidence and continue only when the stated proof is present.
Step 03 — Build a reproducible release
Why: Inconsistent inputs create false differences and make later comparisons unreliable.
Do: Generate from controlled source, scan secrets/malware, validate files, render/test, create manifest with version/checksum/size/type, release notes, and archive.
Read the result: The exact product can be rebuilt and independently verified.
Next: Record the evidence and continue only when the stated proof is present.
Step 04 — Bind checkout to entitlement
Why: A decisive test reduces trial-and-error and limits unnecessary change.
Do: Map product/version/license/price/order/payment/customer to a stable entitlement. Handle duplicate payment, refund, chargeback, taxes, and privacy intentionally.
Read the result: Payment and entitlement reconcile one-to-one or expose a visible exception.
Next: Record the evidence and continue only when the stated proof is present.
Step 05 — Deliver through scoped access
Why: The smallest reversible correction lowers the blast radius while preserving a recovery path.
Do: Use authenticated account or short-lived signed link, correct content disposition/type, download limits only if disclosed, and no customer secrets embedded in shared files.
Read the result: Authorized customer retrieves the exact checksum; unrelated users cannot.
Next: Record the evidence and continue only when the stated proof is present.
Step 06 — Manage updates and revocation
Why: The happy path cannot expose replay, timeout, malformed-input, authority, or dependency failures.
Do: Define whether updates are included, version notifications, compatibility, old-version access, critical fixes, refunds, and lawful revocation/chargeback behavior.
Read the result: Customers know which version and rights remain active.
Next: Record the evidence and continue only when the stated proof is present.
Step 07 — Verify support and recovery
Why: A result is not complete until it remains observable and repeatable after the immediate fix.
Do: Test purchase, duplicate, failure-after-payment, wrong file, expired link, refund, restore, corrupted artifact, and customer handoff. Track support issues by version.
Read the result: Every paid order receives or recovers the promised artifact and license record.
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.
- Product owner, title, version, artifact hash/size/type, release notes, and source manifest.
- Owned/third-party/open-source components, license compatibility, attribution, and resale/use terms.
- Price/order/payment/refund/tax/access duration/device/user/business rights.
- Delivery identity, signed/scoped link, expiration, download result, support, and update policy.
- Wrong-file, tamper, duplicate payment, link sharing, revocation, update, restore, and refund tests.
Acceptance scoreboard
- Product outcome, included files, prerequisites, limitations, support, updates, refund, and rights are clear.
- Ownership and third-party/open-source/data/font/image licenses are documented.
- Release is reproducible, validated, secret-free, versioned, hashed, and archived.
- Checkout/payment/order/entitlement/license reconcile.
- Authorized delivery returns the exact artifact and denies unrelated access.
- Duplicate, failure-after-payment, wrong-file, expiry, refund, update, and restore tests pass.
Minimum handoff record
- Versioned digital product delivery and licensing 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
guide.pdf in place, so earlier buyers cannot prove which version they purchased.Evidence collected
- All orders point to one mutable URL.
- Receipts show title but no version/hash.
- Content changes materially.
- Support cannot reproduce the old file.
Decision: Version the artifact and entitlement. Keep release manifests and state whether buyers receive updates or the purchased version only.
Actions taken
- Published immutable versioned filenames and hashes.
- Bound version/license to order receipt.
- Archived prior releases under policy.
- Added release notes and update entitlement.
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.
- Product outcome, included files, prerequisites, limitations, support, updates, refund, and rights are clear.
- Ownership and third-party/open-source/data/font/image licenses are documented.
- Release is reproducible, validated, secret-free, versioned, hashed, and archived.
- Checkout/payment/order/entitlement/license reconcile.
- Authorized delivery returns the exact artifact and denies unrelated access.
- Duplicate, failure-after-payment, wrong-file, expiry, refund, update, and restore tests pass.
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 |
|---|---|---|
| Customer downloads wrong version | Mutable path or stale catalog points to a different file. | Compare order product/version to artifact digest |
| ZIP contains secret file | Build package includes development or client material. | Scan manifest, archives, history, and generated output |
| Buyer claims commercial use | Rights were missing, unclear, or changed after purchase. | Review displayed and accepted license version |
| Paid order has no download | Payment and access are not anatomic/reconcilable workflow. | Correlate payment, order, entitlement, and delivery event |
Reusable handoff record
- Versioned digital product delivery and licensing 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