Controlled-Use Product Preview — v0.28.0

Encrypted envelope workflows
with verifiable trust semantics

A policy-aware encrypted envelope workflow platform built on standard authenticated encryption. Package structured messages into session artifacts, compare routing policies, export signed bundles, and verify trust — with semantics that distinguish integrity from authenticity.

Request a Demo Live Demo Contact Us
189 tests passing
Signed bundle verification
Trust-aware verification output
Reviewer packet available
Controlled-use release
Who It's For
Built for teams that need verifiable encrypted artifacts
Designed for organizations evaluating structured encryption workflows with explicit policy control and auditable trust.
Security

Security and Trust Reviewers

Evaluate trust semantics, signed verification workflows, and the hardening posture of a system that documents its own boundaries.

Engineering

Technical Evaluators

Run the full demo: build envelopes, compare policies, export bundles, verify signatures. 189 tests. Copy-paste review commands. 15-minute evaluation path.

Product

Product and Platform Teams

Understand how policy-aware encrypted workflows, persisted security artifacts, and signed bundle verification integrate into existing infrastructure.

How It Works
From structured messages to verified bundles
Four stages from plaintext input to a signed, independently verifiable artifact.
Step 01

Structure Messages

Canonical symbolic preprocessing normalizes input into deterministic token streams via the Bry layer.

Step 02

Encrypt and Package

ChaCha20-Poly1305 authenticated encryption seals messages into validated packets, grouped into multi-message session envelopes.

Step 03

Compare Policies

Run the same messages under different routing policies. See exactly what changes, what doesn't, and why.

Step 04

Export and Verify

Export signed bundles with SHA-256 manifests and HMAC signatures. Verify with unambiguous trust semantics.

Evaluate
Choose your evaluation path
Three structured paths depending on your role and what you need to assess.
Technical

Technical Review

Hands-on evaluation of the protocol, trust model, and verification semantics.

Start Technical Review
Security

Security Review

Assess the trust model, hardening status, and documented boundaries.

  • Security Status and Hardening
  • Threat Model
  • Trust Semantics
  • Adversarial Audit Results
Review Security Posture
Buyer

Buyer Evaluation

Understand the product, see it in operation, and assess fit.

  • Product Preview
  • Release Walkthrough
  • Guided Demo Flow
  • Direct contact path
Request a Demo
Differentiation
Not a new cipher. A verifiable workflow.
The cryptographic foundation is standard AEAD. The value is the policy, comparison, persistence, signing, and verification layer built on top of it.

Policy-Aware Comparison

Run the same messages under manual, default, and auto routing. See which messages trigger specialist overrides and why. Differences are explicit and per-message.

Persisted Security Artifacts

Envelopes, policy comparisons, and artifact comparisons are saved with SHA-256 integrity binding. Tampered files are rejected on load.

Signed Bundle Verification

Export bundles with HMAC-SHA256 signatures over SHA-256 manifests. Verification output is unambiguous: integrity, signature, metadata, trust.

Trust-Aware Operator Surface

The dashboard never implies trust where none exists. Unsigned bundles display warnings. Failed signatures display errors. Only fully verified bundles display as trusted.

Reviewer-Ready Evaluation

Reviewer brief, trust semantics specification, copy-paste commands, canonical review artifacts. A technical evaluator can understand the system in 15 minutes.

Documented Boundaries

What is hardened and what is not are both documented publicly. No inflated claims. The threat model and current limitations are available for review.

Security and Trust
What has been hardened, what remains limited
An internal adversarial review identified 11 issues. Phases 35A through 35F resolved the critical and high-severity findings.

Resolved (Phases 35A-35F)

  • DoneKey provider restricted to allowlisted paths and environment variables
  • DoneNonce registry concurrency-safe via exclusive file locking
  • DoneBundle trust: overall_trusted requires integrity, signature, and metadata consistency
  • DoneStorage integrity: SHA-256 content hashes with tamper detection on load
  • DoneKey fingerprint provenance binding derived from actual key material
  • DoneBundle verification restricted to allowed directory paths
  • DoneOperator UI displays explicit trust verdicts for all verification states

Current Limitations

  • OpenLocal trust model only. Not hardened for hostile multi-tenant deployment.
  • OpenNo KMS or HSM integration. Key material is managed locally.
  • OpenNo key rotation or revocation mechanism.
  • OpenNonce registry uses POSIX file locking. Not portable to Windows or NFS.
  • OpenIndex files are not independently signed.
  • OpenNo formal third-party security audit has been conducted.
Contact for Security Questions
Frequently Asked Questions
Common questions
Is this a new cryptographic algorithm?
No. BRY-NFET-SX uses standard ChaCha20-Poly1305 authenticated encryption provided by the Python cryptography library. The Bry and NFET layers handle canonical preprocessing and deterministic scheduling. They are not encryption primitives. The differentiated value is the workflow architecture.
Is this production-ready?
This is a controlled-use product preview, version 0.28.0. It has been through an internal adversarial security review and six hardening phases. It has not been formally audited by a third party and is not designed for hostile multi-tenant deployment. It is suitable for evaluation, controlled workflows, demos, and technical review.
What can I test today?
The full workflow: build multi-message encrypted envelopes, compare routing policies, browse persisted artifacts, export signed bundles, and verify trust semantics. The live demo requires no installation. The Demo Flow tab in the dashboard provides a guided walkthrough.
What does signed bundle verification prove?
Verification checks three properties independently. Integrity: manifest hashes match the actual file contents. Authenticity: the HMAC signature is cryptographically valid. Metadata consistency: the key fingerprint derived from actual key material matches between signer and verifier. The overall_trusted field is true only when all three conditions hold. Unsigned or unchecked bundles are never reported as trusted.
What are the current limitations?
Local trust model only, no KMS or HSM integration, no key rotation or revocation, POSIX-only nonce locking, index files not independently signed, no formal third-party audit. These are documented in the threat model and will be addressed in future hardening phases.
How do I get a demo?
The live demo is running now and requires no setup. For a guided walkthrough or a deeper technical session, email bryanleonard@imagineqira.com with the subject line "Demo Request."
How do I contact you?
Email bryanleonard@imagineqira.com. For security-specific questions, use the subject line "Security Review."

Evaluate the system

Run the live demo, request a guided walkthrough, or contact us for a security review.

Request a Demo Live Demo Contact Us