Veritas Workstation — Useful Tips

VERITAS-START-HERE.md tells the AI how to behave inside this system. This document tells you — the human directing it — how to work with it so the work actually sticks.

You don't need to know the internal architecture to use this correctly. You need one habit.

You've hired contractors your whole career. Here's what makes that model work even though no single contractor remembers everything: the handoff ritual. A contractor gets a scoped work order, does the work, and reports back to the team before moving on. The report is what makes the work durable — searchable, referenceable, something the next person can build on six months later.

Veritas Workstation doesn't do that step automatically. A conversation with Claude, however much real work happens in it, is the "doing the work" part only. Nothing files the report unless someone explicitly tells it to. Skip that step, and the work is real — the site got built, the deploy went live — but the institutional record of it never gets created.

At two points in any substantial piece of work, say something explicit. You don't need exact wording — plain language works — but the intent has to be there.

1. Opening the work order (optional, but helpful for bigger things)

Before diving into something that'll take real effort — a migration, a new build, a research project — you can say:

"Let's open a Work Item for this."

Not required for every task. Most useful when you already know something is going to be multi-step, multi-session, and worth tracking from the start rather than reconstructing afterward.

2. Closing the work order (this is the one that actually matters)

When you're done with a piece of real work — before you move to something unrelated — say so explicitly:

"Close this out." · "Write this up as a Work Item." · "Log what we just did."

This is the single habit that would have prevented today's problem. It's the equivalent of the contractor calling the office before driving to the next job site. Everything else in this manual is secondary to this one trigger.

Not every question needs a Work Item. Use this test: would you want to remember this in three months, or would someone else on your "team" need to know it happened?

• Yes → close it out.
• It's a quick question, a lookup, something with no lasting footprint → skip it, no ritual needed.

Examples from real sessions:

• Migrating a business's website into Veritas and launching a new domain → close it out.
• Asking what a file contains → skip it.
• A real business decision, a signed term, a pricing model → close it out.
• Checking whether a link is broken → skip it, unless the fix itself is substantial.

You don't need the architecture. You need to know there are two different filing cabinets, and both require the same closing habit to actually get used:

1. Claude's own memory of you and your business — carries across every conversation regardless of this repository. Good for durable facts: who you are, how you like to work, standing context about a deal or a relationship. Say "remember that..." any time, and "forget..." to remove something that's gone stale.
2. Veritas's internal filing system (Work Items, runtime logs, truth records) — the repository's own institutional memory, specifically about the organization's work. It is entirely manual. It only gets written when a Work Item is opened and/or closed.

You don't have to choose between them or manage them directly. Just close things out, and the right filing happens.

A short reference, not a rulebook — plain language always works, but these reliably trigger the right behavior:

You'll know the ritual got skipped when you come back to a new conversation and Claude doesn't know about something real that happened before. When that happens:

"Why don't you know about X?"

That question is the safety net. You are the QA step in this system — not because you have to manage the paperwork, but because you're the only one who reliably notices when a report never got filed.

So you know what to expect when you ask for it — a proper close-out creates:

• A Work Item — the equivalent of the contractor's job file: why the work happened, what was done, what's still open, what was learned.
• A runtime log entry, for work that's operationally significant (deployments, infrastructure changes).
• A git commit, if files changed — but only when you ask for one; commits aren't automatic even during close-out.

You don't need to write any of this yourself. You need to ask for it.