We only describe what the platform actually does today. The cards below map directly to primitives in the run, scoring, auth, and metering pipeline. Anything we have not built or verified, we list under what we do not claim — and we do not pretend otherwise.
Provenance discipline: claims here track real architecture, not marketing copy.
Each item below maps to a concrete part of the system: tenant scoping in the data layer, authentication in the API surface, hashing for API keys, idempotency for run creation, env-loaded secrets, and adapter-mediated external calls.
Every project, query, run, result, and ledger entry is scoped to the customer tenant. Cross-tenant data access is not part of how the platform queries the database.
Customer authentication uses Supabase JWT for the dashboard. Enterprise customers can also authenticate programmatic access through API keys.
API keys are stored as hashes, not in plaintext. The original key value is only available at issuance time.
Run creation supports idempotency keys so a retried request does not produce duplicate runs or duplicate ledger debits.
Secrets and provider credentials are loaded through validated environment config. They are never committed to the repository.
All external AI engine and SERP provider calls go through the adapter interfaces. That gives one consistent surface for cost capture, metering, and observability.
These are the security and compliance categories that customers often expect from enterprise SaaS. We will not list any of them as a platform claim unless they are actually implemented, audited, and documented. If you need any of these to evaluate a rollout, tell us during the enterprise conversation and we will be honest about the current state.
None of the items above will be claimed by the platform unless they are actually implemented and documented. We treat this list as part of our provenance discipline: we describe what exists, we mark what does not yet exist, and we do not bend the truth in the middle.
This page exists to describe the security primitives the platform actually has today, not to imitate the compliance grid customers see on mature enterprise vendors. As the platform evolves, items will move from the “not claimed” list into the “what we can safely claim” list — and only after the underlying work is real.
Tell us what your team needs in order to evaluate the platform. We will only describe what exists today — and we will be explicit about what does not.