SAYLOR The result you are building
Finished Result:
A qualification record and paid discovery package that verifies identity and decision authority, defines the current problem and value, inventories constraints and dependencies, exposes risk, and produces a go/no-go proposal with testable scope.
Use this guide when
- A prospect requests custom software or automation with vague requirements.
- Identity, company, payment ability, decision authority, or technical feasibility is unclear.
- A fixed quote would require guessing.
Do not use it as a substitute for
- Providing a full custom solution design for free to an unverified lead.
- Treating urgency, enthusiasm, or a partial payment as proof of identity, authority, or reliable collection.
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 person/company/contact, billing identity, jurisdiction, and decision authority.
- Problem statement, current workflow, users, impact, alternatives, and evidence.
- Budget range, payment path, deadline driver, stakeholders, and approval process.
- Systems, data, accounts, providers, constraints, security, and compliance needs.
- Discovery deliverables, exclusions, confidentiality, price, acceptance, and go/no-go criteria.
Stop Before Proceeding:
Do not grant repository, production, customer-data, wallet, domain, or privileged account access based on an unverified identity or before written authority and payment conditions are established.
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.
Qualification protects both parties A no-go can save the buyer from an unsuitable project and the seller from unpaid, unauthorized, or impossible work.
Discovery is a deliverable When uncertainty materially affects architecture, scope, price, or risk, sell a bounded evidence package rather than hiding guesses inside a fixed estimate.
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
Prospect will not Identity/trust Verify billing entity, domain, Collection, authority, and dispute risk are high.
identify company role, and references
'Simple' request has Complexity Map systems, owners, data, Hidden dependencies make fixed quote unreliable.
many integrations APIs, and acceptance
No one owns Decision Identify signer, operator, and Project may finish technically but never be accepted or paid.
acceptance process approver
Deadline has no Priority Ask what changes if date Urgency may be negotiation pressure rather than operational
event behind it moves constraint.
Budget far below Fit/economics Offer narrower result or Proceeding would require unsafe scope cuts or unpaid work.
required result discovery; compare
alternativesStep-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 Verify the prospect and authority Why: A precise boundary prevents a plausible fix from solving the wrong problem.
Do: Confirm legal/billing identity, domain/contact, role, decision power, payment method, jurisdiction, and who owns accounts/data. Use proportionate checks.
Read the result: You know who can sign, pay, grant access, and accept.
Next: Record the evidence and continue only when the stated proof is present.
02 Define the business problem Why: Symptoms are not enough; a baseline preserves the evidence needed to isolate the failing layer.
Do: Document current process, users, frequency, pain, cost/risk, trigger, desired outcome, alternative, and what evidence would prove value.
Read the result: The problem is more specific than a requested technology.
Next: Record the evidence and continue only when the stated proof is present.
03 Map stakeholders and decisions Why: Inconsistent inputs create false differences and make later comparisons unreliable.
Do: Identify economic buyer, operator, technical owner, security/privacy reviewer, approver, and blockers. Record decision timeline and communication path.
Read the result: Required decisions have named owners and dates.
Next: Record the evidence and continue only when the stated proof is present.
04 Inventory technical and data reality Why: A decisive test reduces trial-and-error and limits unnecessary change.
Do: List systems, versions, APIs, credentials ownership, data volumes/classes, environments, providers, constraints, prior attempts, and access limitations.
Read the result: Major feasibility and authority risks are visible.
Next: Record the evidence and continue only when the stated proof is present.
Procedure continued 05 Choose quote or paid discovery Why: The smallest reversible correction lowers the blast radius while preserving a recovery path.
Do: Quote a standard product only when inputs and variation are bounded. Otherwise define discovery questions, methods, artifacts, time, price, exclusions, and acceptance.
Read the result: Discovery has a useful standalone result even if the build is no-go.
Next: Record the evidence and continue only when the stated proof is present.
06 Set commercial and access boundaries Why: The happy path cannot expose replay, timeout, malformed-input, authority, or dependency failures.
Do: Use written scope, confidentiality, deposit/milestones, non-refundable discovery as lawful/appropriate, expiration, change path, and staged least-privileged access. Never accept secret material by chat.
Read the result: Work and access exposure match collected payment and verified need.
Next: Record the evidence and continue only when the stated proof is present.
07 Issue evidence-backed go/no-go Why: A result is not complete until it remains observable and repeatable after the immediate fix.
Do: Deliver current-state map, requirements, risks, options, assumptions, acceptance tests, estimate range, dependencies, and next decision. State no-go honestly.
Read the result: Client can choose using evidence and neither party is trapped by hidden assumptions.
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 person/company/contact, billing identity, jurisdiction, and decision authority.
- Problem statement, current workflow, users, impact, alternatives, and evidence.
- Budget range, payment path, deadline driver, stakeholders, and approval process.
- Systems, data, accounts, providers, constraints, security, and compliance needs.
- Discovery deliverables, exclusions, confidentiality, price, acceptance, and go/no-go criteria.
Acceptance scoreboard
- Legal/billing identity, contact, role, authority, jurisdiction, and payment path are verified proportionately.
- Problem, current process, value, alternatives, and success evidence are documented.
- Stakeholders, decisions, deadline driver, budget, and blockers have owners.
- Systems, data, access, providers, constraints, and prior attempts are inventoried.
- Quote versus paid discovery decision follows bounded uncertainty.
- Commercial terms, staged access, go/no-go, and next action are documented.
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 client qualification and paid discovery 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 Discord contact in Spain asks for an $1,800 wallet-monitoring tool, pays $180, and receives a private repo link before identity and acceptance are documented.
Evidence collected
- Only a first name and chat handle are known.
- No verified company or billing address is recorded.
- Ten percent is paid.
- Repository access may allow full download before final payment.
Decision Commercial leverage and identity evidence are weak. Preserve records, stop expanding access, and move to written qualification, acceptance, invoice, and milestone conditions without sabotage or retaliation.
Actions taken
- Captured agreement, messages, payment, repo invitation, and release hash.
- Requested verified billing identity and acceptance owner.
- Defined demo, acceptance tests, final transfer, and payment deadline.
- Changed future process to deposit, milestones, and gated handoff.
Proof Of Completion:
Future custom work begins only after verified identity/authority, paid discovery or deposit, written acceptance, and staged access; this project has a documented lawful collection/handoff path.
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.
- Legal/billing identity, contact, role, authority, jurisdiction, and payment path are verified proportionately.
- Problem, current process, value, alternatives, and success evidence are documented.
- Stakeholders, decisions, deadline driver, budget, and blockers have owners.
- Systems, data, access, providers, constraints, and prior attempts are inventoried.
- Quote versus paid discovery decision follows bounded uncertainty.
- Commercial terms, staged access, go/no-go, and next action are documented.
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
Prospect will not identify Collection, authority, and dispute risk Verify billing entity, domain, role, and references company are high.
'Simple' request has many Hidden dependencies make fixed quote Map systems, owners, data, APIs, and acceptance integrations unreliable.
No one owns acceptance Project may finish technically but never Identify signer, operator, and approver be accepted or paid.
Deadline has no event behind Urgency may be negotiation pressure Ask what changes if date moves it rather than operational constraint.
Reusable handoff record
- Versioned client qualification and paid discovery 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.ftc.gov/business-guidance/small-businesses
- https://www.sba.gov/business-guide/manage-your-business/prepare-your-business-emergencies
- https://www.cisa.gov/topics/cyber-threats-and-advisories/supply-chain