Founding engineering
Working across Inferal's engine, ontology, and Relay
My work at Inferal spans the core engine, the ontology system that gives connected data explicit meaning, and Relay, the synchronization capability I built from the ground up.
One product, three connected layers
The engine, ontology, and data-ingestion path cannot be designed as unrelated pieces. Data has to arrive from external systems, retain a clear model of what it represents, and become usable by the runtime that acts on it. Working across all three gave me an end-to-end view of those boundaries and the decisions that connect them.
The engine
I work on Inferal's core engine: the part of the product responsible for turning its data and behavior model into running software. The detailed implementation remains proprietary; the relevant scope is that this was foundational product work rather than an isolated application feature.
The ontology system
I also work on the ontologies used to give connected data an explicit, shared model. That work sits at the boundary between external schemas, internal meaning, validation, and what the engine can safely infer or act upon.
Relay
I built Relay from the ground up as Inferal's data-synchronization capability. It brings data from internal systems and third-party APIs into the product while preserving the structure needed by the ontology and engine layers.
The dedicated Relay case study describes the public engineering scope and the design pressures behind that work without exposing proprietary implementation details.
Founding-engineer scope
The important part of this experience is the breadth of responsibility across a product whose architecture was still taking shape. It required reasoning about interfaces between subsystems, not optimizing one component in isolation, and making choices that later work could build on.