Documentation

Most organizations can observe AI or software activity, but still cannot reliably answer the harder questions after something consequential happens: What did the system do? Was it allowed? What trust state existed at that moment? Can we still prove it later?

Entraphy Systems exists to close that gap between visibility and verifiability.

Existing tools usually solve adjacent problems. Observability platforms show telemetry. SIEMs collect events. Model monitoring tracks behavior. Governance tools document process.

Entraphy Systems focuses on decision-time legality, trust state, replayable evidence, and portable proof. It is positioned as a system of record and proof substrate, not just another dashboard, gateway, or monitoring product.

This page explains the Entraphy Systems platform operating model, not just one product feature.

Buyers need to understand Entraphy Systems as a control-and-proof system, not just a monitoring tool. The core model is: signals → trust state → policy → action → proof.

Most systems explain events after they occur. Entraphy Systems is designed to evaluate and preserve proof at the point of consequence, so later review is grounded in what was true when the action happened, not just in what logs survived later.

Depending on the flow, the customer can receive Trust Flight Recorder records, Proof Receipts, replayable evidence, trust-state outcomes, and portable verification artifacts.

One of the biggest objections is fear of rip-and-replace. Customers want to know whether Entraphy Systems requires them to centralize all telemetry, replace Splunk, Datadog, or OpenTelemetry, or accept a new runtime bottleneck. The answer is no.

Organizations already have telemetry, logs, and controls, but they often lack a defensible proof layer around consequential actions.

Entraphy Systems ingests bounded evidence from surrounding systems, normalizes those inputs into canonical evidence objects, evaluates trust-relevant decisions, and emits proof artifacts, trust outcomes, and replayable records. It is designed around bounded evidence and compact artifacts, not raw-data gravity.

Entraphy Systems is the company and trust-proof platform.

Trust Flight Recorder for AI is the proof product.

Blacksmith is the autonomous hardening product.

Trust Flight Recorder for AI proves what happened, whether it was allowed, and what evidence supported the decision.

Blacksmith pressures boundaries, validates what is real, repairs what is admissible, and remembers how the system hardened over time.

Blacksmith hardens. Trust Flight Recorder for AI proves.

Customers usually do not start with the full platform all at once. They start with one meaningful workflow, one decision surface, or one trust problem that is painful enough to justify proof.

Some teams start with the company platform view, some start with Trust Flight Recorder for AI, and some start with Blacksmith.

For many, the first commercial wedge is Trust Flight Recorder for AI because it shows legality proof at decision time, replayable evidence, portable proof artifacts, and independent verification outside the original runtime.

Trust Flight Recorder for AI is Entraphy Systems' proof product. It preserves a cryptographically verifiable timeline of trust history so organizations can prove what happened, whether it was allowed, what trust state existed at the point of action, and whether that proof still holds later.

The approved shorthand is: the black box recorder for trust.

AI systems and agents can act faster than teams can review them. That creates a gap between observability and defensibility.

Trust Flight Recorder for AI closes that gap by preserving proof at decision time.

Action occurs. Trust state is computed. Legality or proof is generated. A witness is sealed. Replay stays supported. The proof is exported. Verification remains possible beyond the runtime.

Logs and observability may show pieces of an event, but they often fail to prove whether the action was acceptable when it occurred.

Decision-time proof answers a harder question than observability alone: was the action allowed under the conditions that existed at that exact moment?

Replay lets a reviewer revisit a preserved decision path and examine what happened later.

The product preserves compact proof artifacts instead of forcing raw-data gravity.

The record should remain meaningful outside the originating runtime, team, or system boundary.

The Proof Pilot is the standard starting point for Trust Flight Recorder for AI.

One consequential workflow, decision-time instrumentation, replay and proof demonstration, and a portable artifact discussion.

Blacksmith is the autonomous hardening product line inside Entraphy Systems.

It is a governed hardening engine, not a passive detector.

Software and AI-adjacent systems need more than detection. They need a hardening loop that pressures boundaries, validates what is real, repairs what is safe to repair, and leaves evidence behind.

Blacksmith pressures trust boundaries, validates what is real, repairs what is admissible, and preserves witness-grade evidence as hardening memory compounds over time.

Campaign memory, regression evidence, repair history, and durable proof of how the system hardened.

Pressure. Challenge. Validate. Govern. Repair. Verify. Witness. Remember.

The loop turns hardening into a repeatable campaign instead of a one-off patch cycle.

Blacksmith is not a scanner, not a patch bot, not a generic AppSec wrapper, and not an autonomous pentest toy.

It is a governed autonomous hardening system with replayable evidence and compounding learning.

Blacksmith is the implementation-pressure and remediation system. Trust Flight Recorder for AI is the trust, inquiry, and proof substrate. Blacksmith attacks and hardens. Trust Flight Recorder for AI records, proves, and exports the evidence.

Blacksmith hardens. Trust Flight Recorder for AI proves.

Keeping them separate preserves clean architectural boundaries while making the trust system stronger over time.