Say you run NAOMS on three machines: a laptop you carry, a desktop that stays plugged in, and a small server humming in a closet. They're all part of one fleet, all talking to each other. Now a job comes up that only one of them can actually do — it needs a graphics card, or it's a heavy build, or it wants a real browser open. Which machine should it go to?

Until recently the honest answer was "you'd better know, because the fleet didn't." Now it does. Every machine in your fleet carries a record of what it can do, and when a job appears, the fleet sends it to a machine that can actually run it — and never to one that can't.

flowchart LR
  A[A job that needs a graphics card] --> B{Which machines can do it?}
  B --> C[Laptop: no GPU — excluded]
  B --> D[Desktop: has GPU — ranked]
  B --> E[Home server: has GPU — ranked]
  D --> F[Job lands on the best-fit machine]
  E --> F

Two kinds of "what I can do," kept apart on purpose

The interesting part is that a machine's capabilities come from two separate places, and we are careful never to let them blur together.

The first kind a machine works out about itself. It looks at its own hardware and software — is there a graphics card, can it build, can it drive a browser — and writes that down. Because a machine can change (you plug in an external card, you install a tool, you take one away), this self-knowledge comes with a freshness limit. After a while it's considered stale and gets checked again, rather than trusted forever. This is the honest kind: it only ever claims what the machine could confirm about itself, recently.

The second kind you declare by hand. Sometimes a machine can genuinely do something that no amount of self-inspection will reveal — a capability that lives outside what a quick self-probe can see. For those, you state it plainly: "this machine is allowed to do this." And that statement is signed. It isn't a note anyone on the fleet can scribble; it's a cryptographically signed assertion, and only a machine you've marked as a trusted primary is permitted to make one. A random machine on the fleet cannot declare itself capable of something and have the rest believe it. The declaration carries a signature, and the signature is what makes it trustworthy.

Keeping these two layers distinct matters. One says "here's what I checked about myself lately." The other says "here's what a trusted authority has vouched for." We never quietly promote a guess into a vouched fact, and we never let an unsigned claim wear the authority of a signed one.

How a job finds its machine

When there's work to place, the fleet does two things in order.

First it excludes — hard. Any machine that can't do the job is removed from consideration entirely, no exceptions. If a job needs a graphics card, every machine without one is simply out; it will never be handed the work "just to try." This is the part that keeps a job off a machine that would fail it.

Then, among the machines that remain, it ranks. More than one machine might be able to do the job, so the fleet orders them by fit and sends the work to the best one. Machines that are a poor fit — busy, or flagged as troublesome — get pushed down the list rather than picked. So the outcome isn't just "a machine that can" but "the best-suited machine that can."

The upshot for you: you don't hand-place work anymore. A job that needs a graphics card, a build, or a browser is routed to hardware that fits — on its own. A GPU job doesn't land on your laptop. A build doesn't land on a machine that can't build.

The honest limit

Here is what this does not yet do, stated plainly.

The fleet routes and ranks before a job starts. It picks the right machine at the moment of dispatch. What it does not yet do is re-check that machine partway through a long-running job. If a machine's situation changes after the work has been placed on it, the fleet won't currently notice mid-job and move the work elsewhere. Routing is a decision made up front, not a live probe that runs the whole time.

And the declared, signed capabilities carry their own honest caveat. A signed declaration is an assertion of trust — a trusted primary machine vouching that something is true. It is not a continuous live measurement. If you declare a machine capable of something and that later stops being true, the declaration doesn't automatically retract itself; it stands until it's changed. That's the nature of a signed vouch versus a self-probe: one is trusted because of who signed it, the other because it was recently checked. We show them as what they are, and we don't dress a vouch up as a live reading.

What's here today

Live now: every machine in your fleet carries both capability layers — the self-checked one with its freshness limit, and the signed, declared one that only a trusted primary can write. Job placement uses them together: hard-exclude the machines that can't, rank the ones that can, send the work to the best fit. The real thing that already leans on this is the fleet's own internal work-picking — it's not a demo, it's how jobs get placed.

Still ahead: re-checking a machine mid-job so long-running work can move if a machine's situation shifts under it. For now, the decision is made well, once, at the start — and that alone is the difference between a fleet that quietly sends work where it fits and one that hands you the placement problem yourself.

If you'd like the wider tour of everything that shipped alongside this, the week's dispatch ties it together.

Written by AI agents from real project logs; owned and edited by Mujo.

Written by AI agents from real project logs; owned and edited by Mujo.