Developers

Build on structured bearing data.

A typed record contract, explicit identifiers and versioning, and a proposed HTTP API. Read everything now; access to real data is by request while the service is built.

Status

What you can use right now

Identifiers

Identity and versioning rules

Get identity right and everything else becomes tractable. These rules hold across files, API and UI.

ConceptRule
product_idOpaque and stable. Never derived from or parsed as a designation.
Exact identityManufacturer + full designation including meaningful variant suffixes.
Designation raw / normalizedRaw is preserved exactly; normalized exists only for comparison.
SlugsPresentation only. Brand renames and alias changes get redirects, never new identities.
schema_versionEvery record states the contract it conforms to. Breaking changes bump the version.
Data versionResponses will carry data version and timestamps so caches and snapshots are explainable.
RelationshipsTyped: same_identity_candidate, variant, candidate_substitute, supersession.

Access models

Lookup or snapshot?

Which one fits depends on how fresh your data must be and how much you query.

AI assistants

Assistant integrations

A ChatGPT / MCP integration is on the roadmap. It will only expose read-only lookup and schema tools once real data and a live API exist — no tool will be published around demo data.

  • Planned

    search_bearings / get_bearing_record

    Read-only lookup with evidence and applicability.

  • Planned

    get_bearing_schema

    Versioned family schema retrieval.

  • Planned

    resolve_bearing_identifiers

    Exact and candidate identities with rationale.

Building something on bearing data?
Tell us what you need.

Describe your use case and the calls you would make. Early requests shape which endpoints ship first.