Commercial brief // bounded pilot path

Evaluate the path before committing to expansion.

A pilot is a time-boxed technical and buyer evaluation of a named use case across the public Conxian software surfaces. It should produce inspectable evidence, expose open gates, and end with a written decision. It is not a production-readiness certification or an open-ended access promise.

Discuss a pilot scope Back to the buyer brief Review packaging guidance

Pilot posture

One use case, named evidence, explicit stop conditions.

The written pilot scope should name the use case, environments, participants, start date, review points, end date, and decision owner before work begins. Any hosted access, payment behavior, support, or availability term must be separately confirmed and written.

Bounded duration Use time-boxed stages with an agreed end date; do not treat a pilot as indefinite access.

Evidence checkpoints Capture reproducible commands, artifacts, logs, device results, and open gates at each review.

Exit decision Stop, continue with a new scope, or move to contract discovery based on the evidence.

Recommended pilot scope

Keep the first engagement narrow enough to reproduce and review. The final scope is agreed with the customer rather than assumed from this page.

One named customer workflow and one decision owner.
Only the Gateway, Wallet, SDK, and Core surfaces needed for that workflow.
Controlled fixtures, test identities, or non-value-bearing data that the customer is authorized to use.
A named local, self-hosted, or explicitly provided evaluation environment.
A written evidence pack, open-gate register, and end-of-pilot decision.

Product boundaries in the pilot

Gateway // Beta

Integration rehearsal, not hosted settlement

Use the local or self-hosted developer path, or an instance explicitly provided for the pilot. Evidence may cover health, supported-chain discovery, and agreed local proof rehearsal. No generally available hosted endpoint or production settlement claim is part of the pilot by default.

Wallet // stable reference

Non-custodial Android-first client work

Evaluate the reference client and integration-to-launch path on agreed Android devices and environments. Keys and signing remain user-controlled. The pilot does not create custody, a hosted wallet service, or a mainnet-proof claim.

SDK // Beta / conditional

Local builder evaluation

Build and inspect the Conxius Enclave SDK against the use case and documented capability matrix. Record unsupported or quarantined areas. The pilot does not grant production readiness or provider enablement.

Core // live foundation

Shared API and fail-closed evidence

Use lib-conxian-core as the shared foundation for selected types, invariants, and verification boundaries. Launch and commercial gates remain in progress; Core is not a paid fourth tier or a substitute for dependent-surface evidence.

Required customer inputs

The customer owns the business context and must provide the inputs needed to make results meaningful.

Named use case, success owner, technical contact, security contact, and decision maker.
Target environments, supported devices, toolchain versions, network assumptions, and access constraints.
Authorized fixtures, identities, test data, and any data-handling or retention restrictions.
Security, procurement, legal, and compliance requirements that could change the pilot boundary.
Required evidence format, review cadence, end date, and the decision that the final review must support.

Measurable success criteria

Select only the criteria relevant to the written scope. Each criterion should have an owner, a reproducible method, and an evidence artifact.

The agreed integration path builds from a clean checkout on the named toolchain and commit.
The team reproduces the selected Gateway health, discovery, or proof-rehearsal flow in the named environment.
The Wallet reference flow completes on the agreed Android device set without transferring custody or signing control.
The SDK interface needed for the use case is exercised locally, with supported, conditional, and unsupported behavior recorded.
Core verification fixtures return the expected success or fail-closed result, with the test vector retained.
The final evidence pack records open gates, owner, next decision, and a recommendation to stop, continue, or scope a contract.

Time-boxed stages and checkpoints

The sequence below is a bounded template. The written scope sets the actual dates, participants, and entry or stop conditions.

Stage 0 // scope

Baseline and kickoff

Confirm the use case, surfaces, environments, inputs, evidence format, start date, review dates, end date, and stop conditions.

Stage 1 // local evaluation

Build and inspect

Reproduce local setup, inspect source and readiness documents, and record the first capability and security boundary results.

Stage 2 // bounded rehearsal

Exercise the workflow

Run only the agreed Gateway, Wallet, SDK, and Core flows with controlled fixtures and a mid-pilot evidence review.

Stage 3 // decision

Close with an exit path

Review measurable results, unresolved gates, customer fit, and the next decision before the agreed end date.

Evidence checkpoints

Kickoff: signed scope, repository commits, toolchain and device matrix, data boundary, and test plan.
Mid-pilot: reproducible commands, test outputs, screenshots or device results where relevant, and an updated open-gate register.
Final review: success-criteria results, known limitations, security and procurement notes, ownership of follow-up work, and exit recommendation.

Explicit non-goals

No production settlement, value-bearing signing, or unreviewed mainnet deployment.
No custody of funds, assets, private keys, or signing control.
No generally available hosted Gateway endpoint, blanket provider enablement, or adapter certification.
No uptime, SLA, operational guarantee, support response target, or compliance commitment unless separately written.
No custom protocol, broad chain expansion, or new commercial entitlement hidden inside the pilot.

Exit paths

Exit A // stop

Stop with evidence

Close the pilot when the use case is not a fit, a gate remains open, or the evidence does not justify further work. Retain the final record and no access assumption.

Exit B // continue

Run a new bounded scope

Continue only with a new scope that names the next capability, evidence, owner, dates, and stop conditions.

Exit C // contract discovery

Define institutional terms

Move to contract discovery for private deployment, procurement, support, compliance, or availability requirements. Those terms are not inherited automatically from the pilot.