Skip to content

Roadmap & status

GaugeWright is built in shippable increments. This page is the single source of truth for what you can use today and what's coming — every other page defers here, so a capability described anywhere on the site carries the same status badge it has on this table.

The one truth to read first

GaugeWright orchestrates locally, but it does not run the model locally. The agent's reasoning is performed by the third-party LLM provider you configure, so your prompts and the in-scope context are sent to that provider over the network, in plaintext, today. What this means for who can and cannot see plaintext is spelled out in Where your data goes.

Network egress is open by default, isolation is an opt-in

The runtime's network-egress default is open, not deny-by-default (product decision, 2026-06-17): a chat can reach the model out of the box. An operator opts into network isolation per project (network_isolated, default off), which restores kernel-enforced network containment. This is a deliberate low-friction trade-off — the egress chokepoint and taint/consent gating are always on, but because the per-host egress proxy (a model-endpoint allowlist) is deferred, "open" means unfiltered host egress, so a non-isolated project carries a lower boundary ceiling than an isolated one.

What the statuses mean

These four badges are used identically across the whole docs site; if any other page ever disagrees with this table, this table wins.

  • Available — in the product you can download and use today (the local desktop workbench).
  • Built — implemented and tested in the codebase, but not yet operationally deployed (typically waiting on hosting infrastructure or go-live wiring). Not a usable end-user feature yet.
  • Planned — committed and designed, not yet built.
  • Not implemented — absent today.

Reading the split badges (e.g. \"Built · live Planned\")

Some rows carry two badges because the code and the deployment have different statuses. The first badge is the code state — core Built, verifier Built, adapter Built all mean the component is implemented and tested in the codebase. The second, live Planned, means that even though the code exists, the capability is not operationally deployed for end-users — it is waiting on the hosting infrastructure to go live. A row with live Planned is not usable today, no matter what its code badge says.

Available means today; Built does not

If a page describes a Built feature, it is describing the design and the code behind it, not something you can switch on. The only mode you can use end-to-end today is the local desktop workbench.

Today's ceiling: method secrecy from the context owner is not achievable

The only Available placement is the local desktop workbench — an unattested placement where the host is the context owner. At this placement, per the boundary ceiling, method secrecy from the context owner is not achievable — only obfuscation, via isolating the run from the host network. The model endpoint and the host are both in the trust set. Raising the method ceiling to host-blind requires an attested placement, which is Built in code but not operationally live.

At a glance

Capability Status
Local desktop workbench (build · run · review) Available
Multi-authority federation (collaborate across machines) Built live Planned
Append-only audit log + SIEM export Available
Kernel-enforced method isolation (Linux/macOS) Available
Windows method-isolation sandbox Planned
Encryption at rest — local envelope encryption (AES-256-GCM) Available
Encryption at rest — KMS-backed (server deployments) Built
Cross-party packaging & deployment Built live Planned
Attested compute (confidential VM, host-blind — provider stays in TCB) verifier Built live Planned
Enterprise identity (OIDC / SAML / SCIM / RBAC) Built live Planned
Output review & release lifecycle Built
Hosted multi-tenant platform Planned
Public hosting / embedded agents core Built live Planned
MFA enforcement Not implemented
Confidential inference (provider out of trust boundary) Planned
SOC 2 Type II · DPA · penetration test Planned

The Deployment modes page reads this same table from the angle of where the agent runs and who's involved; the Glossary carries the same badge on each term.

Two encryption-at-rest claims, kept apart

Local envelope encryption (AES-256-GCM, a random per-instance data key) is Available in the desktop workbench today. Separately, a KMS-backed adapter — the data key wrapped by a cloud KMS key, so nothing usable sits at rest and key access is KMS-gated — is Built: the adapter is implemented and verified live against a real Key Vault, but it is not operationally deployed at server scale (server hosting is the infra gap). Built ≠ switched on.

What \"attested\" does and does not remove

Attested compute (confidential VM) raises the method ceiling to host-blind: who operates the host no longer decides who sees plaintext. It does not remove your model provider from the trust boundary. Even with attestation Built, the residual trust set is {the attested GaugeWright code, the model provider} — the prompt still reaches the provider in plaintext. Only confidential inference (Planned) takes the provider out of the boundary. See Where your data goes.

Enterprise identity is Built in code, not yet operationally live

The enterprise-identity row reads Built because the OIDC and SAML SSO adapters, SCIM 2.0 provisioning, fixed-role RBAC, and the org-level enforce-SSO toggle are implemented and tested in the codebase (verified live against real IdPs) — but they cannot be switched on end-to-end without the hosted control plane, which is the infra gap. Built is the code, not a usable end-user feature.

Public hosting & embed — MVP vs. later

The browser-embeddable agent surface (a consultant embedding their agent in their own website for end-users) is being shipped as a clearly-scoped MVP first, then widened. Per-piece status below reflects what is built and tested in code versus what is operationally live. None of it is usable end-to-end today: the managed host that serves a live per-visitor session is infrastructure that does not run in the local scaffold, so the whole surface stays Planned for end-users until that host ships.

The entire embedded-agent surface is not operationally available today

No item in either table below is end-to-end usable today. Every row is either a Built component (implemented and tested in code, awaiting the managed host) or Planned. The per-row badges describe code-readiness, not a feature you can switch on.

Embed capability Status
Anonymous chat (ephemeral, identity-less, discarded on teardown) core Built live Planned
Managed-auth signed-in chat (audience via email / magic-link / social) adapter Built live Planned
My-chats — your own durable chats (drawer + standalone element) data layer Built live Planned
Chat panel + <gw-session> provider + embed.js bundle Built publish Planned
"Powered by" branding mark Planned
Consultant Deploy Config · Embed/Preview · basic Monitor Planned
Embed capability Status
Embedded output panel (read + download your own artifacts) Planned
Embedded files panel (browse your own worktree) Planned
BYO-OIDC sign-in + silent token pass-through adapter Built live Planned
Anonymous → authenticated claim flow (one-time claim token) Planned (decided, build deferred)
White-label — paid removal of the powered-by mark Planned
Attested host as a selectable deployment ceiling Planned
Server-side secret API key (backend proxying) Planned

What \"core Built\" covers here

The audience-identity seam, the durable-chat data layer, the scoped remote session, and the web-component elements (<gw-session> / <gw-chat>) are implemented and tested in the codebase. They cannot run end-to-end without the managed host that serves live per-visitor sessions, so the surface stays Planned for end-users. The end-user side is For embedded end-users; the consultant side is Package & deploy.

How the guarantees are backed

Not every status caveat is the same kind of promise. The docs keep two kinds apart so claims stay defensible:

  • Structural, machine-checked guarantees. Built into how the system works and paired with an adversarial test that fails if the protection is removed. These are the boundary properties on How GaugeWright protects your work: a handle is not access; method and context reads are both explicit; a run has no ambient authority; everything is fail-closed; history is append-only. Available
  • Policy / operational properties. Things that depend on configuration, process, or a third party — your LLM provider's retention terms, certifications, monitoring, build signing. These are not invariants and are stated as such.

The Security & trust page splits the two bucket-by-bucket for reviewers (with the optional INV-* deep links).

Per-OS caveat on the sandbox

The kernel-enforced sandbox that stops a work chat from rewriting its own method is Available on Linux and macOS. Windows method-isolation is Planned — until it ships, run untrusted methods on Linux/macOS.

Known limitations & gaps (today)

Stated here in the docs, not only on the external trust site:

  • Inference is remote and inside the trust boundary. Prompts and in-scope context go to the third-party provider you configure; its retention and training terms are the provider's, not GaugeWright's. Confidential inference (removing the provider from the boundary) is Planned. See Where your data goes.
  • Only the local desktop workbench is usable today. Cross-party deployment, attested compute, enterprise identity, and hosted/embed are Built or Planned — not operationally live.
  • No third-party certifications yet. SOC 2 Type II, DPA, and a penetration test are Planned.
  • MFA enforcement is Not implemented as a GaugeWright-native factor. The org-level require-SSO / require-MFA policy is Built (the enforce_sso and require_mfa org-security toggles landed 2026-06-18, tracker SEC-1 / ID-5); the MFA factor itself is delegated to your IdP under the enforce-SSO flag — GaugeWright declares the policy it honors, the IdP enforces the factor. The last-owner break-glass guard means enforce-SSO can never lock the org out.
  • Supply-chain & ops gaps. No SBOM / dependency scanning, no production monitoring, and unsigned builds today. These are tracked on the Security & trust page and its linked architecture documentation.

Where to go next