One product core, adapted to the boundary your workflow permits.
Secoya One combines the evidence engine, verification model, integration interfaces and deployment packaging. The cryptographic core remains consistent while customer-specific adapters connect approved keys, trust material, time, storage and event sources.
Choose the invocation boundary that fits the workflow.
Embedded, service and event-driven invocation are deployment profiles of Secoya One. They do not create separate banking, insurance, healthcare or cloud editions.
Embedded
Invoke the evidence engine inside a customer-managed application boundary where local execution and latency make that appropriate.
HTTP or event route
Place the same core behind an approved service endpoint, webhook, queue, audit export or event stream.
Container or sidecar
Run the product alongside the existing application where separation, portability or operational ownership requires it.
- decision pathExisting workflow → authorised event source → Secoya ingestion and attestation → signed evidence record → customer-controlled storage.
- signingCustomer KMS or HSM → signing operation. Secoya does not need custody of the customer’s private signing keys.
- verificationRecord + authenticated historical trust material + independently accepted trust anchor → customer, auditor or other authorised verifier.
- payload boundaryA record may commit to business data by digest without making Secoya the central repository for the underlying payload.
Deployment still requires source access, event mapping, keys, trust policy, storage, security approval and operational ownership. Secoya One supplies the common product boundary; customer-specific production connectors remain integration work.
Historical verification is designed not to require an operational Secoya service or the originating application. It still requires authentic trust material and a basis for trusting the asserted authority.
Gate 6 has demonstrated the continuity model in reference conformance testing and internal clean-room reproduction. The first customer deployment pilot will bind one defined evidence-submission or decision record to persistent replay state, customer-controlled storage, trusted key resolution and an explicit verification profile. The integration pattern and vendors will be selected from the deployment’s architecture, data classification, residency, availability and key-custody requirements.
Supplied by the deployment, not assumed by the format.
Atomic replay
Persistent, atomic replay claiming so a valid record cannot be reused. The store and its uniqueness scope are deployment-supplied.
Key custody
Managed key generation, storage, rotation and revocation through a KMS or HSM. The default Node provider is not production custody.
Trusted time
An independent time source where chronology must be defensible. Declared time alone is a signer assertion.
No Cloudflare D1, KV, R2, Durable Objects, specific KMS or trusted-time authority is integrated at this stage.