Consequential digital events
A decision, approval, intervention or automated action may need later review. The institution defines what to capture and which context matters.
Secoya One · technical reference · developer preview
One evidence standard. Independent verification.
Secoya One provides the infrastructure for creating, protecting and verifying consequential decision records.
The Secoya Trust Record Format defines how those records can be independently interpreted and verified, without dependence on a particular software implementation or vendor.
Technical review starts here.
Detailed material retains its implementation versions, provenance and test boundaries.
- Architecture and data flow
- API, webhook and sidecar scope
- Trust Record specification, public repository and downloads
- Verification runtime requirements and optional Local Evidence Inspector
- Test results, provenance and reproduction methodology
- Security, trust and evidence limitations · Privacy
- Deployment responsibilities and operational requirements
Local Evidence Inspector preview
Release identity and reproducible test evidence
Inspector v0.1.2 uses the vendored @secoya/pq-sdk 0.4.0-rc.6 verifier. Requires Node.js 24.7 or later for the supported preview experience, including native ML-DSA-65 verification. Package metadata still declares Node >=22; that lower declaration is not the supported hybrid-preview requirement.
Locally reproduced: 20 tests passed, 0 failed on Node.js 24.18.0. Coverage includes real Ed25519 and ML-DSA-65 verification, invalid signatures, altered payloads, missing trust, strict parsing, replay and predecessor presentation, and input-race regressions.
Node.js 24.19.0 reproduction is reported in the supplied copy blueprint. Its execution log was not supplied for this review, so it is not represented here as a locally reproduced result.
The offline test disables fetch and checks local assets; it does not establish OS-level network isolation. Reports are printable HTML with browser Save as PDF. The Inspector does not issue records, authenticate imported identities, export an authenticated evidence package or integrate historical-continuity and external timestamp receipts.
npm.cmd test npm.cmd start
Open http://127.0.0.1:4173 after starting the downloaded local application. Request the preview package or inspect a synthetic sample report.
Current identifiers
Product, format and implementations are distinct.
A verifier binds to the record format and applicable profile. Secoya One packages the operational boundary; no individual implementation becomes the protocol authority.
Product
- Name
- Secoya One
- Company
- Secoya Systems Ltd
- Role
- Evidence engine, verifier, integration interfaces and deployment packaging
- Status
- Developer preview
Protocol
- Authority
- Secoya Trust Record
/3RC1 · ratified - Record
secoya-trust-record/3- Canonical
- RFC 8785
- Policies
pq-only·hybrid-required·classical- Result
secoya-verification-result/1- Profile
secoya-verification-profile/1
Implementations
- TypeScript
- Reference implementation 0.4.0-rc.6
- Python
- Verifier 0.1.0rc2
- Rust
- Interoperability harness 0.1.0
- Status
- Developer preview
- Distribution
- Technical review material supplied directly
Standards and policy
NIST-standardised algorithms. Customer-selected policy. Deployment-specific assurance.
The record carries the selected policy explicitly. A customer chooses the production policy according to its regulatory, interoperability and assurance requirements; the pilot validates that choice in its environment.
PQ-only
ML-DSA-65 is standardised in NIST FIPS 204. This policy requires a trusted post-quantum signature.
Hybrid-required
ML-DSA-65 and Ed25519 signatures must both verify. NIST guidance accommodates dual-signature operation when its applicable conditions are satisfied.
Classical-only
Ed25519/EdDSA is specified under NIST FIPS 186-5 and may support transitional interoperability where post-quantum processing is not yet available.
FIPS boundary
Secoya does not present its record format as FIPS certified. Any production FIPS-validation claim depends on the selected KMS or HSM, its validated cryptographic module, approved operating mode and deployment configuration.
Verification model
Use the published format. Verify with a compatible implementation.
Published formats and compatible implementations sit beneath the chosen sidecar, webhook/message-route or embedded integration pattern. A verifier uses the record and independently accepted trust material rather than relying on the originating system.
Published format
The record structure, protected fields, canonical bytes, algorithm identifiers and verification semantics form the compatibility authority.
Conformance material
Language-neutral schemas, committed vectors and expected results let another implementation test the same bytes and decisions.
Independent trust
Offline verification still requires the applicable published trust material, policy artifacts and a trust anchor independently accepted by the verifier.
Independent is not trustless
A verifier does not need an operational Secoya service or the originating application. It does still need authentic trust material and an independently accepted basis for trusting the authority.
Layered result
Cryptographic validity, authority at the relevant time, policy acceptance, continuity and replay, rollback or omission controls are separate evaluations. A single “verified” label must not imply that every layer was established.
Secoya One implementation layer
What the current implementation provides.
- recordsCreation, signing, verification and linked renewal for versioned Trust Records.
- signaturesML-DSA-65 and Ed25519 under customer-selected
pq-only,hybrid-requiredorclassicalpolicy. - trust checksKey status, validity windows, revocation, authority and fingerprint evaluation.
- envelopes
secoya-hybrid-v1: X25519, ML-KEM-768, HKDF-SHA-384 and AES-256-GCM protected evidence. - schemasStrict Draft 2020-12 schemas, runtime validators and versioned verification results.
- integrationSynchronous and asynchronous signing/verification with vendor-neutral registry, KMS, trusted-time and replay interfaces.
- provider limitsAlgorithm support and provider-declared RAW-message limits are enforced before remote signing calls.
Not included
No vendor-specific KMS, durable replay database, managed registry, trusted-time provider or production monitoring service ships in this release.
Operational boundary
Secoya One uses one core across embedded, service and event-driven deployment profiles. Customer-specific connectors and controls remain deployment work. The implementation does not itself establish identity authority, production key custody, durable replay prevention, workflow enforcement or completeness.
Reproduced results
Implementation evidence, with boundaries stated.
TypeScript
100 passed · 0 failed
RC6 source suite reproduced on Node.js 24.18.0, 17 September 2026, including issuance, verification, encryption envelopes, async providers, schemas, canonicalisation, adversarial cases, property tests and 2,000 deterministic malformed inputs. The Inspector has a separate 20-test suite described above.
Python
25 tests · 538 subtests
A separate verifier reproduces verification, malformed-input, policy and trust expectations. It does not issue records or perform encrypted-envelope operations.
Shared /3 conformance
12/12 · three languages
TypeScript, Python and Rust reproduce the committed canonicalisation and Trust Record expectations through separate implementations.
Gate 6
17/17 · two internal implementations
The reference implementation and a separately authored internal clean-room verifier reproduce historical trust decisions through key, policy and trust-anchor change with Secoya and the originating application unavailable.
Assurance boundary
These are implementation, conformance and interoperability results. ML-DSA-65 and Ed25519 are NIST-standardised algorithms; that does not make the Secoya format or developer implementation FIPS validated. Production FIPS status depends on the selected validated module and operating configuration. No independent external cryptographic audit, production penetration test, legal-admissibility opinion or customer deployment assurance is claimed. The clean-room Gate 6 reproduction remains internal.
Runtime
Runtime requirements are explicit.
Technical review material and reproducible test instructions are supplied directly to qualified reviewers and design partners.
Complete encryption path
Node.js 24.7 or later is required for the complete native hybrid encryption path. The full suite has been reproduced on Node.js 24.18.0.
Node.js 22 behaviour
Non-native core paths remain testable; native encryption cases report an explicit version skip rather than a misleading cryptographic error.
Technical review material
Evidence available for diligence.
The frozen RC1 authority and its subordinate publication aids are available in the public specification repository. The frozen protocol is public. The Inspector and implementation material are supplied directly for agreed technical evaluation.
- Public specificationFrozen Trust Record authority, ratification statement, schema and illustrative record on GitHub.
- FormatRatified Trust Record authority and profile material.
- ConformanceLanguage-neutral schemas, committed vectors and expected results.
- ImplementationsTypeScript reference implementation plus Python and Rust verification material.
- IntegrityVersioned reports and SHA-256 checksum manifests supplied with the review set.
Developer preview and review material, not production assurance or certification. Production key custody, operational integration and customer acceptance remain engagement work. Reports do not replace the underlying evidence or establish the truth of its assertions.
From event to reviewable evidence.
Beyond conventional records
Application logs remain valuable. Independent verification additionally needs explicit protected content, a compatible format and an accepted trust basis outside the originating application.
Creation and protection
Selected evidence is canonicalised and cryptographically protected. The protected record makes its assertions and verification inputs explicit.
Retention and key ownership
Retain the record, public trust material and applicable policy. Private signing keys stay within the institution’s chosen custody boundary, not inside exported verification packages.
Authority and policy
A signature can be valid under an unapproved key. Evaluate authority against independently accepted trust material and policy.
Historical trust continuity
Retain appropriate time and lifecycle evidence for later interpretation. Test-controlled historical demonstrations do not establish institutional history or production provisioning.
Portable findings
A compatible verifier can assess records without Secoya’s services or the originating platform, provided authentic trust material and applicable policy remain available.
Separate assessment
Report integrity, authority, time and assessment completeness separately. A single pass label must not imply that every assurance question was answered.
Integration scope and responsibilities.
These are integration approaches, not a hosted API, production container or managed webhook service. Institutional connectors and operational controls remain deployment-specific work.
API
The implementation provides synchronous and asynchronous signing and verification functions. Agree adapter interfaces, authentication, schema mapping, error handling and network boundaries for the selected workflow.
Webhook
Connect workflow events to evidence creation through an adapter. Authenticated delivery, retries, idempotency, ordering and recovery must be implemented and assessed for the deployment.
Sidecar
Run evidence functions alongside the originating application through a separate process. Agree runtime, process permissions, supervision, key access and recovery; no production container package is established here.
All approaches need institution-approved source mapping, retained records, trust material and verification policy. See deployment responsibilities.
Demonstrations and optional developer tools.
These browser demonstrations use synthetic data. They are not footage or evidence of a bank deployment or Sandbox execution.
Formats and verification boundaries
Formats, algorithms and trust boundaries
The applicable Secoya Trust Record /3 RC1 format defines protected fields and canonicalisation. Existing technical resources describe RFC 8785, SHA-384, Ed25519 and ML-DSA-65 policy modes. Algorithm availability depends on the implementation and supported runtime.
RFC 3161 supplies a timestamp protocol, not automatic trust in a time authority. Keep signer-declared time, trusted time evidence, lifecycle history and business truth distinct. Selected successful tests are not full conformance certification.