Platform
The trust infrastructure most tools skip.
Applying data and AI to people is only acceptable if it can be made transparent — that's the hill we die on. Underneath the analytics sits the machinery that makes the promise real: governed AI access, relationship-based security, adaptive loops that check their own work, and data integrity you don't have to trust on faith. Most of it ships invisibly. Here it is, named.
Why this page exists
Transparency isn't a feature. It's the machinery.
People give discretionary effort when they can see how decisions about them were reached — , not just a fair outcome. A tool that leans on data and AI in ways that can't be made transparent structurally can't satisfy that. So we build so it can.
That commitment isn't a slogan bolted on at the end — it's load-bearing infrastructure. Governed access, explainable adaptation, and honest data integrity are what let "transparent by construction" be true rather than aspirational.
None of it shows up on a chart, so most of it goes unnoticed. The four pillars below are what changed under the hood — each one shipped, in production, and published to a live capability feed that downstream sites read automatically.
Pillar 1 — AI governance
We govern the agents that use our tools.
Every analytical service is reachable by AI agents over the — which is the point, and also the risk. An agent that can call a tool can call it a thousand times, or call the one that mutates data. So the gateway that lets agents in is also where we govern them: built in, not bought as a separate console.
- Scoped keys
- Each consumer gets a key mapped to a set of scopes — an agent sees only the tools it was granted, never the whole surface.
- Enforced rate limits
- A per-consumer token bucket throttles abuse and runaway loops before they touch the database — a real limiter in the request path, with a kill switch and per-consumer tuning.
- Sensitive-op confirmation
- A mutating tool (accept a correction, overwrite a mapping) is rejected unless the call carries an explicit
confirm: true— an agent can't change state by accident, and the refusal is audited. - Full audit trail
- Every tool call writes one attributable audit row — who, which tool, when — so agent activity is legible after the fact, not a black box.
The category the market calls "agent governance" (Barndoor-, Aegis-class) — we evaluated buying it and built the primitive set in-house instead, at the one chokepoint every agent already passes through.
Pillar 2 — Security & access
Access that follows relationships, with the database as the backstop.
"Who can see this?" is rarely a static role. It's a relationship — you own it, you shared it with a teammate, your team inherited it. So access is modeled as , evaluated in production by , with underneath as the last-line guarantee. Two independent layers — defense in depth.
- Fine-grained sharing
- owner → editor → viewer, plus team memberships and per-object sharing — the shapes RBAC models badly, evaluated consistently (no stale allow after a revoke).
- Never drifts
- A share change and its authorization tuple are written together through the outbox, so the app database and the authorization engine can't disagree.
- Tenant isolation in the database
- Even if application logic erred, row-level security refuses to return another tenant's rows. Fine-grained sharing sits above it; the floor never moves.
- Engine-agnostic
- The authorization adapter is swappable — managed today, self-hosted tomorrow is an environment change, not a rewrite.
Verified against the live authorization engine with a differential test — the in-house reference and the production engine must agree, 7 / 7.
Pillar 3 — Adaptive intelligence
Every adaptive loop learns whether it patterned right.
Adaptive systems are easy to build and easy to fool yourself with — they feel smart without anyone checking. The closes that gap: the moment a policy makes a choice, we log what it predicted; when the outcome lands, we join the two and score predicted-versus-realized. "Measure engagement" becomes "learn if we were right."
- The prediction half, kept
- Inputs, policy version, and the candidates the policy chose among are recorded at decision time — the half most systems throw away.
- Joined to the outcome
- A stable decision id ties the prediction to the real signal (a rating, a correction, an action) so calibration is measurable per policy version.
- Already learning
- Job matching updates its signal weights from human review; adaptive psychometrics, the exec feed, and the compensation decision deck feed the same ledger.
- Explainable by design
- Because the inputs are logged, an adaptive choice can be explained after the fact — the opposite of a black box.
One pattern across four surfaces, adopted cross-repo (Performix, vela, the DevPlane optimizer) — so learning compounds instead of being re-invented per feature.
Pillar 4 — Reliability & data integrity
Nothing important is written and quietly lost.
The unglamorous failure mode of every analytics platform: a secondary write — a benchmark contribution, a downstream update — fires, misses, and no one notices until the numbers are wrong. The ends that. The secondary write commits in the same transaction as the primary, then a drainer delivers it with retries. Either both land, or neither does.
- At-least-once delivery
- Enqueue in the caller's transaction; a background drainer claims work with
FOR UPDATE SKIP LOCKED, retries with backoff, and dead-letters what won't deliver. - Idempotent
- Redelivery is safe — a duplicate contribution or authorization write is a no-op, not a double count (a live test caught the one engine quirk that would have broken this).
- Guards the moat
- The cross-client benchmark data that sharpens our priors over time flows through the outbox — a transient blip can't silently under-collect it.
- Crash-recoverable
- A lock TTL returns work stranded by a crashed worker — delivery resumes instead of stalling.
One primitive, three consumers already (benchmark flywheel, authorization sync, consumer feeds) — reliability as shared plumbing, not per-feature heroics.
Not a claim — a surface
See it yourself.
Transparent-by-construction means the platform is legible from the outside, too. These are open, live, and machine-readable.
/api/capabilities
The capability feed
Every capability, with realization evidence — what functions, why it's valuable, how it's integrated.
/console
The dev console
Exercise the live services + MCP tools directly — the technical evaluation cockpit.
/api/health
Live health
Every service reports status in the open — no status-page theater.
The moat a black box can't copy.
Any vendor can add a feature. The one thing a black-box incumbent can't retrofit is being transparent by construction — and this is the infrastructure that earns it.