Work / Selected projects
We use internal R&D to test our engineering approach in working systems. Each project starts with a defined problem, implements the essential functions, measures the result, and states what still needs to be validated.
01 / MAPPER
Active R&D · full pipeline tested with synthetic data · field validation pending
Mapper combines repeated sensor observations from a manually driven survey to estimate landmark positions, course boundaries, a centerline, and uncertainty. It packages the result as an offline review file that operators can inspect and correct.
The first panel shows a vehicle following an imperfect path while repeatedly observing course markers. The second shows Mapper’s reconstructed boundaries and derived centerline.
The vehicle may weave, reverse, follow one edge, or make multiple passes. Each frame contains sensor observations and an estimated vehicle pose. Mapper uses both to reconstruct the course; the route driven is not itself the course.
Mapper estimates marker positions and course boundaries, derives a centerline, and reports uncertainty so an operator can inspect and correct the result.
HOW IT WORKS
Mapper converts each observation from vehicle coordinates into a common map frame. It then associates repeat sightings of the same marker, estimates marker positions, and fits the course boundaries and centerline. Because the driven path only positions the observations, the operator does not need to follow the eventual centerline.
These measurements come from nine synthetic driving scenarios, not field trials. The end-to-end pipeline is implemented, but field accuracy has not yet been measured. The current pipeline also produces 1.1–2.3 times as many landmark estimates as there are markers. Version 1 uses manual vehicle control; autonomous survey planning has been evaluated only in simulation.
02 / EVENT PLATFORM
Working development system · synthetic test data only
The platform handles registration and event operations while reducing the data that can be linked across events. Passkeys handle sign-in. A client-encrypted vault lets participants reuse their information, while event-specific sharing and separate keys and policies limit what each service can access. This development system demonstrates the architecture and core workflows; it has not yet been evaluated for production security, availability, or regulatory compliance.
KEY DESIGN CHOICE
The server does not maintain a central record linking each participant to every event. Participants keep reusable information in a client-encrypted vault and share only the fields an event requires. Separate service roles and encryption policies limit who can decrypt each category of data.
Participants keep reusable information in an encrypted vault; the server does not keep a cross-event participation map.
An organizer can record the result of an eligibility check without storing the source document or its identifier.
If the encryption service is unavailable at startup, the application stops rather than bypassing encryption.
Registration, waivers, payments, check-in, scheduling, staffing, and results follow the same rules for which data an event receives.
WHAT THE WORK DEMONSTRATES
These projects force architecture choices into working code, where integration problems become visible and results can be measured. We show both the evidence and the current limits so prospective partners can judge our work on its merits.
Working on a related system?CONTACT
Tell us what the system must do, what exists today, the constraints that matter, and when you need a result.
[email protected]