Treyam · Work · Reference models

Reference models.

Three systems built to specification, each one showing how a complete loop is put together rather than how a single stage performs.

01 — Calibration

Read the borders first.

Everything on this page is drawn in one of two channels, and the channel is legible before the words are.

Calibration notice

These are reference models — systems built to specification to demonstrate the architecture we apply. They are not named client engagements, and the figures shown are engineering targets, not measured outcomes. We publish no performance figure we cannot put a name against.

Throughout this site, solid rules mark measured values and dashed rules mark modelled ones.

MeasuredModelled

02 — The models

The loop, applied three ways.

Each model states the target it was engineered toward, the method used to reach it, and the shape of the change. None of them carries a claimed result. They were built to demonstrate an architecture, not run in production long enough to measure one.

MeasuredModelled

REF-01 · Model

Robotics & automation

Autonomous warehouse fleet

Representative system. Not a named client engagement.

Target: Path conflicts resolved at fleet level, not per unit
Method: ROS 2 orchestration, shared occupancy map, central arbiter
Scope: Multi-aisle facility, mixed-payload mobile units, design target 50+
Outcome: Collision avoidance moves from each robot negotiating locally to one planner holding the whole floor

REF-02 · Model

Machine learning & networking

Urban intersection sensing

Representative system. Not a named client engagement.

Target: Inference at the pole, not in the datacentre
Method: Edge vision models, batched telemetry, store-and-forward uplink
Scope: Signalised intersections with intermittent backhaul
Outcome: Decisions survive a network outage because the deciding stage sits on the same pole as the sensing one

REF-03 · Model

Cloud & platform

Zero-downtime platform migration

Representative system. Not a named client engagement.

Target: Cutover reversible at every step
Method: Dual-write, shadow reads, blue/green cutover, single-command rollback
Scope: Stateful services with a live transactional workload
Outcome: Migration becomes a sequence of reversible steps rather than one irreversible weekend

Targets, not outcomes.

03 — Solid channel

What is measured

The section above is modelled from end to end. This one is not. Every line below is a commitment we would be embarrassed to fail, and each has something behind it you can ask to see.

First technical reply within 24 hours, from a named engineer on a rota rather than a shared inbox. Evidence: the ticket log.
Handover reproducible from an empty account, because the infrastructure is defined in code and the runbook is written down. Evidence: the repository.
Rollback in a single command, with no incident call attached to it. Evidence: the runbook and the deploy history.
No system depends on one person to operate it. Evidence: the access register.

A dashed border is not a hedge. It is how you can tell, with the labels covered, which claims we can put a name against.

Bring us the system you cannot currently measure.

Tell us what the loop looks like today and where it breaks. We will tell you which stage we would instrument first, and what that would cost.

Start a conversation See the six stages

hello@treyam.in · Bengaluru, India