Technical diligence route

Inspect the foundation—not only the presentation.

See what is implemented, how evidence becomes governed workflow state, where interpretation is constrained, and which claims remain provisional or outside current scope.

Active architecture

See the current boundary before inspecting its parts.

This active model supersedes the provisional public visual while preserving its underlying semantic discipline. It separates external platform responsibilities, carrier transport, Epistema assurance, readouts, admission, and downstream state.

Epistema active architecture showing external agent platforms and control planes, A2A and MCP carriers, Epistema semantic assurance, read-only overlays, independent admission, and downstream governed state. Open the active architecture with a plain-language walkthrough.
1 · Ingestion and normalization

Accept source evidence without allowing a telemetry vendor or model provider to define Epistema’s meaning.

2 · Semantic and governance core

Promote evidence conservatively through an explicit interpretation boundary into governed workflow state.

3 · Decision and evaluation outputs

Keep commitment records, QTF and PEI readouts, and the Workflow Value Ledger distinct but connected.

Walk through the architecture

Epistemic firewall

Evidence does not become meaning by accident.

Provider vocabulary, eval scores, and telemetry remain source evidence until an explicit interpretation step promotes them into typed workflow semantics. Representation remains downstream.

01Evidence

Traces, records, artifacts, scores, corrections, costs, and source provenance.

02Interpretation

Conservative promotion, role assignment, withholding, and explicit uncertainty.

03Semantic State

Typed workflow states, transitions, constraints, commitments, and resolutions.

04Representation

Workflow Value Ledgers, queries, reports, consoles, diagrams, and readouts.

Current status

Bounded implementation, explicit exclusions.

The public proof is designed to make maturity inspectable. “Implemented” means a bounded, test-backed slice—not a production claim.

Implemented · bounded

Import Evidence

Local JSON and CSV submissions support deterministic validation, conservative classification, evidence-window summaries, and a ledger preview.

Open the first-run path →
Implemented · bounded

Workflow Value Ledger v0.2

A pure-function layer derives commitment status, evidence-qualified value signals, explicit optional-input states, and a recommended next action.

Open the illustrative readout →
Implemented · bounded

Reference Path

Work-item, Opik, and OTel-shaped fixtures pass through one structured report contour while retaining source-specific evidence.

See the bounded review motion →
Implemented · bounded

MCP scaffolds

Local contracts, stdio compatibility, persistence, validation, error envelopes, and governed readouts exist. This is not a production MCP service.

Request controlled MCP diligence →
Provisional overlay

QTF and PEI

Evaluation readouts remain subordinate to the semantic boundary. They do not define source truth or silently become semantic state.

See their architectural role →
Implemented · bounded

A2A assurance endpoint

A published Agent Card and HTTPS endpoint support a read-only semantic-assurance handoff, including a bounded Microsoft Foundry round trip.

Inspect the boundary →
Integration path

Enterprise platform controls

Enterprise identity, tenant routing, deployment, scaling, and policy enforcement are supplied by the surrounding platform and integration design.

Discuss the integration path →

Data and trust boundary

Customer-approved evidence enters. Human authority remains outside the model.

Epistema does not require unrestricted raw enterprise data. Evidence may arrive through structured files, approved exports, redacted summaries, source references, or bounded adapters.

Customer and steward responsibilities

  • Lawful collection, classification, consent, and permitted use
  • Source-system access, minimization, redaction, and retention
  • Applicable privacy, security, compliance, and governance rules
  • Final authority over organizational commitment

Epistema responsibilities

  • Operate on authorized submitted or connected evidence
  • Preserve provenance, gaps, withholding, and uncertainty
  • Keep provider metadata from silently defining meaning
  • Respect agreed handling boundaries in an implemented deployment

Current limitation: production identity, access management, tenant isolation, deployment security, and policy enforcement are implementation responsibilities, not features of the current bounded prototype.

Live bounded milestone

Agent-to-agent transport now carries the assurance handoff.

A Microsoft Foundry agent discovers and invokes a deployed Epistema assurance endpoint through A2A over HTTPS, submits a candidate assessment, and receives a completed read-only semantic readout. This is a working proof of the assurance handoff across an agent boundary.

What the proof establishes

  • Agent Card discovery and a standards-based HTTPS endpoint
  • Foundry-to-Epistema A2A invocation
  • Typed readout fields for disposition, evidence, gaps, and posture
  • Fabricated approval evidence is deferred rather than accepted
  • Readout does not grant authority or mutate governed state

What remains outside the claim

  • Foundry A2A is still a preview surface
  • Bearer authentication is transport authentication, not tenant or commitment authority
  • Native typed-data placement through Foundry is not established on the tested path
  • Tenant isolation, source attestation, and delegated identity remain open
  • Work IQ integration and production readiness remain future work

Interpretation: Epistema complements the host platform. The platform may provide identity, permissions, context, orchestration, evaluation, guardrails, and execution; Epistema asks whether the proposed consequential commitment is supported by the evidence and authority available at that point.

Proof trail

Different claims require different proof.

Architecture, fixtures, demonstrations, regressions, and milestones are kept distinct. A polished demo does not stand in for executable evidence.

Reference architecture

Implementation-facing system truth for ingestion, governance semantics, evaluation, and ledger output.

Open architecture →

Platform baseline

Positions Epistema beside AI platforms, orchestration, agent control planes, governance, and evaluation categories.

Request the positioning note →

Governance console

A static bounded demo of ready, constrained, blocked, and missing-evidence states.

Open console →

Full resource index

Technical, strategic, pilot, research, and reference materials grouped by purpose.

Open resources →