Draft v0.1 — open for public comment. Endpoint examples are illustrative. The verification program and index are in preview.
Open specification · Draft v0.1

Vertical extensions

One core, many extensions. Industry-specific fields belong in independently versioned modules.

The mechanism

Industry-specific data belongs in namespaced objects under extensions. Each extension defines its name and full semantic version, field schema, capability nodes, required checks, and any stricter freshness rules.

Illustrative example:

{
  "extensions": {
    "legal": {"extension_version": "0.1.0", "bar_numbers": ["00799999"], "jurisdictions": ["TX"]},
    "home": {"extension_version": "0.1.0", "license_number": "EXAMPLE123", "insured": true}
  }
}

An insured field is an operator claim. An independently performed insurance check belongs in the verification evidence.

Lifecycle

StageGate
ProposedWritten specification available for comment.
Reference implementationAt least one endpoint implements the proposed contract end-to-end.
ConformantImplementation passes the applicable public test suite.
OfficialPublisher designates the extension Official on evidence of the test results.

Unofficial experimental extensions use the x- prefix and must not claim Official conformance. No extension is designated Official by this preview.

Fifteen extensions in four proposed waves

WaveExtensionsFocus
1 — Initial referenceslegal, home, beautyAttorney status, home-service credentials, appointment services. Draft planning.
2 — Credential-heavy professionsmedical, financial, realestate, insuranceProfessional qualifications, jurisdictions, affiliation, and authorization. Proposed.
3 — Frequent bookingsauto, pet, dining, hospitality, eventsRepair, grooming, reservations, lodging, rentals, and staffing. Proposed.
4 — Care and knowledgechildcare, seniorcare, educationBackground checks, credentials, and domain-specific freshness. Proposed.

Plumbing, electrical, and HVAC start as nodes under home.systems.*; they warrant separate modules only if their data requirements diverge materially. No reference implementation is claimed live based on this roadmap.

Propose an extension

Use a lightweight RFC: name, problem, capability paths, field schema, required checks, freshness policy, compatibility implications, and one operator willing to implement it. Keep vertical-specific fields out of the core. The reference implementation should do the filtering, not an elaborate submission process.

Start a proposal.