Havenlon System Glossary

A hardware-enforced execution control infrastructure for high-risk digital execution. It separates execution authority from software, people, AI agents, and SaaS backends, then places that authority inside layered constraints, hardware trust boundaries, and verifiable evidence chains.

The core security philosophy of Havenlon. It assumes no single layer is always trustworthy, so identity, authorization, policy, execution, and evidence are split into separate trust boundaries.

The core capability layer that decides whether a critical action should be allowed before it actually happens. It evaluates initiation, approval, policy fit, risk triggers, and final execution permission.

The layer that proves how a critical action actually happened. It focuses on whether the full execution path can be reconstructed, verified, and audited after execution.

The evidence system behind critical execution. It links initiation, authorization, policy decision, and final execution into one traceable path for verification and accountability.

The evidence anchor for a critical action. It connects the request, approval, policy decision, and execution record around the same execution intent so the path stays traceable and consistent.

A high-risk action proposal that may create an external result, such as transfers, signatures, broadcasts, API executions, payments, device control, or operational actions. It is a proposal, not final execution.

A change to the system’s governance state. It may not move assets directly, but it changes who can execute, who can approve, or how execution is controlled.

A mechanism that prevents external systems from changing execution reality by themselves. The first step is proposal, and the second step is signed confirmation inside the controlled boundary.

The execution path of Two-Step Signed Commit. Critical changes do not become effective because a SaaS database changed; they must pass through a controlled confirmation path inside the device trust boundary.

The local evidence buffer inside key devices. It is not an unlimited log database; it keeps critical execution evidence locally when needed and supports later synchronization and verification.

A principle that execution should not continue indefinitely when critical evidence cannot be reliably produced or synchronized. The system should reduce or stop high-risk execution when evidence integrity cannot be maintained.

The coordination layer in Havenlon. It provides workflow, user experience, notification, state display, evidence archive, and business integration, but it is not the final trust root.

The device-side governance state that defines who can execute, who can approve, and which rules apply. SaaS may display it, but the effective governance state must be recognized inside the device-side boundary.

The physical trust boundary of Havenlon. Critical execution and governance changes must be confirmed inside this boundary rather than relying on platform-side trust.

The governance and arbitration core of Havenlon. It handles policy, approval, routing, risk control, device state, governance state, and pre-execution decisions on the customer side.

The identity initiation device. It proves who is initiating a request for a critical action, but identity initiation does not equal authorization and cannot complete final execution by itself.

The authorization confirmation device. It proves who approved a critical action and can participate in approvals for transfers, contract calls, governance changes, policy updates, and device binding.

The hardware-sealed execution endpoint for real-world business systems. It is designed to turn exposed credentials such as API keys, certificates, payment credentials, and operational secrets into controlled execution.

The final secure execution boundary. It is responsible for final signing, key usage, secure execution, and execution proof, and is not directly exposed to apps, SaaS, or ordinary software layers.

The arbitration component inside the Havenlon hardware system. It participates in policy judgment, request filtering, execution routing, risk checking, and controlled access to secure execution.

The entry evidence that records what the user saw and did at the application entry point. It captures interaction evidence, not final execution proof.

The log that records which execution intent was submitted by the user’s own business system. The business system initiates the intent, while Havenlon controls whether and how it can be executed.

The log that proves which identity initiated a specific intent through a Pass Key.

The log that proves which authorized party approved or rejected a specific intent.

The log that proves how Hub evaluated a critical intent under the applicable policies and risk rules.

The log that proves whether a real-world execution action occurred, such as API execution, signing, encryption, payment submission, or device control.

The log that proves whether final secure execution happened inside the secure execution boundary. It is one of the most important forms of final execution proof.

The archive layer that stores, displays, searches, exports, and audits evidence records. It manages evidence visibility, but the truth of evidence must still be proven by device-side confirmation.

A compact set of public statements that defines Havenlon’s stance on security, trust, execution control, evidence, and device-side confirmation.