Create the evidence. Change it. Watch verification fail.
Generate a portable secoya-trust-record/3 RC1 record, inspect and download its JSON, then alter the signed evidence and verify it again. The keys and cryptographic operations remain inside your browser.
Four steps. One visible evidence object.
1. Create the decisions. 2. Inspect the exact RC1 JSON. 3. Change the evidence. 4. Reverify and observe the fail-closed result. Fresh Ed25519 and ML-DSA-65 keys are generated locally; the demonstration transmits no decision or key material.
Ready. Create the records to begin.
No records have been created.
Inspect and challenge the JSON.
This is the actual object being verified—not a decorative transcript. Edit any value and choose “Verify edited JSON”, or use the prepared loan-amount challenge above.
The JSON is parsed strictly: duplicate member names, forbidden prototype keys, invalid I-JSON strings and unsupported structures are rejected. Compare the structure with the published RC1 authority and schema.
- Records
- —
- Divergences
- —
- Confidence
- —
- Length
- 1
- Algorithm
- —
- Last renewed
- Not yet
- Policy
- CREDIT-POLICY-v2.1
- Minimum score
- 720
- Maximum DTI
- 0.43
Waiting for the demonstration to start.
What the demonstration covers.
- 01 / policyRegister the rules that were applicable when the decisions were made.
- 02 / createConstruct three exact
secoya-trust-record/3RC1 envelopes using RFC 8785 and SHA-384. - 03 / attestApply independent Ed25519 and ML-DSA-65 signatures to each record’s frozen RC1 signing input.
- 04 / inspectSee, copy and download the portable JSON record that the verifier actually receives.
- 05 / challengeModify the payload or protected context, reverify it and observe a deterministic rejection.
- 06 / continueRun the existing audit view and create a successor whose protected header links to its predecessor.
The application continues making its decision.
Secoya receives the selected event through the agreed sidecar, webhook/message route or embedded boundary. The decision engine remains the customer’s; Secoya is the evidence layer, not a replacement platform.
Existing workflow
Produces an authorised decision event using the organisation’s existing business logic.
Evidence service
Maps the selected event, creates the evidence record and applies the configured trust controls.
Independent verification
Uses the record and accepted trust material without relying on the originating application.
This browser demonstration performs genuine RFC 8785 canonicalisation, SHA-384 hashing, Ed25519 signing, ML-DSA-65 signing and verification over synthetic data using the published RC1 record and signing-input structure. Its keys, authority binding, declared time, business policy, audit and renewal state exist only in this browser session. It does not establish production key custody, independently evidenced time, durable replay control, persistent completeness, legal effect, external audit or an independently accepted trust anchor.
Replace synthetic assumptions with one real workflow.
Test the evidence boundary, customer-controlled trust and five pass/fail gates under agreed operational conditions.