Where Apeiris fits

Not another tool in the row. The evidence model underneath them.

Apeiris is often mistaken for a category it isn't. It is not a policy engine, an AI gateway, a GRC platform, a model evaluator, or an observability tool — and it doesn't replace any of them. It defines the open control-and-evidence model those tools produce and consume evidence against: the layer that reasons about the action a workload assembled across identity, authority, data, knowledge, and behavior. An evidence layer, not another sensor and not a choke point.

Read this as where each layer sits, not as a scorecard. Each category below does real work Apeiris does not do; Apeiris adds the shared meaning and evidence model that lets their outputs compose into one reviewable action. The runtime that collects and evaluates that evidence in your environment is the Apeiris platform, in development — today the corpus supplies the model, mappings, and evidence requirements. What exists today →

CategoryWhat it does wellWhat Apeiris addsHow they compose
GRC & AI governance platforms Manage policies, risk registers, audits, and framework attestations as an organizational workflow. A versioned, machine-readable control set with framework provenance, direct-vs-partial coverage, and mapped ≠ satisfied made explicit per obligation. GRC owns the workflow and sign-off; Apeiris supplies the control-and-evidence model and the obligation-to-control mapping it attests against.
AI gateways & firewalls Sit inline on prompts and tool calls to filter, rate-limit, redact, and block at request time. The control semantics and required evidence a gateway signal maps to — so a block or allow becomes a governed decision with a reason, not just an event. The gateway enforces inline; Apeiris defines what its signals mean and what evidence they should produce. Apeiris is not inline and decides nothing.
Model evaluation & red-teaming Measure a model's quality, safety, and robustness against benchmarks and adversarial tests. Evaluation of the action the workload assembled — under whose authority, over what data, within what policy — bound to the deployed reachable graph, not the model in isolation. Model eval answers “is the model fit?”; Apeiris answers “was this action, in this context, evidenced?” A model-assurance attestation is one input to the composed action.
Policy engines (e.g. OPA-style) Evaluate declarative rules against a request and return allow/deny at decision time. The obligations, evidence requirements, and cross-domain proof chains a policy should express — plus the distinction between a rule being mapped to an obligation and the evidence satisfying it. The policy engine decides; Apeiris supplies the obligations and evidence model the rules encode, and keeps coverage traceable to a normative source.
Observability & SIEM/SOAR Collect, correlate, and alert on logs, traces, and telemetry across systems at scale. A typed evidence ontology so a raw signal becomes evidence for a specific control and obligation — with provenance, freshness, and a blocking posture — rather than an undifferentiated log line. Observability owns collection and storage; Apeiris owns the meaning, mapping, and evidence-quality of what was collected. Telemetry is a source of evidence, not the verdict.

The one-line boundary

Apeiris owns meaning, mapping, evidence-quality, conclusions, traceability, and provenance. Partners own collection, enforcement, workflow, and telemetry storage. That division is deliberate: the market has strong tools for every seam except the shared model that lets their evidence compose into one reviewable action. That is the layer Apeiris publishes — open, signed, and free to build on. See it from the security angle → · the underlying idea →