Infrastructure

Four layers, one system of record

The architecture exists to make one promise credible: that a published score can be traced to its inputs, its factor set and its version, months after it was written.

Edge render layer

The site is server-rendered at the edge. Public catalogue reads are executed server-side with a publishable key, so no privileged credential reaches the browser.

Server-side rendering
Server functions as typed RPC
Static asset delivery from CDN

Application layer

Scoring, lead capture and account reads run as server functions. Authenticated calls carry a bearer token and execute under the caller's own database identity.

Deterministic scoring function
Zod-validated inputs at every boundary
No service-role credential in ordinary reads

Data layer

Managed Postgres holds products, scores, factor tables, orders and the credits ledger. Row-level security is enabled on every user-owned table.

Row-level security on all user data
Immutable score records
Frozen factor sets per methodology version

Identity layer

Authentication is managed, with roles held in a dedicated table rather than on the user profile — so a compromised profile row cannot escalate privileges.

Email and social sign-in
Roles in a separate table
Security-definer role checks

Data flow for a single score

partner submission
      │
      ▼
 extraction (advisory)  ──►  human confirmation
      │
      ▼
 scoring function  ◄──  frozen factor set (v1.2)
      │
      ▼
 immutable score record  ──►  product page · API · aggregates

A re-score never edits an existing record. It appends a new one carrying its own methodology version, which is why the version history can be reconciled against any score we have ever published.

Security posture

Our handling commitments and the controls behind them are stated on the trust and security page.