Skip to main content
development environment — data here is not real and actions have no financial effect
Request a demo
Resources

Compliance library

How eligibility is expressed as reviewable data, why every default denies, and the questions this platform deliberately refuses to answer on your behalf.

The three defaults, and why they all deny

  1. An absent fact never satisfies a ruleNot knowing whether a verification is valid is not the same as knowing that it is, and neither is permissive. An integration that stops populating a field closes the gate rather than opening it.
  2. A policy that matches nothing deniesEligibility comes from a rule saying so, never from no rule objecting. A workspace with no published policy onboards nobody, and says exactly that.
  3. The first matching rule decidesIn sequence order. A later allow cannot undo an earlier reject, so a policy can be read top to bottom and understood.

Why the attribute vocabulary is closed

A rule engine that can read any field is one nobody can bound.

  • “What could this policy possibly depend on?” has to have a short answer — roughly 25 declared attributes, each with a type.
  • Adding an attribute is a reviewed code change, because each addition widens what a policy may discriminate on. That is a regulatory decision rather than a configuration one.
  • A condition comparing a country code to a number fails at authoring, with the path to the offending node, rather than never matching in production.
  • Nothing is ever evaluated as code, so a policy can be reviewed by reading it, diffed between versions, and replayed against a historical subject.

What we will not decide for you

No jurisdiction pack ships, deliberately

A plausible-looking built-in pack would be read as legal advice, and an unreviewed pack cannot back a published policy. Jurisdictional rules are authored by people accountable for them.

Similarly, nothing can approve a verification on its own. With no provider adapter registered, the only path to an approved verification is a named officer recording the evidence they reviewed — enforced in the schema, the service and the compliance package rather than by policy alone.

What is recorded, and for how long

  • Every decision is snapshotted with the policy version that produced it, so “why was this allowed” is answerable under the rules that governed it.
  • Personal data used for identity is encrypted at the field level; the flags rules actually need — country, classification, screening status — are kept in the clear so the engine never decrypts at scale.
  • The audit trail is hash-chained and append-only at the database, so an altered history fails rather than merely being detectable.
  • Segregation of duties is checked continuously: holding both an originating and an approving role is surfaced on the team page rather than discovered during an examination.