Blog

This week we tested what happens when the AI side of Tyina goes wrong. We scripted the intent layer to demand full speed ahead, every cycle, no matter what — then ran it on the robot with the normal safety core underneath, unmodified. Over twenty decisions, it never got what it asked for. With the path clear it was allowed to move, held to 0.1 m/s. When someone stepped in front, it stopped at 1.9 metres — "BLOCKED — protected_obstacle_person_or_animal [person 71%]" — and stayed stopped while the detection flickered. A cardboard box stopped it at 0.4 metres. When the sensor feed dropped out for a moment, it stopped for that too: "refusing to act blind." Each decision was written to a chained log with its reason — change a line and the chain breaks, remove one and the gap shows. The bad commands were ours, on purpose. The refusals were the robot's.

It’s built. Tracks, an arm, a depth camera, a Raspberry Pi doing the thinking. Until now Tyina has lived in simulation — planning grips, mapping sites, proving itself with no body to run on. Next, the engine goes onto the hardware. Brain first was always the plan: prove the thinking on its own, then give it something that moves. Nothing’s driven a metre yet, and loading the code doesn’t change that — a grasp, a route, a pick stays locked until it’s done for real. But the engine and the machine are about to meet for the first time. We’ll show how it goes.

The grasp engine plans a pick. The field planner maps the ground. The missing piece between them was always: how does someone actually build a job — without writing code, and without being handed a black box that might do anything?

This past stretch I built that piece. It's a blueprint editor — I've been calling it the Logic Builder.

How it works

You wire a job together from blocks. Each block is one proven action: drive to a point, cover an area, pick something up, observe, wait. You drag them into the order you want, and that's the job — go here, scan this area, pick that up, come back.

The clever part isn't the blocks. It's that the complicated engineering stays sealed inside each one. The operator works with the arrangement — the order, and what each step is pointed at — not the maths underneath. You don't need to understand how a grip is calculated to drop a "pick" block into a sequence. You just need to know you want it to pick something up there.

It connects to the planner too. Draw your area, your route, your drop-point on the map, send it across, and each block in the job binds to a real shape you drew. The same job can run on a different site by re-pointing it at new shapes — you build the logic once, not again for every field.

Where the safety sits

This is the part I cared most about getting right. The Logic Builder doesn't contain any safety — it can't. It only lets you select a safety setting per block, from a fixed set the tool can't edit. A driving block stops for almost anything in its path. A ground-work block tolerates brushing against low growth, so it doesn't freeze on every blade — but underneath every setting is a floor that always stops for a person, an animal, anything solid, or anything it can't identify. No block, no setting, no operator can switch that floor off.

So an operator in the field gets real power — they can build and adjust the work themselves — without ever being able to weaken the safety underneath it. They arrange; the frozen core enforces.

The honest part

Nothing an operator builds is trusted just because they built it. A new job is checked automatically, and it stays unproven until it passes a real test on the actual machine. Until then it doesn't appear as a runnable button. Right now, on the bench, that means the proven list is empty by design — and that's the system working, not a gap. The day the arm is here is the day jobs start earning their place.

It's gated, too: building and changing jobs sits behind a login, and every change is recorded against whoever made it. The operator runs proven work; the author builds it; the machine proves it.

All of this runs today in simulation. None of it has driven a metre. But the loop is real now — draw a site, build a job by wiring proven blocks, see it checked against the actual engine — and it's ready for the moment there's a motor on the other end.

The grasp engine looks at a cluttered desk and works out how to pick something up. Lately I've been building the same kind of thinking for a much bigger space: a piece of land, and the work a machine might do across it.

It's a planning tool. You load a picture of the place — a satellite screenshot, a drone photo, an old farm plan — and trace your world over it: where home is, the route a machine would follow, the no-go areas it must never enter, the gates, the boundary markers. Then you can ask the engine to check it — how far the route really is, whether it strays into a no-go zone, whether the destination is named.

The distances are real, not guessed. There's a measure tool: draw a line over something you know the length of — a barn wall, a gate gap — type the real metres, and the engine scales the whole map from that one known distance. Add a second known length and it cross-checks them, and tells you honestly if they disagree, which usually means the photo was taken at an angle where a flat scale starts to drift. It's a small idea with a long reach: it's how you turn a scaleless picture into a rough map without needing satellite positioning at all. And that matters, because a lot of real land doesn't have a reliable signal — under hills, under trees, miles from anywhere.

Here's the part I want to be plain about: there is no machine attached to any of this. The planner is the interface; behind it is a real engine doing the calculation — and that engine talks to nothing physical yet. I built it this way on purpose. The hardest and most valuable thing in a transparent system isn't the motor; it's the part that decides and explains. So I built that first, where it's cheap to get wrong, where every decision can be read back in plain terms, and where a mistake drops nothing and harms no one.

It also means the join is already there. The interface asks the engine, the engine answers, and when there's a real machine, the same engine is what it plugs into. I'm not going to bolt a brain onto a moving machine as an afterthought — the brain comes first, proven on its own.

Where this stands

Everything here runs today, in simulation and on the bench. The grasp engine plans a pick and explains why, and refuses with a reason when it can't, all without trained data. The field planner lays out the work and checks it against a real engine. None of it has driven a metre.

The next stage is to scale up — and it's staged on purpose. First a robot arm gives the engine real hands and turns on the reality gate. Then a larger RC vehicle, retrofitted as a controllable test platform, where the same principles meet a real motor, a real camera, and the messy real world. Simple, rigid jobs first — carry a load, follow a set route, stop for anything in the path — before anything scales. The brain comes first, proven on its own; the bodies follow.

Tyina exists because most robotic intelligence is a black box. A neural network makes a decision, and not even its builders can point to why — the reasoning isn’t written anywhere readable; it’s spread across millions of tuned numbers. When it makes a strange mistake, there’s no line to fix, because there is no line. You retrain it and hope.

So Tyina keeps its decisions in readable, deterministic logic you can inspect.

But AI is useful for writing that logic. It can draft a solution to a fiddly problem far faster than a person can type one. The temptation is to let it write the engine’s code and move quickly.

That’s the trap. Build on top of code you never read, and you get a tower of logic no human has verified. Each line is readable in principle — but nobody read it. Readable-but-unread is its own black box. You’d have escaped the neural-network tangle only to build a new one out of unreviewed code.

The point is to keep the speed without losing the transparency. So Tyina has a mechanism for both.

Locked and unlocked

Tyina has two modes.

Locked is the operating mode. Only approved, tested code runs; the AI cannot introduce new logic. Once the engine is doing a real job, the code has earned its place and nothing rewrites it.

Unlocked is development mode. The AI can propose code, quickly — but everything it writes is logged and quarantined as provisional. It does not run as trusted logic, and nothing can be built on top of it until it has earned trust.

A neural network’s reasoning vanishes the instant it happens; it was never text, so you can’t go back and read it. Here, every line the AI writes is recorded as readable code, permanently. It may be written faster than a person can follow live, but you can always go back and read exactly what it wrote, and why. A fast process with a complete record.

How code earns trust: three gates

Provisional code becomes trusted only after passing three gates, in order:

1. Safety. Checked automatically against Tyina’s fixed safety limits. Anything that could produce an unsafe action is rejected here.
2. Human. A person reads it and approves it. This can’t be automated — the point is that a human has looked.
3. Reality. It’s tried in the real world, and the real test passes. Not a simulation, not the system checking its own homework. The physical outcome confirms the code does what it claims.

Pass all three, and the code is locked in. Fail any, and it expires — discarded, never built upon. That last rule is what stops the tower of unreviewed code from forming: code that doesn’t earn trust doesn’t survive.

Where this stands

The third gate — reality — needs a real-world test: a robot arm attempting the action and succeeding. The arm is the next step, so that gate isn’t active yet. The mechanism is built and runs as designed, but until there’s a physical test to pass, it promotes nothing.

That’s deliberate. Promoting AI-written code on a simulated success would mean checking an invented result against an invented test. The mechanism waits for reality instead. When the arm is here, the gate has something real to check against — and code can earn its place.

Why this matters

The AI proposes; deterministic, inspectable logic decides; reality has the final say. The AI does the fast part — suggestions, first drafts — and none of it becomes load-bearing on trust alone.

The safety core sits outside all of this. The AI proposes engine logic only; the fixed safety limits are frozen and human-only. The lock is on the engine’s door — the safety layer has no door the AI can reach.

Until now, Tyina lived in simulation. This week it opened its eyes on the real world for the first time — and it worked.

With a depth camera pointed at an ordinary, cluttered desk, you can now type or say the name of an object, and Tyina finds it, plans how to grip it, and explains what it's doing in plain language. Say "pick up the onion" and it locates the onion. Say "the watch" and it finds the watch instead — the same scene, a different object, the right answer each time. When the conditions aren't right to grip something safely, it doesn't guess and lunge — it stops, and tells you exactly why.

That last part is the whole point. Most capable robots today are black boxes: they're trained by copying humans thousands of times, and even their creators can't fully say why they move the way they do. Tyina contains the black box rather than removing it — borrowed AI vision does the perceiving, and that part is a neural network. But it only chooses what and where; a transparent engine calculates the grip from the object's real shape, fixed safety rules sit underneath, and the AI can never override them. The vision can misread what it sees — it can never take an unsafe action. Every decision the engine makes is visible and can be audited. There's no mystery about how it reached its answer.

This is an early step, and an honest one. Right now Tyina plans a grasp — it doesn't yet physically pick things up. The next stage is a robot arm, and the groundwork to drive it is already built and tested. But the hard, interesting part — a machine that can look at something it's never seen, reason about how to handle it, and tell you what it's thinking — is real now, on real data.

We think that combination matters — and it's worth being plain about what the grasp engine is. It's a deliberately readable, classical method, chosen because every step can be inspected. It isn't the headline; it's the simplest honest proof that transparent action works. The product is the governance around it: a safety law the AI can't touch, and a record of every decision. A robot that explains itself and refuses rather than blunders is suited to places where you can't send an engineer to debug a black box — structured workspaces, and one day perhaps far stranger environments. We're building it in the open.

If you're an investor, a builder, or just someone who finds this interesting — we'd love company on the journey. Get in touch.