Core concepts

Organization

An organization is the tenant every other record in this platform belongs to: its members, integrations, control checks, evidence, audit ledger, and trust center configuration. A user can belong to more than one organization, each through its own membership record carrying a role of owner, admin, or member. Every query in the product scopes through an organization id, so one organization never reads another organization's data.

Integration

An integration is a stored, encrypted credential for one external provider (GitHub, AWS, Okta, Google Workspace, and 20 others), scoped to one organization. The credential is encrypted at rest with AES-256-GCM under its own key, decrypted only for the length of one check run, and used only to call that provider's own read-only API. A control check that needs no credential, such as tls-certificate-valid, has no integration at all. Its integrationId is null, which is a valid, expected state, not a missing setup step.

Framework

A framework is a named, versioned standard (ISO 27001, SOC 2, GDPR, DORA, NIS2, or the EU AI Act) and the fixed catalog of controls it defines. All 6 catalogs are static data checked into this platform's own code, not rows fetched from a database, because a standard's text does not change per customer. See Frameworks for the full catalog list and control counts.

Control

A control is one requirement inside a framework's catalog, identified by the code the standard itself uses (for example ISO 27001's A.8.24, GDPR's Art-32). Each control carries an automation mode: deterministic, where a real check can evidence it directly through an API; agentic-assisted, where the sandboxed browser fallback can gather evidence instead; or human-judgment, where no screenshot or API call substitutes for a person's own review. A control's satisfiedByControlIds field lists which of this platform's control-check templates, if any, can produce evidence for it. An empty list is honest and expected for most controls today, stated as a real gap rather than an invented mapping.

Control Check

A control check is a customer's own configured instance of a check: a controlId naming which check template to run (for example github-branch-protection-enabled), a target (a repository, domain, or org name), an optional integration, and an optional cron schedule for a recurring run. Its own frameworkControlIds field is the reverse of a control's satisfiedByControlIds: a tag list naming which framework controls this specific, configured check counts as evidence for. A framework's coverage percentage on the Frameworks page is computed by joining that tag list against the framework's own catalog at query time, never by copying framework content into this platform's database.

Evidence Record

An evidence record is the result of one run of one control check: a status of pass, fail, or needs-review, a timestamp, the raw response the check received, and a plain-language summary. An authentication failure against a provider's API is always recorded as needs-review, never fail, since a rejected credential proves nothing about the setting itself. A large screenshot or response body from the sandboxed browser fallback is stored separately as its own artifact row, in S3-compatible object storage under Object Lock in Compliance mode, and linked back to the evidence record it supports.

Audit Ledger

The audit ledger is a hash-chained, append-only log, one chain per organization, with no update or delete path in the application. Every entry stores a SHA-256 hash of its own payload, a hash of that payload combined with the previous entry's hash, and an HMAC-SHA256 signature over the combined hash, computed under a secret the database never stores. Writing an evidence record, deciding a pending approval, and changing a configuration each write one entry. See Architecture for the 5 actions that always write to this ledger through a person, never a model call, before they take effect.

Trust Center

A trust center is one organization's own public page, published at a URL it chooses, showing exactly the sections it opts into: framework coverage and control pass rate as percentages, a control-by-theme breakdown, certifications, sub-processors, data categories, and documents gated by an NDA or by approval. It reads the same evidence records and framework coverage computed above, aggregated to the percentage and title level a visitor sees, never a raw evidence record itself. See Trust center for what an owner configures and what a visitor can do.

How a control becomes a public claim

The 8 concepts above chain together in one direction, from a standard's text to a visitor's screen:

• A framework's catalog defines a control, such as ISO 27001's A.8.24, and labels it deterministic, agentic-assisted, or human-judgment.
• For a control marked deterministic or agentic-assisted, its satisfiedByControlIds names a real check template, such as github-branch-protection-enabled.
• An organization configures that template as its own control check, pointing it at a real target and, if the check needs one, a stored integration, and tags it with the framework control ids it should count as evidence for.
• Each run of that control check writes one evidence record: pass, fail, or needs-review, with the raw response behind it.
• The same run also writes one entry to the organization's audit ledger, chained to every entry before it.
• If the organization has published a trust center and opted into showing framework coverage, a visitor sees the resulting percentage, never the evidence record itself.