Preserving the information available at a decision time

ShippedContent reviewed: 06 Sept 2026

The vintage path separates the period measured from the publication date of each available value and retains revision history.

A reference date identifies the period measured. A publication date identifies when a particular value became available. Filtering a revised series by reference date alone can introduce information that was unavailable at the decision time.

Alelyon’s vintage adapter distinguishes first release from the available revision sequence. A missing key or an initial fetch failure can produce an empty result with a diagnostic reason. An interrupted paginated fetch can return and cache partial rows, so a nonempty result does not establish complete coverage. Consumers must retain that limitation and must not substitute a current value under a historical label. The FRED real-time documentation explains the provider’s real-time interval semantics.

Consumer record

Retain source, series, reference period, requested as-of time, returned publication date, retrieval time, and data-quality status. Establish timezone and release time separately when an intraday decision depends on them. Revision discipline covers one information boundary; it does not model liquidity, fills, or transaction costs. See the integration guide.

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.