From Proofence Engine to AtlasProof

People often ask us where the Proofence Engine ends and AtlasProof by Proofence begins. It is a fair question, because the two are designed to feel like one system. The short answer is that the engine is the reasoning core that produces trust decisions, and AtlasProof is the workspace and API where teams request those decisions, review them, and act on them.

This separation is deliberate. Keeping the core engine distinct from the surfaces that use it lets us evolve verification independently of any single interface, and lets teams adopt the parts they need without swallowing the whole platform on day one. This post walks through the layers and how a single request flows across them.

The Proofence Engine: the trust core

The Proofence Engine is the proprietary core that does the actual work of verification. It coordinates independent checks across models, evidence, and policy, resolves where those checks agree and disagree, and produces a trust decision with the reasoning attached. The engine has no opinion about how it is presented. It exposes a clean contract: give it an output and context, and it returns a verdict, the signals behind it, and the evidence trail.

Because the engine is a layer rather than a product surface, the same core can sit behind a review workspace, a batch pipeline, or an enterprise control plane. That reuse is what keeps trust decisions consistent no matter where they are made. A verdict produced for a customer-facing assistant is built the same way as one produced for an internal agent.

AtlasProof by Proofence: the verification workspace

AtlasProof by Proofence is where people meet the engine. It is a verification workspace and API: a place to submit outputs for checking, see trust scores and their supporting evidence, route borderline cases to human reviewers, and keep a durable record of what was decided and why. Where the engine reasons, AtlasProof makes that reasoning visible, reviewable, and actionable for a team.

The API matters as much as the interface. Most teams do not want verification to be a separate destination they visit; they want it woven into the systems they already run. So AtlasProof exposes the engine over an API that a product can call inline, before an AI output is shown to a user or handed to an agent. The workspace and the API are two doors into the same room.

// Conceptual client call — illustrative, not a live endpoint contract.
const result = await atlasproof.verify({
  output: draftAnswer,
  context: { sources, policyId: 'disclosures-v2' },
  checks: ['grounding', 'consistency', 'policy'],
})

if (result.band === 'review') {
  routeToHumanReview(result)
}

How a request flows

It helps to trace a single verification from request to record. Each step below is a boundary between layers, and each boundary is where the system stays honest about what it knows.

1. A product calls AtlasProof with an AI output and its supporting context.
2. AtlasProof hands the request to the Proofence Engine, which runs independent checks.
3. The engine returns a verdict, the contributing signals, and the evidence trail.
4. AtlasProof presents the result: a clear pass, a routed review, or a blocked output.
5. The decision and its evidence are recorded so it can be audited later.

The engine decides what to trust. AtlasProof is where a team decides what to do about it.— Proofence Product

Where AirTrustOS fits

For larger organizations, verifying individual outputs is necessary but not sufficient. They also need to govern which policies apply where, who can approve exceptions, and how trust decisions roll up across many teams and systems. That is the role of AirTrustOS by Proofence, the enterprise governance control plane. It sits above AtlasProof and sets the rules that the workspace and the engine enforce.

The path from Proofence Engine to AtlasProof, and onward to AirTrustOS, is really a path from a capability to a practice. A trust decision on its own is a technical result. Wrapped in a workspace and an API, it becomes something a team can build on. Governed by a control plane, it becomes something an organization can stand behind. The layers are separate so that each can do one thing well, and connected so that trust never has to be reinvented at every surface.