Tenure deploys inside your Kubernetes cluster. OIDC authentication, hard scope isolation between engineers and projects, a complete per-turn audit trail, and an orientation tax dashboard that makes the productivity case without anyone having to construct it.
Helm chart · OIDC / SSO · No egress · MIT licensed
An engineer established last week that the auth service uses Redis for sessions, that Postgres is off the table for this use case, that the failure mode is fail-open. This session: the AI doesn't know any of it. They explain it again. Then again tomorrow. Then a new engineer joins and explains it from scratch.
That's the orientation tax — the fraction of every AI session spent re-establishing context the system should already have. Tenure measures it, shows it decreasing, and makes it go away.
Most enterprise AI deployments have no answer for the question security teams always ask eventually: what exactly is being injected into the model's context, for which engineers, and when? Tenure answers it completely — because making injection visible only makes sense if you're confident in what it shows.
Every belief injected into every session is logged — which belief, which query surfaced it, which engineer, which turn. Not reconstructed from logs after the fact. Recorded as it happened.
Engineers run with extraction on and injection off for as long as they need. They see exactly what Tenure learned before it ever changes a response. No surprises. No behavior change until they're ready.
Re-explanations prevented, time saved, tax still paid — per engineer, across the org, trending over time. The productivity case builds itself from real usage data. No narrative required.
Admins see all users' beliefs, audit logs, and injection history from a single dashboard. Understand what the AI knows about your codebase and your engineers before anyone asks you to prove it.
Scope isolation in Tenure is a hard filter, not a probabilistic one. A session
in project:client-a cannot surface beliefs from project:client-b
regardless of semantic proximity. When an engineer switches projects, the belief
context pivots immediately with no residual injection from the previous scope.
This is not a tuning parameter. It is an architectural consequence of treating memory as typed state rather than a search index. No surveyed memory system provides an equivalent guarantee.
Scope is probabilistic. Semantically proximate beliefs from other projects can surface regardless of which project is active. Drift scores of 0.92–1.0 on session re-entry in independent evaluation.
Scope is a hard filter applied before retrieval scoring. Out-of-scope beliefs are structurally absent — not down-ranked, absent. Drift score: 0.0 across all session turns in independent evaluation.
project:client-a cannot surface beliefs from project:client-b regardless of query content. Verifiable, not claimed.Tenure ships as a Helm chart. One HTTPS endpoint. No egress. OIDC delegates authentication to whatever your org already uses — Okta, Azure AD, Google Workspace, anything that speaks OIDC. Your IT team approves it once. Engineers connect through their existing identity.
On first install, the VS Code extension asks for an existing Tenure endpoint. Engineers enter the domain your IT team deployed to. The extension validates it, handles the OIDC browser flow, and stores the scoped token in VS Code's native secret store. No config files. No plaintext credentials. No IT ticket per engineer.
Engineers run in observe mode for as long as they need — days, weeks. Tenure extracts beliefs silently. Nothing changes about their AI responses. When they open the beliefs panel and see exactly what the model will know, they turn injection on. Your admins see the same panel, org-wide, from day one.
The admin dashboard tracks re-explanations prevented, time saved, and tax still paid — per engineer and across the org, trending over time. You don't need to argue for continued investment. The metrics do it.
| Question | Answer |
|---|---|
| Does data leave our network? | No. Zero egress. The Helm chart has no outbound connections. Beliefs are stored inside your cluster. |
| How is authentication handled? | OIDC. Tenure delegates to your existing IdP. No new credential store. User provisioning, MFA, and offboarding are inherited from whatever you already use. |
| What ports does it open? | One HTTPS endpoint on the port you configure. The VS Code panel uses SSE over the same connection. No other open ports. |
| Can one engineer's context bleed into another's? | No. Scope isolation is a hard filter at the architecture level, not a threshold or probabilistic suppression. Verifiable against the published benchmark. |
| What is stored and where? | Structured beliefs extracted from AI sessions. Stored in a PersistentVolume inside your cluster. Encrypted at rest. Exportable as an encrypted archive. |
| Is there an audit trail? | Complete per-turn injection log. Every belief injected, which query surfaced it, which engineer, which session. Admins have full visibility across the org. |
| What is the license? | MIT. No vendor lock-in. No licensing server. No call-home on startup. |
You don't need a procurement process to start. Deploy the Helm chart in your existing dev environment — the one your IT team has already provisioned and security has already reviewed. Engineers try it there. The orientation tax dashboard generates the numbers. Those numbers become the internal case for production without anyone having to construct a narrative.
The path from dev environment to org-wide deployment tends to be pull, not push. Engineers who stop re-explaining their stack don't want to go back.
The Helm chart is the same chart you'd use in prod. Deploy it in dev first. Same security properties, same OIDC config, same audit trail. Nothing changes when you graduate it.
After a few weeks in dev, the orientation tax dashboard has real data. Re-explanations prevented. Time saved. Tax trending down. That's a business case without a slide deck.
By the time procurement is involved, your security team has already reviewed the same Helm chart running in dev. The review is a formality, not a discovery process.
Engineers who found Tenure individually and want to bring it to work have a path. Point IT at this page. Hand them the Helm chart. The conversation starts from evidence, not promises.
Helm chart, OIDC configuration reference, and security review documentation are in the deployment guide. MIT licensed. No account needed. Nothing calls home.
Helm chart · OIDC · MIT licensed · No egress · No account needed