# LNSAT: technical architecture and source build

LNSAT is public, experimental 0.1.0 source for policy-governed authorization and evidence around consequential agent actions. It is not a supported end-to-end V1 installer, package, container, hosted service, or proven Docker runtime.

Public source reviewed: October 12, 2026. Canonical: https://hypler.com/lnsat

## One request, one authority path

LNSAT treats a consequential action as a bounded request with evidence. A model recommendation, connector credential, or available tool does not independently authorize execution.

### Packet to receipt

A packet records the proposed action: actor, target, payload, digest, requested scope, and evidence inputs. Policy evaluates that exact packet and returns an allow, deny, or approval-required result.

When policy requires a human decision, scoped approval binds that specific request. Durable one-time authorization is consumed before a bounded adapter attempts execution. The result becomes a receipt; an uncertain external result is recorded as outcome_unknown and sent to reconciliation before retry or settlement.

Why this choice: It keeps a proposed action, its decision, and its observed result traceable as one bounded record.

```sh
packet
  -> policy
  -> scoped approval (when required)
  -> durable one-time authorization
  -> bounded adapter
  -> receipt | outcome_unknown -> reconciliation
```

### Approval binds request identity

An approval is not a reusable permission slip. Changing the actor, target, payload, artifact digest, or permitted scope creates a different request and invalidates the earlier approval.

That identity rule lets an operator review a concrete consequence. It also keeps approval evidence connected to the packet that was evaluated instead of a broad intent or a later modified action.

Why this choice: It prevents a decision about one action from being reused after the action materially changes.

### Source documentation

- [README.md](https://github.com/hypler-dev/LNSAT/blob/main/README.md)
- [Authority layer and reference workflow](https://github.com/hypler-dev/LNSAT/blob/main/docs/architecture/AUTHORITY_LAYER_AND_REFERENCE_WORKFLOW.md)
- [Project status](https://github.com/hypler-dev/LNSAT/blob/main/docs/PROJECT_STATUS.md)

## Typed contracts at the authority boundary

LNSAT separates request contracts, policy decisions, durable authorization records, adapters, receipts, and inspection surfaces so one capability does not silently become authority to act.

### Rust durability and service seams

The Rust surface includes lnsat-contracts for typed authority contracts, lnsat-auth for local authentication, lnsat-store for durable state, and lnsatd for service behavior. These seams express the source architecture; they do not establish a supported production service.

SQLite durability work and the audit PostgreSQL migration foundation are separate concerns. Their presence in source must not be read as a claim of one finished, supported storage deployment.

Why this choice: Compiled, typed seams make the local authority core and its durable records easier to inspect and test.

### TypeScript integration surfaces

The TypeScript packages cover packets, policy, gateway, audit, MCP, CLI, and core concerns. API and optional console surfaces make the source inspectable during development, while the Gateway remains the boundary where a proposed consequential action enters the authority path.

A console preview can help inspect source behavior. It is not an enforcement plane, a hosted offering, or runtime proof.

Why this choice: Shared interface contracts let source tools and inspection surfaces describe the same bounded request.

### Source documentation

- [System architecture](https://github.com/hypler-dev/LNSAT/blob/main/docs/architecture/SYSTEM_ARCHITECTURE.md)
- [Architecture and developer guide](https://github.com/hypler-dev/LNSAT/blob/main/docs/architecture/ARCHITECTURE_AND_DEVELOPER_GUIDE.md)
- [Rust crates](https://github.com/hypler-dev/LNSAT/tree/main/crates)
- [TypeScript packages](https://github.com/hypler-dev/LNSAT/tree/main/packages)

## Policy decides; reconciliation resolves ambiguity

LNSAT keeps authorization separate from execution outcome. A successful authorization does not prove an external action completed, and an unknown result is not permission to repeat it.

### Deterministic policy outcomes

Policy works on a bounded packet and its declared limits. It can deny a request, allow it, or require scoped approval. This makes the decision inspectable against stated inputs instead of treating a model output as the final authority.

The product surface also carries diagnostic contracts, including lnsat.product_surface.v2. They help describe source capabilities and maturity; they do not grant execution authority.

Why this choice: Explicit outcomes make it possible to review why a proposed action was denied, allowed, or held for approval.

### Unknown is a durable state

Timeouts, disconnects, partial responses, and incomplete downstream observation can leave an action outcome unknown. LNSAT preserves that state with the request and authorization evidence rather than assuming success or retrying by default.

Reconciliation is the follow-up path: inspect evidence, determine whether an external effect occurred, and record a settled or still-uncertain result before another consequential action is considered.

Why this choice: A missing downstream response must not be mistaken for either success or safety to retry.

### Source documentation

- [Claims and maturity](https://github.com/hypler-dev/LNSAT/blob/main/docs/CLAIMS_AND_MATURITY.md)
- [Authority layer and reference workflow](https://github.com/hypler-dev/LNSAT/blob/main/docs/architecture/AUTHORITY_LAYER_AND_REFERENCE_WORKFLOW.md)
- [Project status](https://github.com/hypler-dev/LNSAT/blob/main/docs/PROJECT_STATUS.md)

## Interoperability proposes; LNSAT authorizes

Integration contracts can carry context, identity, and requested operations into LNSAT. They do not bypass the packet, policy, approval, or receipt path.

### Inspection is intentionally read-only

MCP is a read-only inspection source in the documented source surface. It can expose information about packets, decisions, and evidence, but tool discovery or tool access is not authority for a consequential action.

The Gateway admits a proposed action into the authority boundary. A bounded adapter may execute only after the applicable packet, policy, approval, and one-time authorization conditions are satisfied.

Why this choice: Observation can improve review without giving an inspection tool authority to cause an external effect.

### Interfaces are not runtime claims

A2A mapping, OAuth admission, OpenTelemetry correlation, SPIFFE identity interfaces, and Registry quarantine source contracts describe interoperability seams. They can preserve identity, traceability, or admission context without granting execution authority by themselves.

These contracts remain experimental source. They do not establish a hosted integration, customer-ready connector, deployed identity fabric, or completed end-to-end runtime.

Why this choice: An interface declaration is useful evidence of a design seam but cannot prove a deployed integration works.

### Source documentation

- [Documentation index](https://github.com/hypler-dev/LNSAT/blob/main/docs/DOCS_INDEX.md)
- [System architecture](https://github.com/hypler-dev/LNSAT/blob/main/docs/architecture/SYSTEM_ARCHITECTURE.md)
- [MCP package](https://github.com/hypler-dev/LNSAT/tree/main/packages/mcp)

## Evaluate source with release evidence in view

The public repository supports source evaluation. Its documented commands check TypeScript, Rust, source assertions, and release evidence; current strict supported-release evidence is expected to fail because no supported release is claimed.

### Pinned local prerequisites

Read the public development documentation before substituting tool versions. The reviewed public-main instructions name Node 22.22.3, npm 10.9.8, and Rust 1.97.1 for the source workflow.

Use a clean local checkout for evaluation. The commands below are source checks; passing individual checks does not convert experimental source into a supported runtime or published artifact.

Why this choice: Known tool versions make source evaluation repeatable and reveal environment-specific drift.

```sh
git clone https://github.com/hypler-dev/LNSAT.git
cd LNSAT
npm ci
npm run typecheck:workspaces
npm run test:workspaces
npm run build
npm run rust:check
npm run source:check
npm run release:check
```

### Interpret the gates honestly

npm run release:check is a strict supported-release evidence gate and is currently expected to fail. That failure documents absent release evidence; it is not a workaround prompt and should not be hidden by treating source validation as runtime proof.

npm run dev -w @lnsat/console starts a development preview for source inspection. The console preview is not enforcement. public:check is useful for checking the public source surface after the documented workflow is established.

Why this choice: A strict release gate should preserve evidence of what is still unsupported instead of masking it as a passing build.

### Source documentation

- [Local development](https://github.com/hypler-dev/LNSAT/blob/main/docs/LOCAL_DEVELOPMENT.md)
- [Rust toolchain](https://github.com/hypler-dev/LNSAT/blob/main/docs/RUST_TOOLCHAIN.md)
- [Product build sequence](https://github.com/hypler-dev/LNSAT/blob/main/docs/PRODUCT_BUILD_SEQUENCE.md)
- [Contributing](https://github.com/hypler-dev/LNSAT/blob/main/CONTRIBUTING.md)

## Read claims with the source

LNSAT public documentation is part of how an evaluator distinguishes a contract, a development surface, and a supported release claim. Start with status and maturity before relying on a single diagram or package directory.

### Suggested reading path

Read the README for repository orientation, PROJECT_STATUS for current maturity, and CLAIMS_AND_MATURITY for what the source does and does not claim. Then use the documentation index to choose local development, build sequence, architecture, and security material relevant to the question.

The resulting picture should remain narrow: public GitHub source is the authority for these technical claims, at version 0.1.0 experimental pre-release. No supported end-to-end V1 installer, package, container, hosted service, or real Docker runtime proof is available.

Why this choice: Maturity, status, and scope should frame interpretation of implementation details.

### Participation and boundaries

CONTRIBUTING describes source participation. SECURITY identifies the repository security process. LICENSE states the license boundary. Each is useful context for evaluation, but none changes the maturity of the executable surface.

For a current technical decision, check the linked public-main document revisions directly. Documentation here summarizes the reviewed source rather than replacing it.

Why this choice: Contribution and security processes help an evaluator engage with source without overstating release maturity.

### Source documentation

- [README.md](https://github.com/hypler-dev/LNSAT/blob/main/README.md)
- [Project status](https://github.com/hypler-dev/LNSAT/blob/main/docs/PROJECT_STATUS.md)
- [Documentation index](https://github.com/hypler-dev/LNSAT/blob/main/docs/DOCS_INDEX.md)
- [Security policy](https://github.com/hypler-dev/LNSAT/blob/main/SECURITY.md)
- [License](https://github.com/hypler-dev/LNSAT/blob/main/LICENSE)

## Operating-system targets need separate qualification

LNSAT has no proven supported runtime on any operating system listed here. These rows record planned evaluation targets only; each operating system and architecture requires independent server or headless evidence before any runtime-support claim.

### Qualification is per target

The Linux distribution rows are distinct planned server or headless targets. Their architecture selection, install path, service lifecycle, storage behavior, and recovery evidence remain under development.

Windows and macOS targets name the planned processor architecture explicitly. They remain under development; each requires corresponding qualification evidence.

Why this choice: One successful source check or development preview cannot establish a portable runtime across operating systems, releases, architectures, or headless server conditions.

### Support status stays explicit

Every card identifies a specific planned operating-system target, the intended evaluation context, and whether its architecture has been named. Each row remains under development and requires its own qualification evidence.

A planned target is not a supported runtime. No installer, package, container, service, support commitment, or production qualification is claimed by this page.

Why this choice: A target list is useful only when it makes the missing evidence visible before an operator relies on it.

### Platforms under development

These are planned evaluation targets. Each operating system and listed architecture needs its own server or headless qualification evidence before LNSAT can claim runtime support.

#### [Ubuntu](https://ubuntu.com/)

Linux server / headless. Under development.

- **Server/headless architecture: Under development** No architecture-specific target or qualification result is claimed.

[Platform and brand reference](https://design.ubuntu.com/brand)

#### [Debian](https://www.debian.org/)

Linux server / headless. Under development.

- **Server/headless architecture: Under development** No architecture-specific target or qualification result is claimed.

[Platform and brand reference](https://www.debian.org/logos/)

#### [Rocky Linux](https://rockylinux.org/)

Linux server / headless. Under development.

- **Server/headless architecture: Under development** No architecture-specific target or qualification result is claimed.

[Platform and brand reference](https://docs.rockylinux.org/teams/web_design/)

#### [Red Hat Enterprise Linux (RHEL)](https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux)

Linux server / headless. Under development.

- **Server/headless architecture: Under development** No architecture-specific target or qualification result is claimed.

[Platform and brand reference](https://www.redhat.com/en/about/brand/standards)

#### [Fedora](https://fedoraproject.org/)

Linux server / headless. Under development.

- **Server/headless architecture: Under development** No architecture-specific target or qualification result is claimed.

[Platform and brand reference](https://fedoraproject.org/wiki/Logo)

#### [SUSE Linux Enterprise (SUSE Enterprise)](https://www.suse.com/products/server/)

Linux server / headless. Under development.

- **Server/headless architecture: Under development** No architecture-specific target or qualification result is claimed.

[Platform and brand reference](https://brand.suse.com/suse-logo)

#### [openSUSE](https://www.opensuse.org/)

Linux server / headless. Under development.

- **Server/headless architecture: Under development** No architecture-specific target or qualification result is claimed.

[Platform and brand reference](https://en.opensuse.org/openSUSE:Trademark_guidelines)

#### [AlmaLinux](https://almalinux.org/)

Linux server / headless. Under development.

- **Server/headless architecture: Under development** No architecture-specific target or qualification result is claimed.

[Platform and brand reference](https://wiki.almalinux.org/branding.html)

#### [Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/what-is-amazon-linux.html)

Linux server / headless. Under development.

- **Server/headless architecture: Under development** No architecture-specific target or qualification result is claimed.

[Platform and brand reference](https://docs.aws.amazon.com/linux/)

#### [Arch Linux](https://archlinux.org/)

Linux server / headless. Under development.

- **Server/headless architecture: Under development** No architecture-specific target or qualification result is claimed.

[Platform and brand reference](https://terms.archlinux.org/docs/trademark-policy/)

#### [Windows](https://www.microsoft.com/windows/)

Desktop / service-host evaluation. Under development.

- **x86-64: Under development** No Windows x86-64 install, lifecycle, or runtime qualification is claimed.

[Platform and brand reference](https://learn.microsoft.com/en-us/windows/apps/publish/partner-center/trademark-and-copyright-protection)

#### [macOS](https://www.apple.com/macos/)

Desktop / service-host evaluation. Under development.

- **Intel x86-64: Under development** No Intel macOS install, lifecycle, or runtime qualification is claimed.

- **Apple silicon M-series arm64: Under development** No Apple silicon macOS install, lifecycle, or runtime qualification is claimed.

[Platform and brand reference](https://www.apple.com/legal/intellectual-property/guidelinesfor3rdparties.html)

### Source documentation

- [LNSAT project status](https://github.com/hypler-dev/LNSAT/blob/main/docs/PROJECT_STATUS.md)
- [LNSAT claims and maturity](https://github.com/hypler-dev/LNSAT/blob/main/docs/CLAIMS_AND_MATURITY.md)

## Language choices support bounded authority

LNSAT's implemented source stack uses Rust for a compiled durable and local authority core, TypeScript for interfaces and contracts, and SQL-backed transactional storage. This describes the source architecture, not an assertion that every language or boundary has production runtime proof.

### Rust: compiled durable authority core

Rust crates such as lnsat-contracts, lnsat-auth, lnsat-store, and lnsatd provide typed contracts, authentication primitives, durable records, and service seams. The intent is a local, compiled core where packet identity, one-time authorization, and receipt transitions are explicit.

This is a source-level design choice. It does not prove a supported daemon, installer, container, or hosted service.

Ownership and borrowing let Rust reject classes of invalid-reference and lifetime errors at compile time without a garbage collector. Explicit Result values make failures visible to callers. Unsafe code, native dependencies and authorization logic still need separate review; compiler checks cannot decide whether an action is permitted.

Why this choice: Rust supports memory-safe resource handling and explicit error states near the durable authority boundary. The tradeoff is stricter ownership rules and a more demanding systems build workflow.

[Rust systems security](/wiki/rust-systems-security)

### TypeScript: interfaces and integration contracts

TypeScript packages cover packets, policy, gateway, audit, MCP, CLI, and core functions. Their contracts keep developer tooling and inspection surfaces aligned with the typed authority model while the Gateway remains the execution admission boundary.

TypeScript supplies interfaces, discriminated states and compile-time checks while running as JavaScript on Node.js or in the browser. Its types are erased at runtime, so incoming packets and external responses still need validators. Shared types accelerate interface development; they do not authenticate input or enforce policy by themselves.

Why this choice: Shared types make API, CLI, MCP and UI contracts easier to evolve together. Runtime validation remains essential because compile-time types do not inspect untrusted JSON.

[TypeScript contracts and interfaces](/wiki/typescript-contracts-interfaces)

### SQL durability: transactional evidence storage

SQLite durability and the audit PostgreSQL migration foundation are distinct source concerns. Transactional storage preserves authority records, receipts, and recovery evidence without collapsing local durability into a claim of completed audit deployment.

Security functions remain bounded: packet identity, policy evaluation, scoped approval, one-time authorization, read-only inspection, receipt recording, outcome_unknown, and reconciliation.

SQLite supplies embedded transactions for local state without a separate database server. PostgreSQL offers a distinct server-based concurrency and audit-migration foundation. A database transaction can protect local record updates, but it cannot atomically guarantee that an external tool effect happened exactly once.

Why this choice: Authorization and recovery require durable, inspectable transitions so unknown outcomes can be reconciled rather than silently retried.

[SQL durability and audit](/wiki/sql-durability-audit)

### Authentication protects identity; approval binds the action

The Rust lnsat-auth crate includes Argon2id password handling and protected secret representations. SQLite retains identity and session state. A successful login establishes an authenticated session; the exact action still has to satisfy policy, scope, approval and one-time authorization requirements.

These are current experimental source functions. OS-mediated login, selected disk-encryption providers and a supported production authentication service require their own implementation and qualification evidence.

Why this choice: Separating identity verification from action approval prevents a valid session from becoming blanket permission for every future request.

[Human approval as a system boundary](/wiki/human-approval)

[Rust systems security](/wiki/rust-systems-security)

### Canonical bytes and digests bind reviewed content

Packet validation and canonical hashing make the request identity reproducible. The public contracts define the bytes and domains that particular digests commit to, so a modified target or configuration can be distinguished from the reviewed request.

A matching digest establishes a commitment to content. It does not authenticate a live target, prove the caller owns that target, or authorize execution. Those checks belong to the complete Gateway authority path.

Why this choice: Approval evidence must refer to the exact reviewed content; hashes cannot replace identity, policy or observed execution evidence.

[Runtime contracts and TypeScript interfaces](/wiki/typescript-contracts-interfaces)

### Source documentation

- [System architecture](https://github.com/hypler-dev/LNSAT/blob/main/docs/architecture/SYSTEM_ARCHITECTURE.md)
- [Rust crates](https://github.com/hypler-dev/LNSAT/tree/main/crates)
- [TypeScript packages](https://github.com/hypler-dev/LNSAT/tree/main/packages)
- [Security policy](https://github.com/hypler-dev/LNSAT/blob/main/SECURITY.md)
- [Local authentication source](https://github.com/hypler-dev/LNSAT/tree/main/crates/lnsat-auth)