What protects the record. What still needs evidence.
Helix applies separate controls to account access, signed evidence, custody and physical observations. Understanding those controls helps you decide what a verification result can support.
Begin with the trust decision.
A signature can be mathematically correct under a key supplied by an attacker. Helix therefore distinguishes record integrity from issuer authority. A verifier needs an independently trusted root key or bundle digest, then checks the issuer’s delegation, allowed signing purpose and validity.
Evidence, authority, provenance, freshness and physical observations are reported separately. Missing trust or observation data produces uncertainty for the affected claim. A public record, an attractive tag or a green result on one axis is insufficient to conclude that every aspect of the physical object is authentic.
This is an operating platform with regression-tested controls. Application-managed encrypted keys are not HSM custody. Local tests are not an independent cryptographic audit. Physical anti-copying performance, conservation suitability and field reliability need qualified hardware and measured evidence.
An account gives access to a defined set of work.
Customer onboarding
Customers join through recipient-specific, expiring welcome invitations and create a passkey. The credential is scoped to the site’s relying party and origin. A customer session belongs to its authorized experience; server-side checks verify the current account, session and relevant agreement before protected actions.
A demo QR contains the same welcome invitation as its link. It is generated locally, expires with the invitation and is usable once. Share it with the intended recipient. Creating an account or accepting a demo invitation does not create a Founder Workspace membership.
Ownership and administrative control
Evidence downloads, tag preparation, custody offers and package refreshes check the current owner and record state. State-changing customer requests also check same-origin and session-bound request verification. Workspace administration uses its separate identity, membership and agreement checks.
Demo requests are unverified leads. They are retained in an administrator-only inbox; follow-up status does not grant access. A welcome invitation is an explicit administrative action. CRM exports retain submitted details and history but do not establish marketing consent.
Protect the key and the meaning of its signature.
Key custody
Private signing keys are protected in application-managed AES-256-GCM envelopes. Associated data binds the envelope to its owner, algorithm, purpose and wrapping version. Runtime wrapping credentials remain server-side. Compromise of the application or its privileged runtime remains a serious risk; encryption at rest does not eliminate that trust dependency.
Signature policy
Credentials declare required signature slots, algorithms and thresholds. Verification checks the exact message, key identity and delegated purpose for each required slot. Empty policies, duplicate or unknown slots, algorithm substitution, missing signatures and message-hash mismatches fail closed. ML-DSA and SLH-DSA provide supported post-quantum signature families; deployment security depends on the complete selected policy and key operation.
Resumable signing
Long operations are split into saved computational steps. Checkpoints are encrypted and authenticated with context binding the operation to its key identity, owner, purpose, algorithm, message and step. Immutable storage prevents a retry from silently replacing the winning saved state. The finished signature is independently verified before issuance continues.
Progress labels show public operation names and counts. They do not contain private keys, seeds, randomizers, intermediate roots or checkpoint bytes. A saved step is progress toward a signature, not a completed credential.
Make digital changes detectable and access deliberate.
| Control | Purpose | Limit |
|---|---|---|
| Evidence commitments | SHA3-512 content and metadata commitments bind exact inputs into the evidence root. | A hash commits to bytes; it does not establish the truth of the submitted description. |
| Private evidence access | Owner-checked routes separate source evidence from public credential summaries. | A shared package can carry evidence; review its declared delivery mode before sharing. |
| Package validation | Check inventory, paths, duplicate entries, expansion limits, encodings and signature requirements. | Archive validity alone does not establish issuer trust or physical authenticity. |
| Public registry summaries | Expose information needed to identify a credential and interpret current status. | Public status is an online observation and depends on service availability. |
| Immutable production objects | Preserve signed evidence and publish later package versions separately. | Retention and recovery still require maintained storage and tested backup/restore procedures. |
The package parser applies path and size policies before treating archive contents as trusted input. Those limits are distinct from the studio’s upload limits. A malformed package should yield a structured failure rather than an implied pass.
Demo form submissions save the contact record and intake event together before notification is attempted. Missing email configuration or delivery failure does not remove the lead. Administrators can export retained leads without exporting signing keys, login tokens or private evidence.
A handoff needs a recipient, an event and a recoverable result.
A transfer starts with the current owner and a named active recipient account. Acceptance requires the intended recipient’s authenticated session and a valid offer token. Only the token digest is stored. Offers are time-limited; cancelled, expired, wrong-recipient and stale-state operations are rejected.
Acceptance records the signed custody event and moves the work and its tag controls atomically. Replaying a completed acceptance recovers the existing result instead of creating another transfer. Older outstanding offers are superseded.
Refreshing the credential package verifies the custody chain and sealed transparency proof, then checks that the owner, custody head and record state still match before changing the package pointer. A race with a later transfer or revocation fails closed. The original signed manifest and evidence remain intact.
Freshness, revocation and recovery
An offline proof describes history included in its checkpoint. A current registry observation is needed to discover subsequent revocation, recovery or custody changes. When the service cannot be reached, freshness remains unresolved. An unavailable status check is not an active verdict.
Saved issuance and transfer progress supports recovery after interrupted responses. It does not guarantee uninterrupted hosting or substitute for restore drills. Key compromise, loss of operational credentials and storage recovery require controlled operational procedures.
Evaluate the threat against the relevant control.
| Scenario | Relevant control | Remaining question |
|---|---|---|
| Changed evidence or manifest | Recomputed commitments and exact signature-policy validation | Was the original evidence truthful and sufficient? |
| A package supplies its own trust root | Independent root pinning and issuer-delegation checks | How did the verifier obtain and maintain its trusted root? |
| Replayed custody or acceptance | Certificate/evidence-root binding, linked events, recipient checks and idempotency | Does the verifier have current data? |
| Copied QR or NFC memory | Separate locator and envelope checks from physical observations | Is secure hardware response or qualified enrollment available? |
| Copied pattern or moved tag | Unit enrollment, controlled reading and attachment qualification | Has attack testing established performance for this carrier, reader and substrate? |
| Cross-account request | Current owner, session, audience and administrator checks | Are the account and trusted hosting boundary uncompromised? |
| Host outage or interrupted signing | Durable work, authenticated continuation and explicit pending states | Can operations restore service and verify the recovered state? |
NFC read-back confirms expected NDEF bytes. It does not prove unclonability. Optical matching, removal resistance and conservation-safe attachment remain separate qualification tracks. Simulation and unvalidated observations are not promoted to physical authentication.
See the public threat model and conformance series for format-level requirements and qualification boundaries.
Report a reproducible issue privately.
Email projecthelixhq@gmail.com with the affected workflow, approximate time, reproducible steps and observed impact. Include a request or certificate identifier when useful. Do not include private keys, session cookies, invitation tokens or other users’ evidence.
Use an account and work you are authorized to test. Avoid accessing other users’ data or disrupting service. We can arrange a controlled exchange if a report requires sensitive material.