Obsidian AI Labs

How Your Digital
Worker Thinks

A prompt is a wish. An algorithm is a plan.
obsidianailabs.ca
The problem with chat

One prompt in. One answer out.

That works for a question. It falls apart the moment the job has steps, and real work always has steps.

The first rule

The process is always on.

There is no mode to remember to switch on. The only question is how much effort the work has earned.

Effort scales to the job

Five gears.

E1A greeting. Seconds.
E2One fact, one edit, one command.
E3Substantial work in one area.
E4The default for real work. Anything multi step.
E5Architecture, or anything that has to be exactly right.
What every job actually is

Current state to ideal state.

Shipping code, writing a policy, planning a quarter. Same move every time. The hard part is saying precisely what ideal means.

The document that runs the job

Done gets written down before work starts.

Problem, vision, what is out of scope, constraints, the goal, and the criteria. It is the spec, the test plan, and the definition of finished, in one file.

Where it lives

It belongs to the thing, not the conversation.

A real project

Lives in the project

An app, a tool, a system. The file sits with it and grows across every task that touches it.

One off work

Lives with the task

An investigation, a single fix. Created at the start, archived when it is done.

How done gets defined

Split it until one criterion is one check.

If you cannot name the thing that answers yes or no, it is not a criterion yet.
When to split

Three tells.

AndIt joins two separate things. Split it.
EitherOne half can pass while the other fails. Split it.
AllWords like every or complete are hiding a list. Write the list.

A vague criterion is how work gets called finished when it is not.

Harder work, more proof

The bar rises with the gear.

E2At least 16 criteria
E3At least 32
E4At least 128
E5At least 256

Not busywork. A big job has more ways to be quietly wrong.

The run

Seven phases, every time.

1
Observe
What is actually being asked
2
Think
Where this could go wrong
3
Plan
Approach and order
4
Build
Make the thing
5
Execute
Run it for real
6
Verify
Prove each criterion
7
Learn
Feed it back in
No credit for naming it

Choosing a method is a promise to run it.

Saying a job needs deeper analysis and then not doing the analysis is worse than skipping it. Claimed and not run counts as a failure, not a shortcut.

The rule that matters most

Verify the outcome, not the action.

A command that returns success is not proof the thing exists.

Web pageOpen it and look at it
EndpointCall it and read the response
A fileRead it back
A deployCheck what is live, not that the upload worked
Gate one

If we built a tool, it ships with a test.

Written from what the tool really does, never hand guessed. A test loosened until it passes is not a test.

Gate two

If it runs unattended, it carries its own alarm.

DetectA health check notices when it breaks or goes stale
RouteIt reaches a human and the worker, not just a log file
FixThe worker repairs it without being asked, then reports

Anything durable should tell you when it dies, instead of dying quietly.

It is not frozen

The definition of done gets sharper as we learn.

Criteria split, goals tighten, dead ends get written down so nobody walks into them twice.

The bar

Good enough is not the target.

Euphoric surprise.

An answer you could not have predicted, and recognise as right the second you see it.

This is what runs our company.

Not a demo. The same process every day, on our own work, before it goes near yours.

See what one could do for you