HX/ the human experience framework
The fortress · open source

The record restson your servers.

HX Fortress is the storage half of the framework: one service, run by your organization on its own infrastructure — session metadata in its own Postgres, transcript content in your own bucket. The console it serves is built for the person who answers for all of that: where the data rests, what can leave the host, and who did what.

Every screen, annotated →github.com/hx-framework/hx-fortress
HX Fortress console overview: health strip for Postgres, blob storage, relay tunnel, embeddings and ingest; residency verified; needs-attention list
The console: five subsystems at a glance, residency verified against every session nightly, and anything that needs a human raised as a banner.
What runs where

A service, a console, a relay

The fortress is deliberately boring to operate: one binary, one systemd unit, storage the organization already knows how to govern. The interesting part is how much of its behavior it can prove.

hx-fortress — the service

One service on a host your organization controls: session metadata in its own Postgres, transcript content in your own bucket, an indexing worker for search. Installed once, enrolled once, run under systemd.

The console — served from the fortress

The administration surface ships inside the service and is served from the fortress host itself. It shows session metadata only — counts, sizes, destinations, health. Transcript content never appears in it.

The relay — outbound only

The HX Fortress relay carries enrollment, liveness, and routing pointers so clients can find their fortress. The tunnel is outbound-only, and transcript bytes never touch it — a claim the console proves on demand.

Diligence

What a due-diligence review finds

Decision-makers evaluating HX are really evaluating custody: can this organization say, at any moment, where every session rests and who could have read it? The fortress console is built so the answer is always a screen you can open and a check you can run, not a promise in a document.

1Residency, proven nightly. Every session is audited against where it is supposed to rest — 12,847 of 12,847 in the demonstration fortress — and any single session can be spot-checked live: four checks against the fortress Postgres, the bucket, the staging prefix, and the relay index, ending in a proof block an administrator can copy into a ticket.
2Egress, enumerated. The posture page lists every way bytes can leave the host, and states the standing rule beside it: anything not on the list does not happen. The relay tunnel is outbound-only metadata, the embeddings endpoint is a configurable fact, binary downloads are checksum-verified, and bucket writes stay in the organization's region under the organization's keys.
3Retention, on the organization's terms. Transcripts rest in the organization's bucket under the organization's own lifecycle policy, with versioning keeping a recoverable prior version. Service logs live 90 days on disk; the console's audit trail is kept 180 days and exports.
4An audit trail for the console itself. Every state-changing action an administrator takes is logged — credential rotations, storage changes, exports — newest first, with read-only views deliberately not logged. A one-page compliance report generates on demand and downloads as PDF, written to be handed to a security review.
5Honest failure states. The console is designed around the bad day. A failed Postgres boot renders a step-by-step walkthrough instead of a stack trace. A storage migration that fails mid-copy switches nothing and resumes idempotently. And the residency incident — sessions resting somewhere they shouldn't — exists as a previewable state, so the team has rehearsed the alarm before it ever rings.

The policy side — retention policy language, lawful basis, works councils — is covered by the policy kit and its GDPR annex; the person-level guarantees live in Trust.

Run the proof

Residency you can spot-check

The residency proof is the console's most important screen. Four checks run live — the Postgres row, the bucket object byte-for-byte against its metadata, the staging prefix for orphans, and the relay index for content — and end in one sentence an auditor can quote.

The Verify Residency dialog: four live checks against the fortress Postgres, the enterprise bucket, the staging prefix, and the HX Fortress relay, ending in a copyable proof block
The same dialog opens from a session, from the audit page, or from a cold URL — a spot-check is never more than one link away. It ends: resides on enterprise systems, with a proof block to copy.
The residency page previewing its incident state: verified and at-the-relay counts split, the fleet audit, per-session spot checks, the four routing gates, and audit history
The incident state, previewable on purpose: the exact failure the residency page exists to catch — rehearsed, with the fix on screen, before it ever happens.
The console, screen by screen →The trust architecture
Open source · MIT

One service, yours to operate

hx-fortress is one binary and one systemd unit, MIT-licensed, stewarded like the rest of the framework. Everything the console shows is also a command against the same host, so automation and humans read the same facts.

  • hx-fortress enrollbinds the fortress to the organization — once
  • hx-fortress statusservice, Postgres, bucket, relay tunnel — the overview, in a terminal
  • hx-fortress credentials setrotates the vault, storage, or embeddings credential in place
  • hx-fortress logsthe same stream the console tails, in the same format
  • hx-fortress updatedownload, verify checksum, install, restart
Read the source →The client — the other half