karti
c821b2ca07
The seam existed with only a Supabase implementation, so an on-prem deployment had no way to authenticate. A customer running PIG inside their own network already has Okta, Entra, Keycloak, Auth0 or Google Workspace; asking them to stand up a second identity system is a serious adoption tax and in a regulated environment usually refused outright. Setting PIG_OIDC_ISSUER is normally the whole configuration — the JWKS is discovered from the issuer's well-known document. PIG_OIDC_JWKS_URI skips discovery entirely for an air-gapped network. OIDC takes precedence over Supabase so an on-prem install can leave the hosted values in its environment file without them quietly taking over. Three decisions worth stating: Discovery is resolved lazily and the FAILURE is not cached. Doing it per request would put the customer's identity provider on the critical path of every API call; doing it eagerly at boot would mean their IdP rebooting takes the CRM down with it. So it happens on first use and retries on the next request. The audience check is optional but warned about loudly. Without it, a token the provider issued for ANY other application in the same tenant verifies here — a token minted for an unrelated internal tool would be accepted as a PIG session. It cannot be mandatory because some providers legitimately issue single-audience tokens. Email falls back through email, preferred_username and upn, because providers disagree, but a preferred_username without an "@" is ignored — PIG keys membership on the address, and a bare username must never become an account identity. Also fixed a warning that claimed "authentication is DISABLED" on a correctly configured OIDC deployment. That is worse than silence: an operator who reads it on a secure install learns to ignore the warnings. The dev bypass itself was already correct — it keys on the resolved provider rather than on Supabase. 18 new tests, most of them about what the provider must REFUSE: a foreign signing key, a foreign issuer, a token for a different application, an expired token, a token with no subject, and a discovery outage that must not become permanent. Keys are generated per test and the JWKS is served locally, so they run offline. Verified: production refuses to start with neither provider, starts with OIDC alone, enforces 401 on an unauthenticated request, and warns only about the genuinely missing admin list. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
🐷 PIG — Prime Intellect Growth
An open-source, agent-native CRM for two-sided AI-compute companies.
Self-hostable. Auditable. Built for teams that buy compute on one side and sell it on the other.
Why this exists
A company that aggregates GPU capacity and resells it does not run one pipeline. It runs two, and its business is the spread between them.
Generic CRMs — Salesforce, HubSpot, Attio — model a single pipeline of deals against companies. They have no concept of inventory, no concept of a commitment you already bought and are paying for, and therefore no way to answer the question the business actually turns on:
Which contracted capacity is sold, to whom, at what margin — and what is idle right now?
PIG is built around that question. One table, allocations,
joins a capacity_commitment (what you bought from a provider) to a
demand_deal (what you sold to a customer). Revenue minus cost is margin per
GPU-hour. Committed capacity with no allocation is money burning. Everything
else in PIG is ordinary CRM plumbing that exists to keep that ledger honest.
Who it's for
PIG models three teams, because two-sided compute companies have three constituencies competing for the same scarce capacity:
| Team | Job to be done |
|---|---|
| Supply | Source, qualify, price, and contract GPU capacity from providers |
| Demand | Sell compute and post-training; renew and expand accounts |
| Research | Consume capacity internally — real burn, no revenue |
Research is a first-class tenant rather than an afterthought. Internal research burn competes with revenue for the same GPUs, and margin math that cannot see it is wrong.
The team set is configurable. PIG ships with these three because they match the structure of the company it was designed for, not because they are universal.
Agent-native, not agent-decorated
PIG is a first-class application for agents and for humans, and neither is a degraded view of the other.
- An MCP server (
apps/mcp) exposes the CRM over both stdio and Streamable HTTP. Any MCP client connects: Claude Code, Codex, prime-agent, or a Buzz workspace agent via its ACP bridge. Each team member points their own agent at PIG and works from the terminal. - Piggy, the in-app agent, drains a leased database queue rather than being called over HTTP — so work survives the agent being down, and every action it takes is recorded with an idempotency key.
- Every agent-derived fact carries evidence. Enrichment writes to a
factstable with a confidence score, a band (verified / probable / possible), a source URL, and a status. Strong signals apply automatically; weak ones become proposals a human approves. A CRM that lets an agent write unattributed claims into the record is a hallucination store, not a database.
The architectural rule
Intelligence never lives in the API.
The API does HTTP, auth, validation, and sync. All research, enrichment, scoring, and identity matching lives in the agent. They communicate through a table, never a direct call. This separation is borrowed from Comp AI CRM and it is the single most load-bearing decision in the codebase.
What makes it compute-native
-
inventory_listingsmirrors the Prime Intellect availability API field-for-field —gpuType,socket,interconnectType,stockStatus,security(secure vs community cloud),prices.onDemand,provisioningTime. Sync is a straight mapping, not an ETL project. -
capacity_commitmentsrecords what you bought: term, GPU-hours, cost per GPU-hour, floor and ceiling. -
contractsis polymorphic over party and type — MSA, DPA, SLA, order form, capacity commitment — because the supply side negotiates heavyweight paper while the self-serve demand side runs on a reliability tier and a credits policy instead of a signed uptime guarantee. -
Two real pipelines, with stages taken from how this market actually operates rather than invented:
Demand: qualification → legal → scoping → proposal → procurement → POC → deployment → expansion Supply: sourced → qualifying → technical diligence → financial diligence → pricing → contracting → onboarding → live → renewalNote that legal sits second in the demand pipeline. MSA and DPA execution gates the deal rather than closing it. Most CRMs put contracts at the end and are wrong about it for this market.
Stack
| Layer | Choice |
|---|---|
| Web | React + Vite + TypeScript, Tailwind, shadcn/ui, light + dark |
| API | Hono + tRPC on Node 22+ |
| Database | PostgreSQL 16, Drizzle ORM |
| Auth | Supabase (JWT verification only — PIG stores no passwords) |
| Agent | Piggy — a worker draining a leased task queue |
| MCP | @modelcontextprotocol/sdk — stdio + Streamable HTTP |
| Deploy | Docker Compose behind any reverse proxy |
Authorization comes from PIG's own users table, never from the mere existence
of an auth account. An identity provider that PIG shares with another
application must not grant access here.
Quick start
git clone <this-repo> pig && cd pig
npm install
cp .env.example .env # then edit it
npm run db:migrate
npm run db:seed # optional — public, sourced, confidence-graded
npm run dev:api # :8920
npm run dev:web # :5173
Connect an agent:
claude mcp add pig -- npx -y @pig/mcp # stdio
# or point any MCP client at https://<your-host>/mcp
Repository layout
apps/
web/ React + Vite front end
api/ Hono + tRPC API, Supabase JWT verification
mcp/ MCP server — stdio and Streamable HTTP
packages/
db/ Drizzle schema, migrations, seed
core/ Shared domain types and the ontology
prime/ Typed client for the Prime Intellect compute API
docs/ Ontology, deployment, seed-data provenance
deploy/ Compose files and reverse-proxy snippets
Documentation
- AGENTS.md — start here if you are joining this codebase. Architecture rules, the traps that have already bitten, conventions, and where to start.
- Build plan — what remains, in dependency order
- Ontology — the domain model, and why it is shaped this way
- Seed data provenance — every claim, graded and cited
- Agent integration — Claude Code, Codex, prime-agent, Buzz
- Deployment — self-hosting
A note on seed data
PIG ships with a roster of publicly documented people so the application is legible on first run. Every record carries a confidence grade and a source URL. No email addresses are included or inferred. Records that could not be independently sourced are marked as such rather than quietly presented as fact, and people who are demonstrably not staff — alumni, residency participants — are labelled accordingly. See docs/seed-data.md.
If you are seeded here and would rather not be, open an issue and it will be removed.