Skip to content

Repository files navigation

Hemion

Hemion is the local-first developer console for Parwana. It is the place to inspect accountability objects and, as those capabilities land, verify bundles locally without treating a verdict recorded by another product as authoritative. The existing multi-chain wallet remains available under Legacy wallet; its routes and stored data are not migrated by this navigation refactor.

Topology

Where Hemion sits in the DieWan Accountability Platform:

flowchart TB
  PAR["Parwana · protocol<br/>canonical bytes · verifier · SDK"]
  PIT["Piteka · product<br/>authorize · execute · investigate · Postgres live state"]
  TUP["Tuppira · data plane<br/>observe · index · read model"]
  HEM["Hemion · developer console<br/>explorer · local verifier · wallet"]
  CON["csv-contracts · chain anchors<br/>optional anchor provider"]

  PIT -->|uses protocol + verifier| PAR
  PIT -->|signed evidence feed| TUP
  TUP -->|read model| HEM
  HEM -->|verifies locally| PAR
  PAR -.->|anchors commitments| CON
  TUP -.->|observes anchors| CON

  classDef here fill:#2563eb,stroke:#1d4ed8,color:#ffffff;
  class HEM here;
Loading

You are here — Hemion, the developer console. It reads the Tuppira read model to explore accountability objects and runs the Parwana verifier locally — it never trusts a verdict just because Piteka or Tuppira recorded it. See the org charter in development/ARCHITECTURE.md.

Glossary

Key terms a newcomer will meet in Hemion:

Term Kind Plain-English meaning Real-world example
Mandate Data structure A pre-action authorization artifact Hemion loads and inspects. A signed work order approving one specific deployment.
Receipt Data structure Evidence of what actually happened, bound to its mandate. A deploy log entry that proves it came from that approval.
Bundle Data structure A packaged set of evidence Hemion verifies locally. An evidence folder you re-check yourself instead of trusting the sender.
Assurance Data structure The structured result of verifying a bundle — a graded conclusion, not a raw pass/fail. An audit report with findings and a conclusion.
Dispute Data structure A recorded challenge to an action, receipt, or verdict. A credit-card chargeback contesting a transaction.
Anchor Keyword A commitment published on a chain; Hemion can anchor a bundle or verify an existing anchor. A notary stamp proving a document existed by a certain date.
Finality Keyword Whether an object is settled on chain (anchored) versus merely seen in the data plane (buffered) — Hemion shows both lanes. "Confirmed by the postal service" vs. "delivered per our records."
Lineage Keyword The walkable chain mandate → action → receipt → dispute → verdict → anchor. A family tree of an event, navigable in both directions.

Information architecture

  • Portfolio of mandates (/) is the default home (HEM-05): mandates grouped by accountable entity and state, with the anchored-vs-buffered split per tile. Cards are projected from real Piteka mandate-chain reads loaded by id — none are simulated — and the local-verifier boundary is carried as a badge. With nothing loaded it shows an explicit empty state.
  • Developer console (/console) identifies the local verifier boundary and exposes the local inspection tools. It is still reachable; it is no longer the default entry point.
  • Anchoring (/anchoring) is a first-class console capability, peer to local bundle verification rather than a wallet feature: pick a Parwana-configured network (projected from parwana/chains/*.toml) and attempt to anchor a bundle or verify an existing anchor. The on-chain commitment / finality protocol backing is delivered by ANCHOR-01; until it lands, the anchor and verify actions render an explicit unavailable state naming that dependency — Hemion never fabricates an anchor or finality.
  • Tuppira explorer (/explorer/tuppira) traces observation lineage. Each traced object shows dual-lane finality (HEM-02): a buffered lane (present/absent in the observation plane, immediate) beside an anchored lane (none / pending / final). The anchored lane reflects real chain finality only — a pending or unknown read is never rendered as final — and shows an explicit unavailable state until ANCHOR-01 supplies a chain finality source.
  • Universal search (/search) classifies one query — mandate, receipt, action, dispute, assurance, anchor, accountable entity, chain tx, or an environments/<env>/receipts/<id> path — and routes it to the right object (HEM-04). A bare digest is reported as ambiguous with candidate kinds and is never routed to a wrong object; unknown queries return an explicit no-match. The page also renders a lineage graph that walks mandate → action → receipt → dispute → verdict → anchor in both directions, with node-type filters and a keyboard-accessible mirror table. Graph shape is structure, not truth, and withheld branches show as explicit gaps.
  • Object pages (/object/<kind>/<id>) give each accountability object type — mandate, action, receipt, dispute, assurance, anchor — a deep-linkable detail page (HEM-03): summary → canonical bytes → relationships, cross-linked along the evidence DAG. The pages reuse the existing inspectors as the canonical-byte decoders rather than replacing them; withheld/redacted fields stay protected.
  • Wallet (/wallet) retains the previous wallet dashboard. Assets, activity, contacts, and settings keep their existing routes beneath that area. It is preserved but, as of HEM-05, no longer framed as a second-class "legacy" tool; the chain services that back Anchoring are no longer quarantined here.

The design system is dark-first with a light theme served when the viewer prefers it (and an explicit data-theme on the root wins either way); both themes clear the WCAG-AA text-contrast matrix enforced by tests/console_shell.rs.

  • Bundle verification, assurance inspection, and object inspection are the remaining Stage 7 console screens. They are deliberately absent from navigation until their implementation tickets are complete.

Legacy wallet capabilities

  • Multi-chain support (Bitcoin, Ethereum, Sui, Aptos, Solana)
  • Encrypted key storage
  • Seal monitoring and management
  • Runtime-backed Sanad and transfer receipt presentation
  • Cross-chain transfer tracking
  • WebAssembly support for browser deployment

Capability boundaries

Hemion never creates simulated proofs, test results, balances, finality, or transfer success. Proof construction, proof acceptance, seal consumption, and cross-chain completion are runtime-owned operations; unavailable wallet capabilities render an explicit unavailable state instead of a best-effort result. An imported verdict is only "recorded elsewhere" until Hemion computes it locally under an explicit verification context.

Parwana V2 platform matrix

Hemion consumes Parwana exclusively through the exactly pinned csv-sdk facade. Capability differences are explicit and fail closed:

V2 capability Native Browser WASM
Canonical consignment inspection Supported Supported
Local verification with caller-supplied context, checkpoint, and proof provider Supported Supported
Atomic acceptance with a caller-supplied store Supported Supported
Filesystem-backed durable journal/store Supported Unavailable (SDK.V2.UNSUPPORTED_CAPABILITY)
Embedded conformance corpus Supported Supported; bytes must match native

Neither target may replace an unavailable capability with structural-only success. Browser persistence, when supplied by the application, is not filesystem-backed native persistence.

NAM-04 naming compatibility

The NAM-04 naming audit records every renamed family, its producer and consumers, compatibility classification, deployment order, and rollback path. The changes are source/user-language only: canonical bytes, JSON fields, schemas, routes, stored data, and verifier semantics remain unchanged.

Default operator copy says “asset network,” while technical inspection details retain exact names such as DisputeBundle, VerificationContext, and AssuranceProfile. unavailable, unknown, pending, inconsistent, and verifier invalid outcomes remain separate states.

Design traceability

The console shell implements Flow Spec Part 8 (S-H1 and H-RULE-1) using the Design System's Hemion “Instrument” skin. REV03 finding D-02 governs the corrected metadata color. The checked-in docs/accessibility/hemion-contrast-matrix.md matrix is enforced by tests/console_shell.rs; keyboard access uses native links and visible two-pixel :focus-visible outlines, and reduced-motion preferences disable shell animation.

License

MIT OR Apache-2.0

About

A protocol explorer, developer wallet and forensic debugger for Parwana protocol

Resources

Security policy

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages