NORTH.md Specification

1North StarCopy

A single sentence declaring the destination. Not the roadmap. Not the next quarter. The destination.

A well-formed North Star is:

• Specific enough to disqualify alternatives. "Be the best ERP" is not a North Star. "Replace spreadsheet bookkeeping for European freelancers by 2030" is.
• Ambitious enough to be uncomfortable. If the North Star feels safe, it is not a North Star.
• Reachable in principle. A North Star is not a fantasy. It is a destination that justifies hard choices.

Example. Arkwell makes a one-day month-end close the norm for European small manufacturers by 2030.

2The BarCopy

The quality threshold that distinguishes "shipped" from "started". Defines what work is acceptable to call done.

A well-formed Bar is:

• Measurable or observable. "High quality" is not a Bar. "p95 latency under 200ms, zero type errors in CI, accessibility AA on every page" is.
• Higher than industry default. A Bar at industry average is no Bar at all.
• Defended by gates. Items in the Bar SHOULD map to enforcement: CI checks, linters, review rules, runbooks.

Example. Every shipped feature passes: typecheck, lint, full test suite, Lighthouse ≥95 on all metrics, WCAG AA via axe, and i18n parity across every supported locale. No exceptions, no "TODO: tests later".

3Asymmetric BetsCopy

The places where we deliberately invest 10x effort, and the places where 1.1x is correct.

A well-formed Asymmetric Bets section names both sides:

• Where we go big. What deserves disproportionate investment because it is load-bearing or strategically decisive.
• Where we deliberately ship medium. What is fine at 80% so we can spend the remaining capacity on the bets.

This section prevents two failure modes: over-investing in commodity work, and under-investing in the work that compounds.

Example. Go 10x on: stock-to-ledger reconciliation, e-invoicing correctness, migration from the incumbent system. Accept 1.1x on: admin settings UI, dashboard polish, internal reports.

4Anti-GoalsCopy

The things we explicitly refuse to do, even when they would be easy or profitable in the short term. Anti-Goals are how we say no without re-deciding every week.

A well-formed Anti-Goal is:

• Tempting. If no one would ever ask for it, it is not an Anti-Goal.
• Justified. A one-line reason that survives pushback.
• Specific. Not "we don't do sloppy work", but "we don't ship features that require external accountant review before use".

Example. We do not build a CRM module. (Mature CRMs exist; we integrate, we don't rebuild.) We do not support on-prem deployment. (Distracts from cloud-first product velocity.) We do not accept feature requests with no documented user pain. (Roadmap is pull-based, not push-based.)

5Trade-off DefaultsCopy

Decisions that have already been made about common trade-offs, written down once so they are not re-debated each sprint.

Cover the trade-offs that come up repeatedly in your domain. Common pairs:

• Speed vs. safety
• Breadth vs. depth
• Build vs. buy
• Generality vs. fit
• Backward compatibility vs. clean design
• Single-tenant vs. multi-tenant

For each: name the default, and name the conditions under which the default flips.

Example. Default: speed over safety on internal tooling, safety over speed on fiscal code. Flips: any code touching e-invoicing or payroll must pass the safety default regardless of internal-vs-external scope.

6Ambition TriggersCopy

Phrases — used by humans and quoted in AI agent prompts — that escalate scope when the team is thinking too small.

A well-formed Ambition Trigger:

• Is short enough to remember.
• Forces a specific reframe. Not "be ambitious", but "what would the 10x version look like".
• Is allowed to be answered with 'this is the 10x version'.

Examples. "Is there a 10x version of this?" "What would [reference team] ship here?" "If we had three weeks instead of three days, what would change?" "What's the version of this that ends up in the keynote demo?"

7ReversibilityCopy

A map of which decisions are one-way doors (expensive to reverse) and which are two-way doors (cheap to reverse). One-way doors deserve deliberation. Two-way doors deserve speed.

A well-formed Reversibility section lists:

• One-way doors in this project. Database schema changes in production, public API contracts, brand identity, fiscal calculation logic, security boundaries.
• Two-way doors in this project. UI copy, internal tool layout, code structure, dependency choices on internal tools.
• The default disposition. Which kind of door to assume when in doubt.

Example. One-way doors: e-invoice signature format, public API response shape, domain name choice. Two-way doors: internal admin UI, dependency on a given OSS library, non-public code organisation. When in doubt: treat as two-way and move.