How it works

Geometry → sources → checks → verdict.

Every call follows the same flow:

your geometry  ─┐
                ├─→  match against reference sources
your ruleset   ─┘    (protected areas, sanctions, registers, ...)
                          │
                          ▼
                    run checks (count, area, distance, subject match, ...)
                          │
                          ▼
                    compose a verdict

The four primitives

Sets

A set is a collection of features (polygons, points, lines, or subject records). Sets are either anchored on a source — e.g. “all features in br:funai:indigenous-territories that intersect my input geometry” — or built from set operations (union, intersection, difference) over other sets.

Projections

A projection computes a value from a set: count, total_area_m2, min_distance_m, an aggregate over a feature property, or a merge of geometries. Projections produce numbers and geometries — they do not contribute to the verdict on their own.

Checks

A check verifies something about a set or a projection and produces a boolean outcome with a severity. Two flavors:

• exists — is the set non-empty?
• threshold — does a projection’s value pass an op + value comparison? (e.g. count >= 1, total_area_m2 > 50000)

Verdict

The verdict combines check outcomes by severity. A response carries two enums on purpose:

• status — ok or degraded. Execution health.
• outcome — compliant, warning, non_compliant, or degraded. Compliance result.

See Verdicts for the full semantics.

Three styles of usage

Style	Endpoint	When to use
Raw discovery	/v1/intersections, /v1/distance	Exploration, debugging, ad-hoc queries
Subject lookup	/v1/subjects	Sanctions / blacklist / registry checks by ID
Full compliance	/v1/evaluate	Production decisions against a ruleset

Most customers start with discovery, then move to /v1/evaluate once their compliance policy stabilizes.