Public and free of charge
- Examine supported existing JSON evidence locally.
- Recompute available signatures, checksums and links.
- Read confirmed checks, contradictions and missing foundations.
- Download the automatically generated JSON report.
IMMO.QUICK VERIFY · PUBLIC EVIDENCE VERIFICATION
Verify JSON evidence and digital signatures with a clear view of the proof.
immo.quick Verify examines supported JSON evidence directly in your browser. Do the checksums match the content? Is an included signature valid? Which declarations are protected, and what remains open? The public verifier of immo.quick Serverless Edition™ makes those distinctions visible and provides the result as a downloadable JSON report.
Content and verification scope updated on 17 October 2026.
How can I verify digital evidence?
Load a supported JSON record into the verifier, add public trust material where needed and compare the expected action. immo.quick Verify recomputes the supported checks locally and separates confirmed points, contradictions and missing evidence. A readable file is not automatically authenticated evidence. A matching checksum establishes mathematical consistency; a valid signature binds protected content to a key. Key provenance and actual execution remain separate questions.
Public evidence examination · no issuance or execution
Examine existing evidence. Access institutional infrastructure separately.
The public verifier is a bounded examination tool: inspect existing records and receive a local JSON report. It does not issue institutional evidence or provide access to the operational immo.quick infrastructure.
Institutional service scope
- Institutional evidence issuance and protected signing.
- Integration with business processes and real target systems.
- Ongoing checks and monitoring within the agreed scope.
- Approval workflows, protected execution and operational integration.
These services are agreed separately. Scope, access rights and operational prerequisites depend on the selected integration. The public verifier is neither a free platform licence nor an operational release.
Request institutional accessVerify evidence locally in your browser
Paste your JSON record or select a labelled example. The verifier neither transmits nor stores your input. Loading this website and its program files is a separate process. No account is required for the local check.
From a file to an understandable verification report
Choose the evidence
Use your own file or a synthetic example. The supported export format matters, rather than a particular company name or demonstration value.
Define the question
Optionally supply public key material, an expected action, a reference time or full CDS™ source texts. This identifies the question the result can answer.
Inspect the result
Read confirmed points and missing foundations separately. Download the JSON report containing the input checksum, verifier version, reference time and individual checks.
What does immo.quick Verify check?
The verifier applies defined rules to known export profiles. It examines the supplied evidence without treating a displayed PASS or issuer declaration as automatic trust. Different values within a supported format are explicitly supported.
| Verification area | What is recomputed | What still requires additional evidence |
|---|---|---|
| JSON and profile | Readability, unique fields, supported profile versions and required references. | An unknown format requires suitable documented verification rules. |
| Checksums and content | The data, receipt and content checksums defined for the supported profile. | A self-supplied checksum alone does not authenticate an issuer. |
| Digital signatures | Supported ECDSA-P256 signatures and the classical Ed25519 component of certain legacy hybrid receipts. | Trusted key provenance; the additional ML-DSA component remains unverified for hybrid receipts. |
| Action and time | Bound declarations, expected action, validity windows and consistency of execution timestamps. | A matching reference or timestamp alone does not establish a real target-system effect. |
| Negative Assurance™ material | Leaf hashes, event and class roots, snapshot binding, neighbour paths, counterevents and declared coverage. | Original capture completeness is not independently confirmed at the source. |
| CDS™ and screening | Finding and segmentation counts, supported screening checksums and supplied full CDS™ source texts. | No new live sanctions screening and no legal determination of an individual case. |
| Receipt chains | Links and predecessor references within supplied CertifiedReceipt and TZero chain segments. | A segment alone establishes neither the complete beginning nor the current chain head. |
The table scrolls horizontally on small screens.
Three examples: what does verification change?
An amount is changed
A file is altered to show a different amount or target action. If that field is protected by the supported signature profile, the content no longer matches the original signature. The verifier reports the contradiction. It does not trust the file simply because it still declares itself valid.
The checksum matches, but issuer identity remains open
A screening receipt includes a correctly calculated checksum but no public issuer signature. Its result may therefore be “Checksums match”. This does not establish authenticated origin. Being able to recalculate a self-supplied hash does not enable someone to generate another party’s signature.
A clean search meets a missing source
A Negative Assurance™ export claims positive coverage while its material identifies a required source as open. Those declarations conflict, and the verifier detects the inconsistency. Whether the source data was captured completely outside the export remains a separate evidence question.
Negative Assurance™: why “nothing found” is not yet proof
Negative Assurance™ relates an absence claim to a defined event space and period. The stored export must identify captured sources, coverage gaps and the binding between the claim, snapshot and examination material. immo.quick Verify recomputes supported exports containing run and material, including Merkle paths and consistency between counterevents and the result. The statement remains limited to the supplied material; it does not become universal proof that a real-world action never happened.
Understand Negative Assurance™Four results that answer different questions
Signed content verified
The supported signature and content binding were examined using the supplied trust material. This is not a general confirmation of every prerequisite for an action.
Checksums match
Supported mathematical bindings are consistent. This alone establishes neither issuer provenance nor the truth of the underlying declarations.
Contradiction detected
At least one checked relationship fails, such as content and signature, an expected action, a count or a Merkle link.
Not fully verifiable
A supported format, required key material or evidence is missing. A technical interruption also produces no confirmation.
Who is public evidence verification for?
Auditors, compliance and risk teams, banks, insurers, investors and private equity teams need to understand what digital evidence actually establishes. AI-agent operators and business partners can also examine supported records. During due diligence, the report helps distinguish demonstrated content binding from a declaration. It does not replace substantive assessment or a decision by the responsible institution.
A public verification path. Two clearly identified systems.
The public verifier is identified as a component of immo.quick Serverless Edition™. It supports selected export profiles from immo.quick Serverless Edition™ and immo.quick Core™, each with its own examination scope. Both systems remain independent. immo.quick Serverless Edition™ uses no TEEs or enclaves. Those technologies belong exclusively to immo.quick Core™; this browser verifier does not establish hardware attestation.
Why this goes beyond a dashboard
A dashboard displays a result. Recomputable evidence also exposes which content is protected, which relationships hold and which foundations are missing. The immo.quick architecture connects such evidence with the question of a specific execution right. The public verifier examines exported evidence. Enforcing an action at its actual execution boundary is a separate responsibility of the integrated systems.
Frequently asked questions about JSON evidence and signatures
Is my JSON file uploaded?
No. The public verifier processes pasted or selected evidence locally in your browser. It does not transmit or store that input. The website and its program files are loaded when you open it.
Can I verify JSON files from other providers?
Yes, if they follow a supported evidence profile and contain the required verification material. The verifier is not restricted to particular example values. It does not confirm unknown signatures in arbitrary JSON structures.
Does “system: immo.quick” establish origin?
No. A text field is initially an origin declaration. Cryptographically confirmed attribution requires a valid signature and a trusted link between issuer and public key.
What is the difference between a hash and a signature?
A checksum mathematically describes content. Without a trusted external reference, it could be recalculated alongside altered content. A digital signature requires the corresponding private key. Public verification needs only public verification material.
Can the verifier publicly authenticate an HMAC-protected record?
Not without the protected secret key. That key does not belong in the browser form. The verifier states this limit and may examine additional public checksums or chain links where available.
Is revocation checked live?
No. The local verifier does not query current revocation registries. It can examine status and validity windows in supplied trust material; those are not presented as an independently confirmed current revocation status.
Does the report grant execution permission?
No. It records checks on supplied evidence. It does not consume a capability, initiate a payment or establish actual external target-system execution.
Is the JSON report digitally signed or personally approved?
No. It identifies immo.quick Serverless Edition™ as the verifier used and r.cherri@immoquick.eu as the contact. It is generated automatically and locally. That does not assert personal approval or a digital signature of the report.
How can I reproduce a result?
The downloaded report includes the input checksum, verifier version, build identity, reference time and a binding of verification options. Repeating a browser check requires identical input bytes, options, reference time and verifier build. You can request access for separately provided offline or institutional use.
Can every form of Negative Assurance™ be fully verified?
No. The public verifier recomputes supported material and consistency checks. Original capture, substantive classification, witness confirmation and actual erasure are not independently established by that process.
What is free and what belongs to the institutional offering?
Local examination of supported existing evidence, including its JSON report, is free. Institutional issuance and signing, integrations, ongoing controls, approvals and protected execution are agreed separately. The complete offline verifier is no longer offered here as a free download.
Does public browser verification disclose the entire architecture?
No. The browser code necessary for local evidence examination is publicly accessible and remains technically inspectable. The verifier supplies no protected signing keys and grants no access to internal datasets, operational approvals or protected target-system execution. Public verifiability does not grant a licence to use the institutional platform.
Continue from verification to the relevant subject
Documented system verification and release scope
Internal verification status · 14 October 2026
What the new internal evidence supports.
The reported internal run connects issuance, ordered consumption, an instruction, a recipient and a test result read back. Revocation and retries were tested separately. It does not establish that an action occurred outside that integrated internal path.
Internal effect path tested. Operational release pending.
Test scope, register evidence and release statusHas the Serverless Edition™ been released for internal production use?
Not according to the documented status dated 14 October 2026. The internal effect path and register delivery have been reported; both individual approvals and the internal operational verification remain pending. Release applies only to the explicitly tested baseline and named scope.