Eticas Evaluation Infrastructure — Reference Architecture & Component Choices

One possible instantiation of the target architecture — fixed control plane, parametrised execution. Companion to the evaluation-infrastructure brief and the architecture-options matrix.
The structure and the data flow are the commitment; the products in each box are not. Click any component to see what it can be swapped for and the contract that makes the swap safe. Toggle the execution plane between its two presets and watch it move into the environment that hosts it: as the Eticas-side prober it sits in Eticas cloud and reaches into the client (access & telemetry cross the boundary); as the client-side runner it sits in the client environment and only the run-spec / findings cross.

Reference Instantiation & Data Flow

How data flows

  1. Run-spec dispatch. The auditor surface triggers a run; orchestration compiles the run-spec from the risk taxonomy and the Layer-2 methodology entries and dispatches it to the execution plane. At MVP this is done by hand by the auditor.
  2. Execution. The execution plane provisions access to the target per the declared audit depth, runs the probes, handles raw evidence transiently and locally, scores each check, and emits findings conforming to the schema. Raw evidence does not leave the execution environment.
  3. Findings return. The findings (YAML/JSON) are returned over HTTPS. The control plane validates them against the schema (Pydantic) and runs the aggregation engine (severity → subcategory and dimension grades + pattern).
  4. Review & persist. Findings are written to the store: a git commit as the system of record and, where present, an upsert into the read-model. The auditor reviews, validates and authors narrative against the store through the auditor surface.
  5. Consume. The store has two independent read consumers: the document outputs (leaflet, client report, optional regulatory) are projected from it via per-output manifests, generating no new content; and the client surface reads it directly to render the platform view and monitoring.
Two distinct surfaces, not one: the auditor surface drives runs and writes findings; the client surface only reads. Each is fundamentally an API — a web app or an MCP server are interchangeable clients on top of it.
Monitoring / re-audit: the observability stack lives in the client environment, instrumenting the audited system; the execution plane pulls its telemetry through OpenTelemetry, the tool's SDK/API, a proxy or a log connector — OSS-first, a data-access channel, never a business dependency. Real-time signal-based monitoring is a later phase.
Fixed vs choice Four things are fixed and not part of any swap: the findings schema, the run-spec / findings contract, the dimension & taxonomy vocabulary, and the location of the aggregation rules. Everything else is an implementation choice — pick any cell, and the rest of the system is unaffected, because each component sits behind a stable interface. This is what lets the MVP ship one execution mode and one storage backend without foreclosing the rest.