With Intention

Most software gets built by inertia. Features accumulate because someone asked, commits pile up because work happened, and the product slowly becomes whatever the last decision pointed it toward. There is no malice in this — it is just what happens when you build without a spine.

Building with intention means the opposite: every project has a one-line directional statement before any code or business plan exists. The practice is not aesthetic — it is operational. It catches drift before drift compounds. The artifacts that carry intention are visible: they live in the code repos, in a personal wiki maintained by the AI, in the procedures that run daily. This page is about those artifacts and how they work in practice.

What the practice looks like, concretely

Intention without artifacts is just a mood. The artifacts are what make it operational — persistent across sessions, readable by anyone (or any AI agent) picking up the work, immune to the natural amnesia of building.

• Northstars

  Every project starts with a single sentence that names what the project is for — not a feature list, not a value proposition, not a marketing tagline. A directional statement that survives changes within its scope — features shift, tactics shift, the Northstar holds. A whole-company pivot earns a new Northstar, built from everything the old one taught. You steer toward it; you never arrive at it.

  TradeTi.me's product Northstar, confirmed after several attempts that all felt slightly off: "Help anyone, anywhere, understand the rhythm of global markets at a glance in their local time." The wording matters. Earlier candidates were value-props dressed as Northstars — describing what the user gets, not what the world becomes. The test for a real Northstar is whether it lets you say no: any feature that doesn't make global market rhythm more legible in local time is out.

  The origin of TradeTi.me captures what a Northstar is actually for: "I made this project because I had a problem I didn't get solved any other way. I am the market research in that way — I'm the person who needs this. If I had the problem, others probably have it too." The Northstar formalizes that intuition into something durable enough to hand off.

• Constitutions

  A Northstar is one sentence. A Constitution is the multi-section document that translates that sentence into operational guidance — specifications, decision rules, worked examples of what fits and what doesn't. It is written primarily for AI agents, which re-read it on every turn and need precision rather than poetry. But it also orients any human who picks up the project months later.

  The distinction matters: the Northstar stays still; the Constitution evolves with the product. Confusing them produces either rigid projects (the Northstar becomes a detailed spec that can't adapt) or directionless projects (the Constitution gets treated as the anchor, no operational guidance drifts). The wiki is the context — the body of work the AI reads from. The Constitution is separate: a file the AI re-reads on every turn, covering ingest procedures, voice discipline, sub-agent rules. It wasn't designed as a Constitution; it became one through use.

• Decisions with reasoning

  Every load-bearing decision gets logged with the alternatives considered and why this one won. Not just the outcome — the reasoning. The reasoning evaporates faster than the choice. Six months later, the choice is in the code; the reasoning that produced it is gone unless it was captured.

  TradeTi.me's decisions log includes the confirmed Northstar wording, the decision to scope the morning momentum window to NYSE and NASDAQ only (and why not Tokyo, Hong Kong, or Seoul — different microstructure, different rules), the call to formalize the wiki's instructions file as a Constitution in its own right. Each entry names alternatives considered, why this path won, and what would reopen the decision. The log is an append-only record of closed epistemic states.

• Questions

  Fundamental questions get tracked separately from decisions. They outlive methods. A question like "what does it mean for global market rhythm to be universally legible?" is not a task to close — it is a standing interrogation that shapes every design choice. Settling a question moves it to the decisions log; the questions list is what's still open.

  The discipline is the distinction: decisions are closed epistemic states; questions are open ones. Mixing them produces a log full of pseudo-decisions that get relitigated constantly, because the question underneath was never actually engaged.

• The wiki

  A personal LLM wiki — the pattern Andrej Karpathy published in April 2026, where the AI maintains a structured, interlinked collection of markdown files alongside you. "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase." Not Wikipedia (collaborative, public); not RAG (re-derived on every query). The AI builds it incrementally as you work — every concept gets a page, every decision gets logged, every cross-reference gets made. When I encounter the same problem twice, I write a page; on the third encounter, the page is already there.

  Every wiki page carries a version number in its frontmatter — an integer, bumped on every edit. The current Northstar page is at v5; the TradeTi.me project page is at v21. When you can see that a page has been touched twenty-one times, you read it differently. You know it has been argued with, corrected, and refined across real work. The version number is a trust signal, not a formality.

  The rule is mechanical: every edit bumps the integer, updates the date. Sub-30-second discipline. It compounds into something useful: a record of which pages are live and working, which are stubs, and which have accumulated enough iteration to be trusted.

• Standard Operating Procedures

  Recurring multi-step operations get written down. Not because the steps are complicated, but because humans skip steps under load, and AI agents drift toward training-data defaults without explicit constraints. A pre-commit checklist runs before every git commit on TradeTi.me's code repo. A reply-quality checklist runs before every marketing reply gets shipped. Both went through multiple same-day iterations when running them surfaced failure modes the first draft didn't catch.

  The iteration discipline is the point: an SOP that never changes is a dead document. Every failure that wasn't caught by an existing gate either adds a new gate or strengthens a weak one. The SOP is how accumulated learning persists across sessions and across the inevitable entropy of working fast.

Why this matters more now

Work happens inside complex adaptive systems — markets, organizations, software ecosystems — where outcomes emerge from the interactions of many agents, no one of which controls the whole. You can't direct such systems; you can only orient them. A Northstar is exactly what the name says: a fixed direction to steer towards — the way sailors steer towards Polaris. You orient by it; you never arrive.

It is very useful when people work together to have an understanding of where everybody is aligned. If you include an AI as well — which also has a tendency to drift — then a Northstar becomes essential, if you don't want to be constantly monitoring the AI and you want it to do more agentic work on its own.

The same problem appears at civilizational scale: any system steered through filtered reports drifts toward serving the report-makers. My company is the micro version. The discipline scales because the underlying problem — many agents, no single controller, drift as the default — is the same at every level.

How this changes the work

The downstream consequence of these artifacts is not tidiness. It is speed, because most decisions are already made. When a feature proposal arrives, the test is mechanical: does it serve the Northstar? Does it match the Constitution's worked examples of what fits? Has a similar decision been logged? Usually the answer is obvious once you look. The artifact does the work; the decision doesn't have to be re-derived.

The deeper consequence is in how the work gets verified. There is a discipline I try to follow: never reason about what the product does from memory or from the spec alone. Look at the actual built thing.

"It's usually how it goes — you make something, you see what comes out of the specifications, something is not completely right, and because you can see it in front of you it's much easier to find out what to change and how to change it and why. The code becomes the ground truth. The seeing part — being able to experience it — that makes such a big difference."

— From the substrate notes, 2026

The spec is intent; the code is reality. The gap between them is only visible by looking at the actual artifact — opening the page, clicking the buttons, reading the files. This came into focus concretely when a review pass on TradeTi.me's UI documentation produced two "corrections" that turned out to be wrong: the wiki spec had drifted from the shipped code, and the corrections would have moved the code away from what was actually there. The seeing step — reading the actual source files — was what caught it. The discipline now: when spec and code disagree, code wins. The spec gets updated to match reality, not the reverse.

This is also why working in public matters. The version numbers visible on the wiki pages, the stream entries that show what shipped and when, the Northstars and decisions logs visible to anyone who looks — they create accountability to what was actually built, not to what was planned to be built. There is no place to hide the gap between intention and artifact when both are visible.

Why this is cheaper than the alternative

There is a tempting way to frame this practice as discipline or rigor — something admirable but costly. That framing gets it backwards. The cost is in building without intention: features that drift from the Northstar, decisions that get made twice because the reasoning wasn't captured, procedures that have to be re-derived every time because they were never written down, code that the spec can't accurately describe because nobody looked at what was actually there.

The artifacts are not overhead. They are what make delegation possible — to AI agents, to future sessions, to anyone who picks up the work. Every hour of delegated work that produces the right output is an hour not spent debugging drift. The Northstar is the substrate that makes delegated execution intent-correct. The decisions log is the substrate that prevents relitigating settled questions. The SOPs are the substrate that carries hard-won execution knowledge across the inevitable entropy of working fast.