Updated March 2026
This article has been fully rewritten to reflect the Storage Architecture Spec v1: operator-confirmed factory root, omatic.project.json manifest, Fred’s consent model, iCloud and topology handling, and the tracking directory migration target.
Engineering Brief · O-Matic Research Lab
O-Matic Storage: The Factory That Finds Its Own Home
Every storage system assumes it knows where you keep things. O-Matic Storage starts by asking — and remembers the answer forever.
Jimmy Walker · O-Matic · March 2026 · 6 min read
Most tools decide where your files live. They pick a folder, assume a path, and proceed. If that folder doesn’t exist or you’d prefer somewhere else, the tool shrugs. You adapt.
O-Matic Storage works the other way. When a new factory instance starts for the first time, it doesn’t assume anything. It looks at what’s actually available — your Documents folder, a network share, an external volume, iCloud Drive — and presents you with options ranked by suitability. You confirm a location. The factory writes that decision into its manifest and never revisits it unless you say so.
That’s not a small shift. It’s the design principle the entire storage layer is built on: the factory adapts to the operator, not the other way around.
The manifest is the truth
Once you’ve confirmed where the factory lives, that path is recorded in omatic.project.json — a single JSON manifest at the factory root. Everything the factory needs to know about itself lives there: where it is, which agents are active, which MCP connectors it uses, what storage paths Fred has been granted access to.
The manifest is the single source of truth. When the factory starts up, Probot reads it. When Fred needs to find a file, he checks it. When a connector changes, the manifest updates. Nothing is assumed, implied, or hardcoded.
This matters more than it sounds. A factory that stores its own identity in a known, portable, human-readable file can be moved, backed up, audited, and recovered. A factory that assumes its own location cannot.
Fred and the consent model
Fred is the agent who actually touches your files. He indexes them, references them, and retrieves them for other agents on request. What he doesn’t do is go anywhere he hasn’t been invited.
Every path Fred operates in is logged in the manifest’s storage index. The first time Fred encounters a path that isn’t already there — a folder you open, a directory you point him toward — he stops and asks. Three options: add it to his permanent index, allow it just this once, or skip it entirely. He won’t proceed until you’ve answered.
This isn’t over-engineering. It’s the difference between an assistant who respects your filing system and one who treats every folder as fair game. Fred knows the difference between your factory files and your personal documents. The consent model enforces that separation structurally, not through trust.
iCloud, network shares, and the topology problem
Storage in the real world is messier than a single local folder. O-Matic Storage handles this by detecting what you’re actually working with — and being honest about the tradeoffs.
iCloud Drive works, but files need to be set to “Keep Downloaded” or operations will fail silently when the file hasn’t been pulled down yet. Fred flags this when he detects an iCloud path and won’t proceed until you’ve acknowledged it. External volumes work, but they need to be mounted at every startup — Fred notes this too. Network shares work, but latency can affect read/write speed on large operations.
None of these are blockers. They’re conditions. The factory tells you what it found, explains the caveat, and lets you decide. That’s the right model for a system that might live on a MacBook, a desktop connected to a NAS, or a development machine with an external SSD.
What Fred never does
Worth stating plainly, because it shapes every design decision in this layer: Fred never moves, renames, copies, or modifies your files without explicit per-file instruction. He indexes. He references. He retrieves on request.
If something needs to be deleted from the factory itself — an old agent file, an archived session log — it goes to .trash/ inside the factory root. Nothing is permanently deleted. The factory treats irreversibility as a hazard, not a feature.
What’s next: machine-readable state
The current tracking system stores session state and agent rosters as markdown files — readable by humans, writable by Fred, but not easily parseable by other systems. The spec targets a split: session logs stay as append-only markdown in tracking/logs/, while machine-readable state moves to JSON in tracking/machine/. Agent Sig numbers, factory status, open items — all in structured JSON that downstream tools and the Layer 3 orchestrator can consume directly.
That migration is scoped and logged. It’s the next infrastructure step, not a future aspiration.
The system adapts to the human. Not the other way around.
Filed: O-Matic Research Lab · o-matic.io · Engineering Brief · Storage Architecture · Factory Design
