Provider integrations
BuiltAdapters, mapping, jobs, replay, and review paths
Activation gateCustomer credentials, provider account, consent, and sandbox acceptance
Methodology
How our figures are calculated.
Haultro publishes two kinds of numbers: platform specifications, which describe measured product behavior, and modeled operational outcomes, which are representative targets rather than guaranteed results. This page states which is which, what sits behind each figure, and how to check them against your own operation.
Platform specifications
Verified characteristics and declared targets.
These figures are labeled by evidence type. Built counts come from the product repository; provider cadences and availability are targets that still require live operating evidence.
Provider-dependent
Location freshness
Cadence depends on the accepted provider, plan, scopes, connection health, device state, and network. The native web location path targets 30 seconds.
24/48/72 hour
Fill forecast horizon
The forecast windows the predictive fill model produces per container.
27+
Product modules
Count of shipped product modules, grouped into 11 capability areas.
150+
Internal platform endpoints
A conservative count of application endpoints used by Haultro workspaces and services. Customer API v1 currently exposes seven documented operations across six paths.
16
Registered AI agents
Executable department-agent, aggregator, and executive registrations in the runtime registry; not a 300-item catalog or a count of customer-visible workflows.
25 to 50,000+
Designed bin range
A product design envelope, not production capacity, a contracted limit, or an autoscaling/SLO result. Exact capacity is confirmed in writing.
99.9%
Availability target
An engineering target, not independently established uptime history, a contractual SLA, or a guarantee.
15-min
SLA check cycle
How often SLA rules are evaluated against live route state.
Activation ledger
What is built, and what still must be activated.
Source-complete does not mean a third-party account, physical device, legal position, or app-store listing is live. The remaining gates are shown here instead of being hidden inside sales language.
Customer API
BuiltSix v1 endpoints with scoped keys, rotation, rate limits, audit, and idempotent service-order writes
Activation gateAdditional platform endpoints are internal and are not customer API commitments
Traffic and truck restrictions
BuiltProvider-gated traffic matrices plus service-zone and prohibited-truck-type controls
Activation gateRoad-level low-bridge, turn, hazmat, and weight restrictions require a named mapping contract and are not currently automated
AI execution
Built16 registered agents, budgets, guardrails, audit, and clean disabled state
Activation gateApproved LLM provider configuration; no provider is currently configured in production
Native driver apps
BuiltExpo iOS/Android source, secure auth, field workflows, and offline replay
Activation gateApple/Google signing, physical-device QA, and accepted store listings
Certified scales
BuiltTicket import, reconciliation, costing, and billing
Activation gateNamed certified provider, contract, credential, payload, and sandbox
Compliance records
BuiltInternal evidence, retention, manifest, certificate, and export workflows
Activation gateAgency-specific configuration and counsel review; Haultro does not submit to regulators or certify compliance
Haultro hardware
BuiltSecure cloud ingest, device control, provisioning, and signed OTA foundation
Activation gatePhysical hardware, carrier, lab certification, firmware key pinning, and field acceptance
Production release
BuiltSource evidence is tied to an exact repository revision
Activation gateThe exact revision, migrations, runtime identity, providers, and rendered workflow must converge before the capability is labeled production-live
Modeled outcomes
Representative targets, and what sits behind them.
Wherever an outcome figure appears on this site, it is framed as "up to" or "representative." Here is what each one is based on. None of them is a guarantee; results depend on route density, fleet mix, and how your operation runs today.
Route savings calculator inputs
A modeled outcome from AI route-optimization scenarios. The model compares an operation's existing stop sequence against an optimized sequence across route density, disposal-stop placement, dead miles between yard and landfill, and idle time. "Up to" means the top of the modeled range at favorable route density; low-density rural routes see less.
Missed-pickup improvement
A modeled outcome combining predictive fill forecasting, SLA monitoring on a 15-minute cycle, and live route state. The model measures how many misses in a typical schedule are preventable when dispatch sees fill status and breach risk before the customer calls. Actual reduction depends on how many misses today are visibility problems versus capacity problems.
Faster cash collection
A workflow outcome, not a benchmarked percentage. When proof of service, disposal weight, and rental terms flow into invoicing automatically, the lag between completed work and issued invoice shrinks from days to the same day. We publish no specific days-sales-outstanding figure because it varies by customer terms.
Our commitment
Modeled figures get replaced by documented results.
Haultro's customer stories are currently representative operating scenarios, and they say so on the page. As customers agree to publish their results, documented case studies with named operators, baselines, measurement periods, and methodology will replace modeled figures. We do not publish a named customer result without the customer's sign-off, and we do not invent one to fill the gap.
Found a figure on this site that is not covered here or not labeled correctly? Tell us at contact@haultro.com and we will fix it.
FAQ
Methodology questions, answered.
Are Haultro's outcome figures from named customers?
Not yet. The calculator is an editable planning tool, not a published customer result. Route savings and missed-pickup improvements must be measured against an accepted customer baseline before they may be published as outcomes.
What is the difference between a specification and a modeled outcome?
A verified product characteristic is tied to source, tests, or rendered behavior. A target, such as 99.9% availability, is explicitly labeled and is not historical proof. Provider cadence is connection-dependent. A modeled outcome depends on route density, fleet mix, and current operations.
How can I validate these figures against my own operation?
Two ways. The ROI calculator models savings from your own truck count, route density, and fuel spend. A live demo runs the routing and fill models against your actual routes and containers, so you see your numbers rather than representative ones.
Get started
See your numbers, not ours.
Book a demo and we will run the routing and fill models against your actual routes.