That is the bet the whole document makes: each vehicle trains on its own routes and shares only a low-rank adapter delta, so the fleet gets better at a city nobody ever uploaded. It is a bet, not a result. There is no GeoFleetic — no process, no server, no vehicle, not one line of Elixir. What exists is a specification, three capability contracts, and this page, which recounts the document from the file every time it is built and refuses to publish if the two disagree.
A [&] capability contract names operations with typed inputs and outputs, and says which primitives may feed it and which it may feed. The three below are declared twice — once as tables in §8 of the specification and once as JSON beside this page — and two hand-maintained copies of one list drift. So this build compares them, in both directions, and refuses to emit anything if they differ.
Spatial fleet-state contract for regional asset lookup, route-aware enrichment, and capacity snapshots.
Geofence-aware spatial contract for boundary membership checks, enter/exit event detection, and compliance-oriented context enrichment.
Route intelligence contract for path generation, optimization, and explainable navigation decisions under spatial and operational constraints.
The specification also declares a PULSE loop, geofleetic.spatial_intelligence, whose 5 phases — retrieve_twin, route_inference, act_dispatch, learn_outcome, consolidate_twin — cover every one of the five canonical PULSE kinds. It is prose in a Markdown table. There is no geofleetic.spatial_intelligence.pulse.json in PULSE/manifests/ — looked for during this build and not found — so nothing can be validated against pulse-loop-manifest.v0.1.json, and the loop cannot be discovered by a tool that reads manifests rather than English.
§14 puts a Pre-Phase in front of the roadmap, and its argument is sound: the delta-CRDT convergence, the federated aggregation and the graph network are the assumptions everything else rests on, and they are cheap to falsify before a 34-week plan is committed to. The Pre-Phase has not started. Its own introductory sentence says three highest-risk assumptions and then lists four, which is the kind of thing that survives in a document nobody has had to execute.
The spec's own first feasibility validation: prototype a minimal position/heading/speed delta-CRDT, drive a hundred concurrent twin updates through delayed and reordered messages, and check that state converges within five seconds of the partition healing with no lost updates. Everything else in the document assumes this holds.
Train a LoRA adapter on synthetic routes with Nx and ONNX only, then check that extracting, compressing and aggregating the deltas produces a merged adapter within five percent of a centrally-trained baseline. The privacy argument this whole product rests on is worth nothing if the merged model is worse than useless.
Whether Nx can express a graph network for route scoring at all, and at what latency on a fifty-node road graph. The spec carries its own escape hatch — a Python sidecar — and marks the outcome as a decision gate that would rewrite the technology stack and the supervision tree.
No mix project, no supervision tree, no MCP server, no PostGIS migration, no Tile38 client. The eight MCP tools named in §9.2 do not exist as code anywhere; the eight names are the whole of them.
A capability contract is only worth something when two parties written by different people agree on it. One unimplemented contract cannot demonstrate that; it can only fail to be contradicted.
There is no software here to measure, so the only honest evidence is about the document itself: how large it is, how much of it is unticked, and whether the parts that are stated twice agree. A number cannot be hand-written onto this site — the build recomputes each one from the file and the publication gate refuses the artifact when a value on the page and a value in the record disagree.
| What was counted | Result | How, and what it does not mean | |
|---|---|---|---|
| Specification, as a file | 987 lines | 54209 bytes of Markdown, last dated 25 March 2026 inside the document itself | |
| Numbered headings | 50 headings | 17 sections at the top level. Fenced code blocks are stripped before headings are read, or an Elixir comment becomes a section | |
| Section numbers used twice | 1 collisions | §10.1 — the integration subsection and the PULSE manifest were both given that number, so a citation of it is ambiguous | |
| Task boxes in the roadmap | 54 unticked | 0 ticked. This is the roadmap of a project that has not begun, counted rather than characterised | |
| Feasibility validations | 4 declared | FV-1, FV-2, FV-3, FV-4 — introduced by a sentence that says "three" | |
| Acceptance test criteria | 13 criteria | Each a Given-then sentence with a latency or a bound. None has ever been run, because there is nothing to run it against | |
| Roadmap stages | 7 stages | Pre-Phase, Phase 0, Phase 1, Phase 2, Phase 3, Phase 4, Phase 5 — 34 weeks of them, starting from a Pre-Phase that has not started | |
| MCP tools named | 0 tools | . Names in a table, not functions in a module | |
| Capability contracts | 3 contracts | 10 operations, matched in both directions against the tables in §8; 3 of them also proven byte-identical to the upstream copies during this build | |
| PULSE loop phases | 5 phases | retrieve_twin, route_inference, act_dispatch, learn_outcome, consolidate_twin — every one of the five canonical PULSE kinds, declared as prose in a Markdown table | |
| RFC keywords in the document | 0 keywords | No MUST, no SHOULD, no MAY. This is a design document, not a conformance specification, and nothing in it can be conformed to yet | |
| Implementation, in lines | 0 lines | No .ex or .exs file exists in this repository outside old_scrap/, recounted on every build | |
| The v0.1 draft specification | spec | docs/spec/README.md | The file, re-read and recounted by this build. Every § number cited on this page was resolved against its real headings, with fenced code blocks stripped first. |
| Three &space capability contracts | spec | records/contracts/ | Byte-identical copies of AmpersandBoxDesign/contracts/v0.1.0/, compared by SHA-256 during this build. Every operation they name was matched against the tables in §8 of the spec. |
| The PULSE loop manifest | spec | docs/spec/ §10.1 | Extracted from the spec by this build. It is prose in a Markdown table: no geofleetic.spatial_intelligence.pulse.json exists in PULSE/manifests/, so nothing can validate it against the PULSE v0.1 schema. |
Each row was produced by reading docs/spec/README.md during this build, with fenced code blocks stripped first so that Markdown inside an Elixir example cannot be counted as prose. Operation names were taken from the tables in §8 and compared against records/contracts/*.contract.json in both directions — an operation in one and not the other refuses the build, which is the only reason two hand-maintained copies of a list can be trusted to agree. The frozen copy of every figure lives in records/spec-facts.json; the build re-derives them all and exits non-zero on any disagreement, so a number on this page cannot be edited into existence.
Until this revision the page said Every GeoFleetic endpoint is an MCP server. There are no GeoFleetic endpoints. It offered a button reading Discover on FleetPrompt, pointing at a marketplace that has never had a GeoFleetic anything in it. Its subtitle promised vehicles that learn routes, predict demand, and optimize logistics over time, in the present tense, beside four application cards describing last-mile delivery, field service, autonomous fleets and supply chains as things this software does.
None of it existed, and none of it exists now. The specification is real and worth reading; the product it describes has not been started. The page was not wrong about the ambition, it was wrong about the tense, and a reader could not tell the difference from the page.
The fix is structural rather than careful. Those three strings are now in the publication gate's blocklist and the gate counts their occurrences: they may appear in this paragraph and nowhere else on the page, so reinstating one refuses the build. The claims come back when the code comes back, and not before.
This surface is at the spec rung, and the rung decides the verbs: read it, argue with it, or build it. There is no “try it” because there is nothing to try, and a page that cannot honour its own call to action is worse than a page with none — the visitor finds out after spending the effort.
A specification with no implementation has exactly one way to get better, and this is it. A contradiction between two sections, an operation that cannot be typed the way §8 types it, a convergence claim that does not hold, a latency target that is not reachable on the BEAM — all of it is useful, and the more specific the better. The form below posts to formspree.io when you press the button, carrying what you typed and nothing else. If you would rather argue somewhere public, the issue tracker is the same channel with an audience.