dVeracity

Get one sector in full (free): its classification, status, reference artifacts and nested industries. Use ofp_sectors first to find the sector id.

List industry sectors and their reference implementations (free). Each carries a status: "implemented" means a reference implementation exists, while "planned" or "placeholder" mean the sector is named in the taxonomy but nothing is published for it. Check the status before assuming a sector has content.

Show which canonical fields carry one O-DEF semantic code (free). This is the reverse lookup a connector needs: given a field in a source system, find where in the Open Footprint model it belongs. Codes carried by more than ten fields are returned with an explicit caution — they are generic classifications, and aligning to one asserts far less than it appears to.

List the O-DEF semantic codes carried by the canonical model (free). Use this when mapping fields from another system — SAP, an ERP, a supplier feed — onto Open Footprint: a code is the shared address two systems can align on. Every code comes with fieldCount, the number of canonical fields sharing it. A high count means a generic fallback that asserts almost nothing, so pass maxFieldCount (10 is a good start) to get only codes specific enough to be a real alignment target.

Check a data payload against the canonical Open Footprint model and, when a sector is named, that sector's published Rego guardrails. Costs API credits per call. WHAT IT CHECKS: structure (required fields, primary key, declared types); the constraints the model declares (identifier patterns, enums, date formats, lengths); value ranges where the model declares a bound (a quantity outside the declared minimum or maximum is rejected; one field in the model declares a bound today, so this check runs only there — read `checked` rather than assuming it ran); temporal consistency (a validity period whose end precedes its start is rejected); enum membership (a foreign key into a vocabulary that publishes its members is checked against that member set, so a well-formed identifier for a referent that does not exist is caught); and, with a sector, the guardrails. WHAT IT DOES NOT CHECK in this release: value ranges on fields whose model declares no bound (an out-of-range quantity passes, reported per call as no_range_declared or no_numeric_fields), unit coherence, referential integrity (foreign keys are pattern-checked and, where a vocabulary publishes one, member-checked, but never resolved against live records), factor provenance, or materiality. The response says so per call: `checked` lists the checks that ran and `checks_not_run` lists every catalogued check that did not, each with a reason (not_implemented, no_data_plane, no_range_declared, no_numeric_fields, no_validity_pair, no_members_published, no_reference_field_supplied, schema_not_run, no_sector_supplied, no_policy_published, not_applicable, unevaluable). `schemaValid` is the structural verdict; `assuranceLevel` (schema-only | schema-and-value | schema-value-and-policy | full) is the depth earned. `valid` is deprecated (kept through 0.5.x, removed no earlier than 0.6.0) — it only ever covered the checks that ran. Every violation and warning carries severity (error | warning). Unknown fields are warnings, never violations, and each carries `didYouMean` candidates when the model has a plausible match; `schema.normalisations` discloses keys that resolved only through case and separator folding. `advisories` carries findings that are true of the payload but do not bear on its validity: today `deprecated_field`, severity warning, naming a `successor` when the model names one — an advisory never changes `schemaValid`. Guardrails report four distinct outcomes, never conflated: passed, denied, not_applicable (the rules do not cover this record type), or unevaluable (the payload lacks the e-ledger inputs the rules read, e.g. co2e_kg — listed in policy.missingInputs). Never report a payload as compliant unless sector_policy is in `checked` and policy.outcome is passed.

Ask a natural-language question about verified emissions data (Open Footprint / PPDM / OGMP-methane knowledge graphs). Costs API credits per call; a payment-required error means the human operator must top up credits. Prefer specific questions (a site, a company, a time range) over broad ones.

List the query templates the semantic layer supports (free). Useful to learn what kinds of questions the knowledge graph can answer before spending credits on semantic_query.

Validate a data payload against a supported sustainability standard (Validation-as-a-Service). Costs API credits per call. Use list_standards first to see supported standards and versions.