Evidence required before applying a receipt in another domain

GatedContent reviewed: 06 Sept 2026

A new domain application needs a defined user decision, a covered uncertainty term, and evidence that the receipt helps with that decision.

A replay mechanism is a technical capability. To use it in a new domain, identify the decision a consumer makes, the inputs the consumer can independently obtain, and the particular claim the receipt can support. Then compare the proposed workflow with the methods the consumer already uses.

Prerequisites

Define the covered quantity and error terms, the trusted parties, and a concrete failure that would disprove the claimed benefit. Show how refusal, incomplete evidence, and revisions will be handled. A signing workflow must have separately authorized key custody and publication procedures.

This current note replaces an earlier narrative at the same route. It does not reissue that narrative’s referee verdicts or assert that a sector product has shipped. Use the trust guide to constrain an integration claim before proposing a domain-specific evaluation.

Choose your beta

One build. Two tiers.

The Windows build downloads with no sign-in, no LinkedIn and no key. Which tier you are in is decided when the app signs in: without a beta key you run everything locally, and a key — issued automatically to a signed-in, LinkedIn-verified account — is what adds Alelyon’s hosted DQC-OS.

Open beta

Run the app without a beta key.

There is one build, and this is the same one the closed beta uses — the tiers differ at sign-in, not at download. Sign in without a beta key and you get the local tier: Terminal UI, Lattice workspace, local calculator, and visible tool traces. A beta key is what adds hosted DQC-OS issuance.

  • Local-first Windows interface
  • Open Alelyon toolkit and source
  • No hosted backend entitlement

Windows 10 / 11, 64-bit · 0.6.1

Closed beta

Verify identity with LinkedIn to unlock hosted DQC-OS.

LinkedIn OpenID Connect verifies control of the LinkedIn account; Alelyon does not scrape your profile. It records a verified access request, and when you verify from your signed-in account page, your hosted DQC-OS key is issued automatically— no review, no queue, nobody to wait for. It does not create or sign you into an Alelyon account, and an anonymous verification issues no key: the key needs a signed-in account to attach to.

  • Everything in the open beta
  • Hosted deterministic DQC-OS calculations, unlocked by your key
  • Signed envelopes and certified answer paths

Signing up uses Alelyon’s own email-and-password account flow, which is separate from LinkedIn verification below. One Alelyon account signs you in to every Alelyon application, and it keeps working until you delete it. Verifying with LinkedIn comes next and links that identity to this account.

Verify with LinkedIn

Verify from your signed-in account page and your hosted DQC-OS key is issued automatically — it appears on that page the moment verification completes. Copy it into a password manager and enter it when Alelyon Terminal asks during sign-in; if it expires, opening your account page issues a fresh one.

Available now

Ask, and a person reads it.

Prefer to talk to someone first, or need access sooner than the self-serve paths allow? Ask directly.

Nothing about access waits on a person. The build downloads with no sign-in and no key; a hosted DQC-OS key is issued automatically when a signed-in account verifies with LinkedIn, and it appears on that account’s page. This address is for everything else — questions, problems, deletion requests, and anything a page cannot answer. It is read by a person, so no response time is promised.

Do not include credentials, account numbers, API keys, or position data in the message.