Server-side integration
Postcode credentials and verification controls remain on the server. The browser never receives a privileged service key.
Technical documentation
How ResolveGrid is designed—and why.
These notes describe the current prototype honestly: what it does, what it does not yet do, and the decisions made to keep operational claims grounded.
Architecture
A layered system with clear boundaries.
01Web workspaceResolution, demo planning, telemetry
02Core APIValidation, source handling, dispatch orchestration
03Location & ML servicesPostcode tools, ETA baseline, verified-learning path
04Mobile field appAuthenticated arrival evidence
The browser uses the core API through the same public origin. The API keeps sensitive credentials and protected operational actions off the public client. The field app signs in separately and submits evidence with its field identity.
Data flow
What happens when an address is resolved.
- InputA user submits a delivery description, landmark or known postcode.
- ResolutionThe service searches candidates, evaluates nearby context, retrieves lookup detail and assembles a standard address record.
- Source labelThe response retains its provenance. A local fixture is not presented as an official verification.
- Optional dispatch planningThe workspace may create a demo dispatch plan with transparent ETA factors.
- Field evidenceOnly an authenticated, provisioned field agent can submit an arrival observation for protected verification.
Architecture decisions
Decisions that shape the prototype.
Source-aware responses
The UI labels fixture, test and official responses so operators can judge whether a result can support a real operation.
AI explains; it does not certify
Provider-backed explanations are optional. They do not decide a postcode or override a source-backed resolution.
Evidence before learning
ETA telemetry starts with an explainable baseline. Learning claims require consented, verified arrival data.
Trade-offs
What we deliberately chose not to fake.
ChoiceWhy it matters
No synthetic “trained model” claimSimulated trips would make a dashboard look advanced, but would not prove real ETA accuracy.
No open field-agent sign-upField evidence needs accountable identities during a pilot; unrestricted public accounts would weaken that trust boundary.
No public browser KYC toolLocation verification and task completion are protected operational actions, not demo buttons.
Test environment disclosedThe product distinguishes a working prototype from approved production access.
Current status
What you can use today.
The public workspace demonstrates address resolution, source labelling, demo dispatch planning, quality checks and ETA telemetry. Approved pilot organisations can sign in, create protected workspace plans and issue one-time operator invitations. Field agents continue to use separately provisioned mobile accounts. Password recovery and managed email delivery are the next operational milestones.
Read the access guide