Index  /  AI & Philosophy  ·  Sheet 8 of 11

AI & Philosophies

Specs · Memory · Governance

Most people are using AI as an oracle — ask a question, receive an answer, hope. I use it as an implementor, which means my job is writing a spec good enough that a capable stranger couldn't misread it.

The reframe

The shift that made AI genuinely useful to me was not a better model. It was realizing the failure mode was mine. I was handing over wishes and grading the results, then being surprised when the output drifted from what I meant but hadn't said.

Automation people already know this discipline. You cannot ask a machine to "handle the product properly." You specify the gripper force, the approach vector, the fault condition. AI is the same negotiation with a much better vocabulary, which makes it more dangerous, because it will confidently fill your gaps rather than fault on them.

The memory problem

The other structural problem is amnesia. Every session starts from zero. Everything learned last time — the decisions, the reasons, the things we already ruled out — has to be re-derived or re-explained.

That's a shift handoff problem, and manufacturing solved it decades ago with a logbook. So: a substrate. Typed, queryable, holding the conversations and the analysis and the relationships between them, so the next session starts where the last one ended.

SUBSTRATE typed · queryable THE WORKpanels · code · calls ANALYSISwhat repeated? NEXT SESSION nothing is learned twice

The interesting part isn't storage, it's the loop. If every correction gets recorded, the corrections that recur stop being corrections and become guardrails. Then the guardrails do the correcting, and you stop repeating yourself. That's the whole bet.

What it actually looks like

This is MemOS — the shell I work inside. Three things are on screen at once and that arrangement is the argument.

MemOS shell showing database tables, a SQL query, a local model panel and persistent startup notes
01Left: the substrate's own tables. Middle: a query against it. Right top: a local model on localhost. Right bottom: the notes that load at startup — including the one that reads "Architect: Rick. Documenter: Claude. Implementor: GitHub Copilot." The working agreement is a row in the database, not a paragraph in a file nobody re-reads.

The tables are typed, not generic. conversations, analysis_units, documents, edges, rungs, plc_tags — the schema knows what kind of thing each row is, so a question can be asked in SQL instead of grep. That was a deliberate pivot away from an everything-is-a-node store, and it is the single decision the whole thing rests on.

Note the fourth row of the ai table: Claude and claude, both present. Identity is a surrogate key precisely because labels get entered twice by a human at eleven at night.

MemOS Eliza tab showing an imported conversation corpus and a retrieved session
02The corpus, and the loop closing. Hundreds of imported working sessions on the left; on the right, one of them opening with "what projects do I have open yet" — and the answer being assembled by reading the record rather than by remembering it.
SQLAccess showing the memos.sqlite schema and document sections
03The same substrate from a plain SQL client. 57 tables. The documentation for the system is stored as rows inside the system it documents, which is either elegant or a warning sign, and I have not fully decided.
Honest status

None of this is finished. The screenshots show a working tool that I use every day and that still has features built, verified, and one step short of being real. That gap is the normal state of a system under construction, not a thing to be embarrassed about — but it would be dishonest to show you the shell and imply it's done.

Positions I hold

An oracle answers, an implementor executes

The second one is far more useful and requires far more of you. Most disappointment with AI is a spec problem wearing a technology costume.

Folders are evidence, not authority

Where a file sits tells you what someone was thinking that day. Useful. Not the same as true, and treating it as true is how a system rots quietly.

A wrong record stays as written

Don't quietly patch history. Write the correction as its own entry, stating the defect. The error is data — overwriting it destroys the evidence of how you think.

Provenance is not verification

Something you recover from your own notes feels verified and isn't. It carries the assumptions it was written under. Re-check before acting on it.

The bounded view is a feature

An implementor that only sees the task can't be biased by strategy it shouldn't have. Compartmentalization isn't distrust, it's a cleaner signal.

Design for additive growth

No rewrites. If the next phase needs the last one demolished, the architecture already failed and is only now telling you.

The honest caveat

I've been doing this for a couple of years, not a couple of decades. These are working positions, not conclusions, and I expect to revise several of them. That's what the revision block is for.

This sheet is the positions. The day-to-day procedure they produced is on Working With AI, and the story of how it all got this way is the timeline of the black box.

← ProgrammingProcess Control →