Testing API

DVM-SL scenario testing

The DVM Scenario Language (DVM-SL) defines a customer release scenario as a virtual quorum world, selected score, mobile participant, execution plan, expectations, and formal target in a single .dvms file.

Use DVM-SL when a customer acceptance scenario spans iOS or Android SDK behavior, one-device quorum participation, DVM execution, publication gates, evidence, and optional K checks. The scenario becomes a versioned artifact that support, security, mobile, and protocol teams can review together.

Every scenario moves through a fixed pipeline: author the .dvms source, parse it to DvmslScenario, lower it to the canonical ScenarioDoc, compile a backend plan, run a native or formal target, and emit a structured report with mobile binding, publication, evidence, and expectation results.

Authoring model

A DVM-SL document has six top-level blocks: world, score, hooks, run, expect, and formal. The format is reviewable by product teams, bindable to debugger scores by runtime engineers, and mappable to K fixtures by formal engineers from one source of record.

The scenario name gives the artifact a stable customer label. world defines engine, peers, roles, threshold, key, lane, setup, aggregator, and mobile participants. score selects an existing debugger scenario. hooks injects faults and intercepts runtime calls before execution begins. run drives deterministic execution, restarts, and reconnects. expect states lifecycle fields, publication fields, artifacts, evidence, mobile binding, and instruction-site predicates. formal attaches a K family, mode, checks, negatives, and comparison axes.

Customer mobile acceptance path

A mobile signing scenario that survives an app restart is the customer-facing baseline. It exercises parser, IR, native runner, mobile role binding, vault preservation, lifecycle projection, artifact projection, evidence projection, and publication state.

Mobile release scenario

dvms

scenario "mobile wallet signing survives app restart"

world {
  engine cluster
  peer api roles [api, signer, agg]
  peer cosigner roles [signer]
  peer phone roles [signer, mobile]
  threshold 2/3
  setup precomputed-setup
  lane 42
  key "customer-wallet-main"
  agg api
}

score {
  use scenario "ClusterDkls23_3Of3"
}

hooks {
  on call kind=bind-decision peer phone => restart phone preserve [vault, keyshare]
}

run {
  continue until quiescent
  reconnect phone
  continue until complete
}

expect {
  lifecycle.state == Published
  publication.state == Published
  artifact kind="SignaturePublic" present
  evidence class="MobileNodeReceipt" present
  receipt.mobile_binding stable
}

Mobile coverage model

A mobile participant is modeled as a peer with mobile in its roles. The same world can also mark api, signer, and agg roles, so one scenario captures a phone party, server co-signers, and the aggregator that publishes the result.

hooks target local runtime calls such as BindDecision, PrepareStep, AdvanceStep, PublishGate, AbortSession, and GetStatus. run can restart or reconnect the phone while preserving vault and keyshare state. expect can bind the final report to mobile receipts, device binding, publication state, and customer-visible artifacts.

Mobile-specific controls

dvms

scenario "mobile publication hold"

world {
  engine cluster
  peer api roles [api, signer, agg]
  peer cloud roles [signer]
  peer phone roles [signer, mobile]
  threshold 2/3
  key "customer-wallet-main"
  agg api
}

hooks {
  on call kind=bind-decision peer phone => restart phone preserve [vault, keyshare]
  on call kind=publish-gate peer api => deny code "CUSTOMER_REVIEW_HOLD"
}

run {
  continue until quiescent
  reconnect phone
  continue until terminal
}

expect {
  evidence class="MobileNodeReceipt" present
  receipt.mobile_binding stable
  publication.state == Denied
}