Prism — install and operate
Prism is a chat application over your engineering data: it correlates Agent Router spend, GitHub pull requests and Jira issues, and answers questions about them in plain English.
It is delivered as an appliance. You receive a set of container images and a Helm chart pinned to one immutable version, you run them on your own infrastructure, and nobody from Tetrate can reach the running system. Every page here is written on that assumption: anything you need to diagnose, you can diagnose from inside, and anything you need to send us, the product will produce for you.
These docs describe this version. You can read them three ways, and they are the same pages each time: as these files, inside the chart tarball you installed from; in your running Prism, under Docs — which is this same set, baked into the image, so it always matches the version you are on; and on the Tetrate docs site, which tracks the current release.
Start here
These pages are in four groups, and which one you want depends on where you are rather than on what you are looking for.
Install — getting it running at all.
| Page | What's in it |
|---|---|
| Installing Prism | What to prepare, how to mirror the images, and the install itself |
| The model | Which model Prism calls, and how to point it at a different one |
Operate — the jobs with a right order and a check at the end. Procedures is the index; the ones you are most likely to want first are proving the egress before you install, taking a source live, and turning on email sign-in.
If you have a Snowflake view of your own people and want per-person answers, connecting your Snowflake directory is the one job on that list you author rather than configure — it is the source every other source's per-person figure is resolved through.
Troubleshoot — something looks wrong.
| Page | What's in it |
|---|---|
| The self test | The built-in diagnostic — the first thing to run, and the thing to send us |
| Known failure modes | Symptom by symptom, and what each one actually means |
Reference — the numbers and the settings.
| Page | What's in it |
|---|---|
| Limits | How far back the data reaches, how fresh it is, how many people at once — and what Prism refuses to answer |
| Install parameters | Every value you can set, generated from the chart |
| How Prism reads GitHub | What the token needs, what Prism reads, and why the sync will not put load on your org |
| How Prism reads Jira | Why the Jira sync will not put load on your instance |
| How Prism reads GitLab | What the token needs, which groups get read, and why GitLab figures stay in GitLab |
And release notes: what changed, and what to read before upgrading. Release and CVE policy is how often those arrive, and how fast a vulnerability gets fixed in one.
If your deployment has a page under customers/, read it alongside
Installing Prism — it carries the names, hosts and ticket numbers
specific to your environment, and it overrides the generic examples here. That
page ships only in your chart tarball; it is deliberately not on the docs site
and not in the app.
What you're getting
Eleven images and one Helm chart, tagged with an immutable version (never
latest). Ten are built from this repo; pgvector is a third-party image
mirrored into the same release, so it arrives scanned and digest-pinned like
the others and your cluster never pulls from Docker Hub. All are linux/amd64
and, bar the bundled Postgres, run as a non-root UID under OpenShift's
restricted-v2 SCC — no SCC exception is needed.
| Image | What it is |
|---|---|
prism-app | the chat UI (FastAPI, SSE) |
agent-runner | the agent runtime — holds the Agent Router connection |
management-mcp | Agent Router spend/usage stats |
github-stats-mcp | GitHub PR stats |
jira-stats-mcp | Jira story-point stats |
github-live-mcp | live per-repo GitHub drill-down; off by default (mcps.githubLive.enabled) |
semantic-mcp | the semantic query MCP — structured queries over every connected context stream's declared model; on by default since 0.10.0 (mcps.semanticMcp.enabled), and the only reader GitLab, an Oracle snapshot and an uploaded staff list have |
discovery-mcp | the discovery session's read-only tools — reading a context stream's published API description, sampling its tables, proposing a manifest for an administrator to approve. Experimental, on by default since 0.16.0 (mcps.discoveryMcp.enabled; set it false to switch it off) |
synth-seed | one-shot job: seeds the synthetic dataset |
prism-ingest | one-shot job + CronJob: ingests real GitHub/Jira data |
pgvector | the bundled Postgres (mirror of docker.io/pgvector/pgvector:pg16); used only when postgres.bundled=true |
The exact digest-pinned list for this release ships as images.txt inside
the chart tarball, at prism/images.txt — see step 2 of Installing
Prism. Registry pull credentials come separately.
What you provide
Four things, and only the first is strictly required to see Prism working:
- An Agent Router gateway and one inference key. The single mandatory external connection — all inference rides it.
- A Postgres instance. Two logical databases: one for the data, one for the agent runtime's own state.
- A namespace to run in, with egress to the gateway.
- Eventually: your real data sources — GitHub, Jira, Router spend. Not needed to start; see "Day one" below.
Day one: nothing connected
The install is designed to come up with nothing connected except the Agent Router. A seed job generates a synthetic organisation — identities, pull requests, Jira issues, spend — so the application demonstrates end to end immediately, before any firewall request or service account has landed.
Each source then flips to live independently with a helm upgrade, as its
access is approved. Nothing has to be ready on day one except the model path.
How we scan the images
Every image is scanned with Trivy at release time, and a fixable CRITICAL or HIGH finding stops the release. Release and CVE policy is the whole statement: the release cadence, how fast we ship a fix for a critical, and what we do with a finding that has no fix to take.
That is a statement about our release process, not a prediction about your scan. Scanners disagree, vulnerability databases update after we publish, and your gate may be configured to flag things ours does not. If your scan reports something on one of our images, send us the finding: we will tell you whether a fix exists and, if it does, which release carries it.