Personal AI Lab Asset Governance: Projects, Archive, Audits, Timeline — Four Categories That Don't Overlap

Asset Governance Notes

After a year of running an AI workstation, the disk reaches a strange state — the directory tree still looks tidy, but you genuinely can't find anything anymore.

At first I thought the directories just weren't fine-grained enough. Slice another level, add another tag, that should fix it. Turns out it doesn't. The problem isn't granularity. The problem is I was slicing along the wrong dimension from day one — I was slicing by content topic, and after six months that always blows up. Because the same asset, across its lifecycle, changes governance attribute; content topic doesn't. However neatly you arrange things by topic today, six months from now its identity in your head has shifted, but the directory hasn't followed.

This piece is one level of abstraction up. The site already has a few articles about how to manage a specific kind of asset — "Six Page Types for a Working Knowledge Base," "From Logs to Knowledge: Retain or Exclude Rules," a "Mac Mini System Audit Before Reinstall," and "Organizing a Large Personal Archive Library." Those all slice downward. This one goes the other way: before you touch any specific library or run any specific audit, by what attribute should every output be split into a handful of root categories? Once the root cut is settled, the rules for those downstream libraries actually start to make sense.

The cut I use now is four buckets — projects, archive, audits, timeline. Each one runs its own territory. No overlap.

Why not slice by content topic

For about a year I used "AI models / engineering projects / music / video / research." Looks intuitive, looks right — every thing has a home.

But it doesn't survive six months. The reason is simple: content topic is a static label, governance attribute is a dynamic identity. The same asset is a "live project" today, may be a "closed-out archive" tomorrow, and the day after that may become an "audit snapshot" because someone ran an inventory. Its content topic hasn't changed — still belongs in the AI engineering drawer — but how I'm supposed to treat it has completely changed.

Concrete example. The Jiyanran Voice Workbench project was, last year, a running engineering effort with weekly commits pushing it forward. Mid-stream we ran two external audits and left two timestamped snapshots. Some early modules stopped evolving and won't be touched again — by rights they belong in the archive. And a handful of decisive architecture changes from inside the project I wrote into the system-level timeline.

If I slice by content topic, "Jiyanran" is one directory and all of that piles in. The result: next time I come back wanting to know "what state is the system actually in right now," I get drowned by stale design docs from earlier rounds; want to look up "what did the most recent formal audit conclude," I'm digging through layers; want to see "when was this architecture decided," the timeline is buried in commit history, invisible.

Put another way — in a topic-sliced directory, no file tells you "what attitude you should bring when you open me." You have to re-judge every single time. After ten rounds of that, nobody opens anything.

Slice by governance attribute and it's a different game. A file sitting in "projects" means it's alive, may be edited, referenced, or pushed forward at any time. Sitting in "archive" means it's dead — you can read it, but don't treat it as current truth. Sitting in "audits" means it's a snapshot of a moment, and you have to read the timestamp to know whether it's still usable. Sitting in "timeline" means it's recording a system-level change — don't expand the content, just follow the reference.

The attribute is stable. Once an asset has been categorized, the way you treat it is locked in. The four buckets, one by one.

Category one: projects — alive, has an owner, still moving

The projects directory holds work that's currently in motion. The test is dumb on purpose — there's still an owner, there are still outputs, it's still being pushed, there are acceptance criteria. Fail any one of those and it shouldn't be in projects anymore.

The lines I have running on this machine right now are a handful — Music Index, OpenClaw, Jiyanran Voice Workbench, Linlu Video Factory. Each one has its own directory, its own git repo, its own .env, its own venv. Those four pieces are the critical physical isolation for project governance — directory, git, env, venv — drop any one and you're in trouble.

Why hammer on isolation? Because dependency conflicts in AI engineering are vicious. Two projects sharing one venv — within six months, one side's deps will get quietly broken by the other side's upgrade. Two projects sharing one .env — sooner or later a token crosses over: one project's key gets read by the other project's code. The light damage is blown quotas; the heavy damage is the wrong caller. Sharing a git repo, don't even get me started, the commit history goes somewhere you don't want to imagine.

Mess inside a project directory is fine — live work is messy by nature: drafts, throwaway scripts, dead logs, half-finished docs. All of that can sit in the project, no problem, because their fate tracks the project. Either they get promoted to a real output someday, or the project closes out and they move to archive together, or one day you confirm they're useless and just delete them.

The biggest danger in the projects directory is failing to move dead pieces out in time. If a project contains both "the live current version" and "an already-dead older version" without clear labels, the next time you go to edit, 95% chance you edit the wrong one. I've been there — meant to change v3, instead changed a same-named file left over from v1, took half a day to figure out why the change wasn't taking effect.

So there's an implicit rule for the projects directory: everything inside is alive by default. The second you notice something is actually dead, move it out. Don't "just leave it here, it's fine." That's the most common contamination path between projects and archive.

Category two: archive — past, closed, still has reference value

Archive holds things that are already dead but still worth keeping. Old wikis in cold storage, past research reports, experiments that finished and didn't get picked back up, instructional cleanups — that category.

The signature of archive is clear: won't be edited again, but you'll occasionally look back, better kept than deleted, and absolutely never authoritative.

My archive is physically isolated from current projects — ideally on a different drive. That sounds excessive — a directory is enough, do you really need a different disk? But physical isolation has a psychological effect: what your hand can't reach, your hand doesn't casually reference. This is the most invisible but most essential move in governance: keep bad options out of arm's reach.

The biggest pit in archive is just one thing — it gets referenced as if it were authoritative.

The worst version of this I ever ate was while debugging a config issue. The AI assistant pulled up the docs, found a design doc with "FINAL" right there in the name, plainly stating that the interface uses v3 and the field is called X. I made the changes accordingly and nothing lined up. Eventually I realized that FINAL was a year-old FINAL — v3 had long since been overturned, the field had long since been renamed, but after the doc got moved to archive nobody went back to poke at it. It sat in archive with FINAL in the filename, looking authoritative.

From that point I gave archive an iron rule — every piece of material in the archive directory is stale by default. Even if the filename says FINAL / SPEC / canonical, the moment it's in archive, it's stale. To use anything from archive as a basis, I have to go back to the live project and find the current version. If there isn't one, that information is treated as nonexistent — you don't get to grab the archived version and use it directly.

The rule sounds unfriendly — there's something right there, why can't I use it? But it's protecting me. What archive preserves is the historical value of "this is what it was at the time," not the factual value of "this is still what it is." Conflating the two is more dangerous than not keeping the file at all — not keeping it just means no information; conflating means wrong information.

So archive isn't a graveyard for data, it's a museum. You can view it, you can cite it as "the state at the time," but you can't take a museum piece into active duty.

Category three: audits — a snapshot of one moment

Audits are the output of a one-shot inventory. The system snapshot before a reinstall, a cross-project topology pass, a third-party security audit, your own periodic asset review — all of these belong here.

Audits have a signature that's different from both projects and archive. Projects are alive, archive is dead, audits are "dead at a specific point in time, but that point matters." It's a photograph. What it captured was the state at that moment.

Two rules for the audits directory — must carry a timestamp, must carry a stale tag.

The timestamp has to go directly into the filename or the directory name, not buried inside the file. This is a lesson learned the hard way, many times. If the timestamp only lives in the frontmatter at the top of the file, you only see it after opening — scanning the directory listing tells you nothing about what's old and what's new. Year and month in the filename, and one glance tells you whether this is from this year or last.

The stale tag matters more. The instant an audit snapshot is taken, it starts going stale — the only variable is how fast, which depends on how fast the system is moving. For stable parts of the system, an audit might still be valid six months later; for parts that are moving, an audit might be junk in two weeks. So the audits directory needs a mechanism that can tell you "is this one still usable" — right now I still tag by hand, and whenever the system goes through a major change I go back and mark the corresponding audits stale.

The biggest landmine in audits is an expired one being treated as current state.

This is worse than misciting from archive. With archive, everyone knows in their bones — you're reading history. Audits are different — audits were made for the purpose of "letting people know the current state," so the default assumption is "this is true." A three-month-old audit, with the system having changed several times in between and nobody marking it stale, the next person who pulls it up and uses it as ground truth has an extremely high chance of being wrong.

So when I run an audit now, I do two things at once — take the snapshot, and also come back to mark it stale when the system changes meaningfully. The second one I forget all the time, and every miss produces a problem. That's also why later in this piece I mention I'm working on stale automation — manual discipline can't carry this.

Audits and archive get conflated easily, but the difference is actually clean: archive is "this thing is dead, move it into the museum." Audits is "this thing is still alive, but at one moment I took a photo of it." The subject keeps living. The photo doesn't update.

Category four: timeline — the running log of system-level changes

Timeline records exactly one thing — system-level changes.

What counts as system-level? Changing the constitution — the machine-level general working guide. Changing directory structure. Installing a new resident service. Configuring a new LaunchAgent — macOS's background services that start at boot. Decisive architecture pivots. That class.

Anything that isn't system-level doesn't go in. "A specific project edited a specific file" — that's the project's commit history, not timeline. "An audit found something" — that lives in the audits directory, not timeline (unless the audit triggered a system-level change). "Read an article today, learned something new" — that's notes, not timeline.

Timeline is append-only — no deleting, no editing, archived by month. Every entry has to state four things clearly: what changed, why, who's affected, and which task or audit it references.

That "references" part is the critical one. Timeline doesn't repeat content, it only carries pointers. For any timeline entry, if you want details, you jump to the project directory or audit snapshot it references. This rule keeps the timeline itself thin — and thin is what makes it readable.

The biggest danger in timeline is every small change getting stuffed into it.

The temptation is real — once you have a running log, why not jot down every edit. But try doing that for one week and you'll see — the timeline drowns instantly. You wanted to know "what major changes happened this month," and instead you find 80 entries, 70 of them "tweaked a parameter" / "edited some copy" / "installed a tool." Nobody reads a log at that density, and even if you did you couldn't find the signal.

So the entry bar for timeline has to be high. My test for whether a change goes in is — three months from now, looking back at this change, will I still think it mattered? If not, don't enter it.

When in doubt, don't write. Missing an unimportant change is a small loss; writing too many unimportant changes invalidates the whole timeline, which is a big loss.

How the four categories reference each other

Once the four directories are settled, the relationships between them are tighter than you'd expect. But there's one principle — cite by pointer, never by copy.

A project hits a milestone and needs a snapshot, that triggers an audit — the project directory leaves one line, "audited, see audits/2026-05-jiyanran-stage-1.md," and the detail lives in the audits directory. If an audit surfaces a significant issue that demands a system-level adjustment, that triggers a timeline entry — the audit report leaves one line, "timeline change triggered, see timeline/2026-05/CHANGE_xxx.md," and the timeline leaves one line, "cause documented in audits/2026-05-jiyanran-stage-1.md." Both sides reference each other, but the content lives in exactly one place.

Project close-out and move-to-archive follows the same logic — the project directory disappears, the archive directory holds the complete snapshot, the timeline gets one line, "project X closed, archive at archive/xxx." That timeline entry becomes the only entry point anyone has, from then on, for finding that project.

Timeline references projects and audits; projects and audits rarely reference timeline — because timeline is an after-the-fact summary, projects and audits are in-flight artifacts. This one-way relationship keeps the directories from forming cycles.

Archive's reference relationship with the other three is the weakest — archive mostly gets referenced, it doesn't actively reference others. It's a terminus.

I didn't think this reference structure through up front either — it emerged from using the system. Once it stabilized, looking things up became a very mechanical motion — first check the timeline to know roughly what happened in what window, then jump to projects or audits for the actual content, and finally, if you need historical background, dig through archive. Three steps cover any lookup.

Real scenarios: how the four buckets work together for decisions

The value of this cut shows up in real scenarios. Three that come up for me a lot lately.

Scenario one: picking up an old project that hasn't been touched in three months.

The old flow was — open the project directory, read the latest doc, start guessing. The problem is, docs in the project directory don't separate truth from junk — some are old design drafts, some are abandoned mid-stream proposals, only a few are the version that's actually running. I'd often spend an hour or two just figuring out "what state is this project actually in right now."

The current flow is — look at what the most recent commit in the project was about, then go to audits and find the most recent snapshot for this project (timestamped, you can see the month at a glance), then go to timeline and pull the system-level changes touching this project in the last three months. Stitch the three together and I'm in context in ten minutes. The audit snapshot tells me "what it looked like at that moment," the timeline tells me "what's changed since," and the latest project commit tells me "what's moving right now." Three angles cross-checked is more accurate than any one of them alone.

Scenario two: debugging a configuration conflict from nowhere.

For example, some day a service suddenly can't reach a port, and you don't remember changing any related config.

Used to be I'd dive straight into the project code and grep commits, often coming up empty — because the issue might not even be in this project, it might be a system-level adjustment that changed port allocation, or a LaunchAgent config somewhere.

Now the first step is the timeline — any network, port, or service-related system-level changes in the last month? Second step, the "known config conflicts" section of the most recent system audit — audits typically jot down conflicts you've already discovered. Two steps and 80% of the weird issues land at a root cause. The remaining 20% is when I go into the project and grep commits.

The order matters — system-level first (timeline + audits), project-level second (commits). Reversed, you cut your efficiency in half.

Scenario three: writing a technical blog post.

Like the one I'm writing right now. The material splits into two parts — archive has the related cleanups I've done over the past year, projects have the practice that's still moving in the last month or two.

Archive is in charge of "what I used to think," projects are in charge of "what I'm doing now." Cite both and the piece gets temporal depth. Cite only archive and it reads like history; cite only projects and it reads like technical minutiae. Putting the two side by side is what lets the piece explain "why, after changing my mind this many times, I landed on this cut."

Audits don't show up much in this scenario — audits are engineering archives, you don't cite them in public writing. But occasionally for a postmortem about "the time we made a major adjustment," the audit snapshot is the most authoritative source you have.

What this governance actually changed

The numbers shifted more than I expected.

Before the cut — the work outputs on this machine were spread across more than a dozen directories. Finding one file took an average of three or four directory dives, and on a bad day half an hour wouldn't find it.

After cutting into four — 95% of the time I can locate a file in under thirty seconds. The remaining 5% is mostly gray-zone material I never properly classified, and each time I hit one I reshelve it on the spot. The gray zone keeps shrinking.

The bigger shift is psychological — I'm no longer afraid of "can't find it." Every previous lookup carried this latent anxiety of "what if I can't find it this time." That anxiety feeds back into behavior — you subconsciously look back less, rely on memory more, and lean on "should be fine" more.

Now I don't lean on memory. I need something, I go to the right drawer and pick it up.

The parts I'm still changing

This governance is nowhere near done. A few things are still growing.

First, stale-tag automation for audits. Right now it's manual — every time the system changes, I go back and mark a batch of audit snapshots stale. The miss rate isn't low. The ideal is a script that periodically scans the audits directory and computes which snapshots are stale based on the current system state. The thing is harder than it sounds — "current system state" doesn't have a machine-readable definition, so you'd first have to formalize "system state" before any script can judge.

Second, the criteria for moving a project to archive. Right now it's pure intuition — I think this project is dead, so I move it. But there's a fuzzy band between "I think it's dead" and "it's actually dead." Move it too early and the project gets pulled back into active use; move it too late and dead stuff keeps polluting the project directory. The ideal is a set of criteria — how long since the last commit, are the dependencies still alive, is there an owner — and meeting enough of them triggers a "suggest archive" prompt.

Third, cross-category reference mechanics. I wrote about this above — the four categories cite each other, but the references right now are plain-text paths in markdown. Move a file and the link breaks. On a single machine I can live with it; the moment it's multi-machine, it falls apart.

Fourth, multi-machine sync. I have more than one machine running now — Mac mini, Mac Studio, Mac Air, each with its own role. The four categories exist on every machine, but whether they should fully sync or each machine should only carry what it locally uses, I haven't decided. Full sync's upside is any machine can pick up where another left off; the downside is the project directory swells fast. Local-only is clean, but cross-machine collaboration suddenly lacks things. This probably needs to split into something like "projects per machine, archive fully synced, audits per machine, timeline fully synced" — but I haven't actually run it, so I don't know what pits it'll dig.