Mehridian / Docs
Browse documentation

Understand the three examples

The application generates three fixed synthetic records in its in-process store. The repository also has three JSON fixtures for contract tests. These share the same state/classification scenarios, not the same IDs, timestamps or labels. Neither set is private evidence or a current activity feed.

Fixture-to-response map

API / UI recordJSON contract fixtureRecorded stateSnapshot eligibleClassificationHuman approval flag
art_demo0001art_fixture0001completetruehealthy-completefalse
art_demo0002art_fixture0002deferredfalsebounded-defertrue
art_demo0003art_fixture0003preparedfalseprepared-awaiting-catch-uptrue

All three responses have mutation_authorized=false and a non-empty explanation. The JSON fixtures are all dated 2026-01-01 UTC; the store records are dated January 1, 2 and 3, 2026 UTC, respectively. These are seed dates, not runtime observation dates.

Complete: a finished state is recorded

The inspector recognizes the complete state and explains it. This does not independently verify that every copy matches its source. A reviewer can inspect the ID, displayed state and example fingerprint; the label alone is not evidence of a fresh processing or replication run.

Deferred: waiting is not finished

The inspector returns bounded-defer and a proposal to review a component summary. It does not retry anything. The command-like proposal is not execution authority, and the human-approval flag does not itself grant approval.

Prepared: ready for a later step

The inspector returns prepared-awaiting-catch-up and a read-only readiness-review proposal. No completed processing result is implied, and the UI does not start a worker.

Deterministic, not LLM-powered

The handler selects branches from predefined rules. It does not call a model. The optional ADK adapter is disabled in the gateway container; an ADK + Ollama experiment would require separate implementation, testing and authorization. No such experiment result is asserted here.

Inspecting is not verifying the underlying evidence

The tests can verify that an input gets the expected classification. That is a test of the inspector’s behavior, not independent readback of real evidence bytes and not engineering acceptance of a production system.

For implementation details, follow the sources below. For supported fields and other model states, see API and data contracts.

Source and provenance

Curated adaptation of pinned public source; not a current hosted-deployment attestation.

Seemorghdev/edge-evidence-reference-platform-public @ 37e8a8f · source review recorded 2026-10-15T06:52:47Z UTC

Adapted from Apache-2.0 source by Seemorghdev. Changes are explanatory and do not amend the engineering source. Source license · NOTICE · Third-party notices · Source manifest

Mehridian · Independent engineering & researchEdge Evidence technical reference · Quartz MIT license·Third-party notices·Copyright & scope