Documentation

Everything required to evaluate and deploy NADIR.

Data requirements, runtime choices, correction readiness, evidence contracts, security boundaries, deployment checklists, and validation responsibilities in one implementation guide.

RequirementsResponsibilitiesAcceptance criteria
NADIR developer architecture
NADIR architectureProduct / documented source
StartBatch sampleNo vehicle changes required
ProductionOwned contractsData, runtime, workflow, evidence
CorrectionOpt-inSupported integrations only
CloseoutDocumentedDecision, gaps, and artifacts
01 / INTERACTIVE DIAGRAM

Integration topology

Telematics and RO feeds into Pulse scoring outputs.

NADIR VISUAL · SEED DATAILLUSTRATIVE · NOT FIELD PERFORMANCE
Nominal Caution Critical

Illustrative seed-data visualization. Validate on your representative fleet sample before operational decisions.

02 / DETAILS

Two ways to read this page

Plain language for fleet and investor conversations. Technical detail for engineering diligence.

Plain-language summary

NADIR helps fleets detect likely ADAS miscalibration after repair using data you already export.

Shadow mode means advisory tiers and signed records — not automatic vehicle changes.

  • Start with a four-week $750 proof pilot.
  • Success = MTTFF-RE within seven days on most repair events.
  • Expand only after a written pass/fail readout.
03 / READING ORDER

Documentation map.

Start with pilot runbooks, deepen into API field reference as needed.

Buyers: /how-it-works, /pilots/start, /pilots/kpi. Engineers: /api, /developers, /deep-dive.

All documents share the same boundary: shadow advisory, no ECU writes, MTTFF-RE for pilots.

  • RunbooksOnboarding + KPI
  • ContractsAPI + schema
  • ResearchControlled benchmarks
04 / RUNBOOK

Week 0–4 onboarding runbook

Roles, meetings, and artifacts each week.

Confirm cohort VIN list, RO feed owner, telematics export owner, legal shadow language.

Deliver adapter manifest draft and sample batch template.

Attendees
Maint · IT · Legal optional
Output
Data contract v1
05 / API REFERENCE

REST API behavior and error contracts

What integrators should expect in diligence.

Telemetry batch ingest, health scoring queries, repair events, evidence compile/verify/export.

Bearer token scoped per tenant; API keys rotatable without redeploying edge gateways.

Base
https://api.nadirai.net/v1
Auth
Bearer + tenant key
Format
JSON
06 / DATA CONTRACTS

Repair order ingestion

The RO close timestamp anchors post-repair scoring. Without it, MTTFF-RE is undefined.

VIN (17 char), RO identifier, close timestamp (UTC preferred), procedure category, and shop identifier.

Optional but valuable: part numbers for glass, ADAS kit replacement flag, technician notes.

NADIR validates identity before joining — malformed VINs land in a quarantine report, not silent scoring.

Required
vin · ro_id · closed_at · procedure
Format
CSV · JSON · webhook
Cadence
Daily batch minimum
07 / INTEGRATION

Telematics ingest and schema validation

Signals you already export — validated before scoring.

VIN, UTC timestamp, speed, yaw rate, steering angle, forward radar lead distance if available, lane offset proxy if available.

Geotab, Samsara, Motive, and OEM exports differ — NADIR maps through adapter manifests.

Missing optional fields reduce confidence; missing required fields reject the batch row.

Required
vin · ts · speed
Ideal
+ yaw · radar · lane
Mode
Batch first
08 / PILOT KPI

MTTFF-RE — the one pilot metric

Mean Time To First Flag after Repair Event. One number for pass, fail, or stop.

When a vehicle leaves a glass or body shop, start a clock at repair order close.

MTTFF-RE measures hours until NADIR assigns CAUTION or CRITICAL in the post-repair observation window.

If most events flag within seven days, your maintenance team gets actionable lead time before silent misalignment becomes a safety conversation.

  • Median MTTFF-RE ≤ 168 hours is the default pilot target.
  • Pass rate ≥ 70% of in-cohort events is the companion statistic.
  • Events without telemetry are excluded — never counted as passes.
09 / EVIDENCE

Evidence bundles and verification

Tamper-evident records for QA, insurers, and safety boards.

Source frame hashes, ingest adapter version, model and policy IDs, tier transition, repair_event_id, operator ack metadata.

Canonical JSON serialization before HMAC-SHA256 signature.

Verification recomputes digest — integrity check, not ground-truth calibration proof.

10 / REFERENCE TABLE

Reference matrix — documentation

Dense field reference for engineering diligence on this topic.

CategoryField / controlValueNotes
Pilotmodeshadow_advisoryNo ECU writes
PilotkpiMTTFF-REMedian ≤168h target
Pilotcohort50–150 VINsShadow Proof SKU
IngesttelemetryPOST /v1/telemetry/batchCSV/JSONL
IngestrepairPOST /v1/repair-eventsRO anchor
ScoretierNOMINAL|CAUTION|CRITICALPolicy-bound
Scoremodelpulse_residual_*Versioned
ProductqueueConsole CRITICAL rowsOperator-facing
ProductdigestWeekly CSV/emailCAUTION summary
EvidencesignatureHMAC-SHA256Integrity only
EvidenceverifyPOST /v1/evidence/verifyRecompute digest
SecuritytransitTLS 1.2+API only
SecurityauthBearer + API keyTenant scoped
BoundaryasilNot claimedAdvisory analytics
BoundaryactuationNoneShadow default
Commercialproof$750 flat4 weeks
Commercialops$750/moAfter pass
Commercialregional$15k+150–500 VINs
11 / GLOSSARY

Shared vocabulary

Terms used across NADIR pilots, API docs, and readouts.

MTTFF-RE

Mean Time To First Flag after Repair Event — hours from RO close to first CAUTION+ tier.

RO closed Monday 6pm, first CAUTION Wednesday 2pm → MTTFF-RE = 44 hours.

Shadow mode

Advisory scoring and evidence export without ECU writes or automated dispatch.

Console shows CRITICAL; maintenance decides whether to pull the unit.

EVB

Evidence Vehicle Bundle — canonical signed JSON record of tier transition lineage.

Includes model_id, policy_id, frame hashes, repair_event_id.

Pulse tier

Low-latency residual scoring tier used in public shadow pilots.

Batch scoring within minutes of telematics upload.

Cross-modal residual

Disagreement metric between sensor modalities (e.g., camera lane vs radar range-rate).

Persistent elevation after glass repair triggers CAUTION.

RO close

Timestamp when repair order is marked complete — starts post-repair observation window.

Must be UTC with timezone documented in data contract.

Policy ID

Version identifier for tier threshold rules separate from model weights.

policy_post_repair_glass_v3.2

Quarantine batch

Ingest batch rejected for schema errors — not silently partially scored.

Clock regression rows excluded with explicit error report.

Exhibit A

Week-four pilot chart plotting MTTFF-RE per repair event.

Median line vs 168h threshold.

Coverage exclusion

Repair event omitted from KPI due to missing telematics — not counted as pass.

Listed in readout appendix with reason no_telemetry.

Reason codes

Machine-readable tags explaining why tier was assigned.

CAMERA_RADAR_DIVERGENCE, POST_REPAIR_PERSISTENCE.

Adapter manifest

Versioned field mapping from fleet telematics export to NADIR schema.

geotab_pulse_v1.4.json
12 / DETAILS

Common questions

Straight answers for buyers and reviewers.

Common questions

Straight answers for buyers and reviewers.

14 / RESPONSIBILITY MODEL

A deployment is a chain of explicit contracts.

NADIR separates what the customer supplies, what the platform computes, what correction can change, and what a human or qualified service process owns.

NADIR / LAYERSSENSOR
RELIABILITY
SYSTEM
COMPOSABLE · VERSIONED · TRACEABLE
01
CUSTOMER + NADIR

Source contract

Vehicle, sensor, time, frame, units, quality, and context.

02
NADIR

Inference contract

Model version, tier, residual, confidence, and severity.

03
SHARED APPROVAL

Correction contract

Eligibility, transform, envelope, fallback, and re-score.

04
OPERATOR

Workflow contract

Acknowledgement, dispatch, physical service, and closure.

05
GOVERNANCE

Evidence contract

Retention, signature, access, export, and verification.

15 / INTEGRATION LEVELS

Choose an integration depth deliberately.

A valid evaluation can begin with a batch export; real-time correction requires a substantially stronger runtime and validation contract.

CAPABILITY
Minimum evaluationOperational monitoringCorrection-enabled
Data
Representative CSV / JSONLScheduled batch or streamLow-latency sensor path
Identity
Vehicle + sensor IDsStable fleet manifestExact hardware + model binding
Time
Ordered timestampsClock-quality reviewBounded synchronization
Runtime
Cloud replayCloud / edge monitorValidated edge / API path
Fallback
Not applicableEscalation workflowExplicit original-stream behavior
Acceptance
Schema + signal fitQueue + evidence qualityTransform + re-score validation
Read edge installation →
16 / DEPLOYMENT CHECKLIST

Use one checklist from first sample to closeout.

The deployment should end with a technical and commercial decision, including documented gaps.

01
01

Scope

Name the business question, owner, vehicles, sensors, and operating mode.

02
02

Sample

Validate units, timestamps, identity, quality, and representative conditions.

03
03

Baseline

Run monitor-only scoring and review expected versus observed behavior.

04
04

Integrate

Connect workflow, correction policy if applicable, and evidence export.

05
05

Accept

Review metrics, incidents, limitations, security, and operational ownership.

06
06

Close

Produce go / revise / stop decision with signed artifacts.

Request an implementation review →

Plan a deployment with explicit requirements.

Bring a representative sample and the team will map the shortest valid integration path.