Pilot Packet

A pilot is useful only when it can stop itself.

This packet defines the safe bridge from public demos to a bounded private pilot. It asks for synthetic examples or fully redacted public-safe summaries and explicit stop rules, not raw logs, credentials, customer data, financial execution logic, private execution records, or deployment authority.

scope proof repair no-go pilot

Run mini gate first Briefing route Claim boundaries

Authority guard visual for proof-carrying action systems.

Pilot Shape

Four artifacts, not a vague call.

A proof-carrying pilot should produce a small evidence package that a critic can inspect. It does not need live deployment, sensitive data, or permission to act in the world.

toy or fully redacted workflow summary -> evidence state -> action warrant -> receipt gap board -> no-credit repair queue

If the pilot cannot create these objects, the correct conclusion is not a sales promise. The correct conclusion is a no-go report with named missing proof.

What To Prepare

Send only material that can safely be audited.

The best pilot packet is small, boring, and strict. It should let the system demonstrate restraint, evidence accounting, repair discipline, and claim boundaries before anyone discusses integration.

PartAllowed InputExpected OutputDo Not Send

WorkflowOne toy or fully redacted task-flow summary with roles and decision pointsState machine and authority boundaryRaw customer workflows

Evidence3 to 10 synthetic traces or fully redacted public-safe summariesEvidence state and missing-proof listCredentials, API keys, raw PII, raw customer logs

ActionCandidate action classes and stop conditionsActionWarrant sketch and no-go criteriaLive execution permissions

ReceiptWhat would count as entry, exit, terminal, wait, and counterfactual receiptsReceipt closure gap boardRaw private execution certificates

LearningKnown failures and safe toy counterexamplesNo-credit repair queue and clean/dirty labelsRaw private incident logs

Acceptance Test

The pilot passes only if it can explain at least one allowed action, one no-go action, and one repair-only state without awarding hidden authority or hidden credit.

authority_leak = 0
credit_leak = 0
repair_credit = 0 until evidence closes

Minimum Evidence

Each action candidate needs a thesis, falsifier, threshold, null arm, receipt requirement, and counterfactual route. Weak evidence should create repair work, not confidence.

thesis + falsifier + nulls
+ receipt envelope
+ no-go boundary

Failure Output

A no-go output is a valid pilot result when it names the exact missing proof and produces a bounded repair path. The pilot is not required to make the system look ready.

NO_GO_PROOF_NOT_CLOSED
REPAIR_ONLY_NO_CREDIT

Pilot Timeline

A tight pilot should expose truth quickly.

WindowWorkDeliverableStop Condition

Day 0Scope one task and remove sensitive materialBoundary noteGoal cannot be stated as evidence

Day 1 to 3Map evidence, authority, receipts, and nullsProof envelopeInputs require secrets or live authority

Day 4 to 7Run toy gate on synthetic or fully redacted tracesNo-go/gate reportAuthority leak or credit leak appears

Day 8 to 14Close one gap and rerunRepair delta reportRepair cannot produce closed evidence

Boundary

The pilot is not a shortcut to deployment. It is a way to find out whether the system knows why it is not yet allowed to act.

Public artifacts show schemas and demo behavior. Private pilots may inspect sensitive workflows only inside customer-controlled environments under explicit boundaries. The project does not request customer secrets, raw logs, regulated advice authority, trading execution logic, or private agent orchestration through this public route.