Skip to content
Gestalt

Pilot terms and excluded operations

Status: customer boundary doc. Required topic pilot_terms_and_excluded_operations from contracts/production-admission.v0.json customer_boundary_lane.required_doc_topics.

What a pilot admission record covers

Section titled “What a pilot admission record covers”

A pilot admission record is the only thing that can move an operation from candidate_pending to admitted. The record names a single explicit boundary, and the central evaluator refuses anything outside it.

The required fields are listed in contracts/production-admission.v0.json pilot_admission_lane.signed_record_required_fields and include:

  • tenant, company, jurisdiction, vertical
  • package_id_and_epoch, connector_id, effect_class
  • admitted_operations, excluded_operations, timeframe
  • signer, key_custody_refs, standing_refs, mandate_refs, human_auth_refs
  • restore_rehearsal_ref, incident_rehearsal_ref, proof_bundle_ref
  • public_claim_posture

A signed record without all of these refuses with production_pilot_admission_unsigned or another stable code from pilot_admission_lane.evaluator_pilot_refusals.

What a pilot admission record does not cover

Section titled “What a pilot admission record does not cover”

The pilot lane is intentionally narrow:

  • Only the operations in admitted_operations are admitted. Every other operation continues to refuse production admission. This is enforced by admitted_operations_only: true and global_refusal_for_everything_outside: true in the contract.
  • The pilot admission record cannot enable a broader marketing or positioning claim. The runtime keeps public_launch_claim_remains_refused set to true for the pilot lane.
  • Period close is candidate-only in v0. The economy.periodClose operation is fixture-rehearsed per operation_maturity, and a pilot admission cannot move it to authentic in v0.
  • A pilot admission record does not enable raw data classes. The refusals on raw register, raw credential secret, raw biometric, and raw payload classes hold regardless of what the pilot record says.

Excluded operations by construction

Section titled “Excluded operations by construction”

The following are never in scope for a v0 pilot admission record:

  • Operations labelled shape-only in operation_maturity (the contract and types exist; no consequence is recorded). Examples today: tenant.self, humanAuth.faceMatchFallback, receipt.verify, proof.request, refusal.codes, refusal.registry.
  • Operations that the customer has not exercised through the prerequisite gates listed in pilot_admission_lane.all_prior_phase_gates_must_pass. These include real tenant company lifecycle, production session, production WebAuthn HumanAuth, identity binding, standing, mandate, package trust, key custody, connector consent witness, effect idempotency when dispatch admitted, proof verification, restore proof, ops posture, and legal/support/privacy boundary docs.
  • Anything the customer has not asked for. Admission is opt-in per operation, not blanket.

Pilot terms summary

Section titled “Pilot terms summary”

A pilot customer accepts that:

  1. Only the operations in the signed admission record are admitted.
  2. Every other operation continues to refuse, and the refusal is the correct response.
  3. A refusal is governed; a refusal is not a failure to render.
  4. Revocation of the pilot admission record is supported and is durable across runtime restarts.
  5. Sealed proof bundles emitted during the pilot timeframe are non-amendable; revocation does not rewrite history.
  6. The runtime, not this document, is the source of truth. If this document and the contract disagree, the contract wins.

See also

Section titled “See also”