Technical Appendix (Redacted)

1. Why This Appendix Exists

SEAL Legal Runtime is Refusal Infrastructure for Legal AI — a sealed governance layer in front of high-risk actions that implements Action Governance at a pre-execution gate in wired workflows.

Most of our public briefs answer what SEAL does and why it exists.
This appendix exists for a narrower audience:

• General Counsel and risk leaders who need to know there is a real, structured evidence surface, and
• Regulators, insurers, and technical reviewers who want to see the shape of the decision objects SEAL produces, without accessing internal designs or client data.

This document is:

• Redacted by design – internal schema names, rule identifiers, and implementation details are not shown.
• Descriptive, not sufficient – it proves there is a coherent evidence structure; it is not a blueprint to re-implement SEAL.

2. What SEAL Does at a Technical Level (Conceptual)

At runtime, in wired workflows, SEAL Legal Runtime:

1. Receives a governed request describing an attempted high-risk action.
   
2. Evaluates that request against your identity, vertical, motion, venue, consent, and turnaround anchors under your governance.
   
3. Produces a governed decision: approve, refuse, or supervised override.
   
4. Emits a sealed decision artifact that records the decision and its key governance anchors, designed to be written to client-owned, append-only audit storage.

Internally, this surface can be thought of in three conceptual objects:

• a Request object,
  
• a Decision object, and
  
• an Artifact object.

The rest of this appendix describes those objects at a high level.

3. Conceptual Objects (Request / Decision / Artifact)

3.1 Request Object (conceptual)

The Request  describes what is about to happen under your seal.

Typical categories captured include:

• Actor anchor
• role (e.g., attorney, paralegal, system agent),
• affiliation or practice group,
• jurisdictional status (e.g., licensed / not licensed for a venue).

• Matter & vertical anchor
• legal vertical or product line (e.g., civil litigation, employment, regulatory),
• scenario or motion type classification (e.g., routine motion, emergency filing, advisory-only).

• Venue & environment anchor
• environment label (e.g., internal test, staging, production),
• venue / jurisdiction of the attempted action.

• Authority & consent anchor
• client / matter consent status (e.g., present, missing, expired),
• relevant engagement posture (e.g., open, closed, limited scope).

• Tempo & turnaround anchor
• urgency or requested turnaround profile,
• whether the action is flagged as “routine” or “high-risk” under your rules.

This object answers:

Who is acting, on what matter and motion, in which venue, under what apparent authority, and at what speed?

3.2 Decision Object (conceptual)

The Decision captures the outcome of SEAL’s runtime evaluation.

Typical categories include:

• Outcome
• approve,
• refuse,
• supervised override (an action routed for supervisory review under your governance).

• Reason classification
• high-level reason family (e.g., missing consent, out-of-scope venue, high-risk motion requires supervision, ambiguous identity).

• Severity & posture
• severity rating or impact class for the refusal / override,
• whether the decision is final or subject to defined escalation paths.

• Timing & correlation
• timestamps associated with the decision,
• correlation references back to the originating request and downstream artifact.

This object answers:

What did SEAL decide about this attempted action, and at what level of seriousness?

3.3 Artifact Object (conceptual)

The Artifact is the evidence object — a sealed record of the governed decision.

Typical categories include:

• Artifact identity
• an artifact identifier suitable for audit and reference,
• linkage to client matter and environment at a high level.

• Governance snapshot
• a summary of the key anchors at the time of decision (actor role, vertical, scenario/motion type, venue / jurisdiction, consent state, turnaround profile).

• Decision summary
• outcome (approve / refuse / supervised override),
• high-level reason category,
• any supervisory reference (for overrides).

• Integrity & storage
• integrity proof (for example, a hash or equivalent),
• confirmation that the artifact is designed to be written to client-owned, append-only audit storage,
• properties required for regulatory, insurer, and internal review.

This object answers:

What was allowed or refused under your seal, on what basis, and how can that be proven later?

4. Illustrative Example (Redacted, Not a Spec)

The following is an illustrative example of how a governed decision might be represented conceptually. It is not our internal schema and not a full field list.

5. Failure Modes and Default Behavior (Conceptual)

For governed actions in wired workflows, SEAL Legal Runtime is designed to be fail-closed:

• If identity is ambiguous or missing,
• if consent is missing or not current under your policy,
• if the venue or jurisdiction is out of scope,
• if the motion is classified as high-risk and requires supervision, or
• if required dependent systems cannot be reached,

SEAL returns a governed refusal (or a supervised override path, where defined) rather than silently approving execution.

This behavior is described in more detail in the Governance Boundary & Coverage FAQ.
The Technical Appendix focuses on the objects created when those decisions are made.

6. Integrity, Anchoring, and Retention (High Level)

Without disclosing specific mechanisms, SEAL Legal Runtime’s artifacts are designed to be:

• Tamper-evident – changes can be detected via integrity proofs.
• Client-anchored – artifacts are designed to be written into client-controlled, append-only audit storage.
• Retention-aware – artifacts can be managed under the client’s retention and legal hold policies.

Technical implementation of integrity proofs, anchoring, and retention flows is not described here and is handled under NDA when appropriate.

7. Redaction & Confidentiality

This appendix is intentionally redacted.

It does not expose:

• internal schema names or full field lists,
• rule identifiers, code families, or decision-graph structures,
• the order or mechanics of rule evaluation,
• cryptographic algorithms, key management, or deployment architecture.

It is intended to:

• give GCs, risk leaders, and regulators confidence that SEAL has a coherent, structured evidence surface, and
• invite deeper, confidential review where appropriate.

For detailed technical discussions, we provide NDA-only briefings and artifact packs that extend this description without ever exposing client matter content.

For Regulators, Insurers, and Risk Committees

If you are evaluating SEAL Legal Runtime for oversight, audit, or underwriting purposes, this appendix is a starting point, not the end of the conversation.

We welcome:

• confidential briefings under NDA,
• structured reviews focused on governance and evidence, and
• collaborative work with your internal risk, security, and compliance teams.

SEAL Legal Runtime was built so that high-risk actions can be governed structurally, and those decisions can be proven later.