> Business context for an agent working on commercial software — from The Handover, the-handover.org/docs/business-context > Authors: Leon Mallett (captivated.online) with Claude Code · Last confirmed working: 2026-08-14 > © Captivated Ltd — free to use in your own work, not to redistribute as a collection. the-handover.org/licence Commercial context for work on this codebase. Everything here is a fact an agent **cannot read from the repository**, and each one changes decisions that otherwise look purely technical. ## Why this file exists An agent without commercial context makes locally sensible choices that are commercially wrong, and does so confidently, because nothing in the code contradicts them: - Adding a dependency whose licence prohibits the commercial use this software is sold under. The build passes. The problem surfaces at an acquisition, a client security review, or never — which is worse. - Writing a commit message, issue or comment that discloses something not yet public. - Simplifying away a constraint that exists for a regulatory reason nobody wrote down. - Changing behaviour that a published page, a contract or a support commitment promises will work a particular way. None of these are code-quality failures, so no amount of care about the code prevents them. ## The constants **Owner:** {{legal_entity}}. Copyright, licence grants and any contractual commitment belong to this entity. Use its exact registered form in licence headers, notices and anything with legal effect — an approximation is worse than a placeholder, because it looks deliberate. **Jurisdiction:** {{jurisdiction}}. This determines which consumer protection, data protection, advertising and tax rules apply. When a question touches any of those, reason from this jurisdiction rather than the one most represented in training data — the differences are substantive, and the confident answer is frequently the wrong-country answer. **Default visibility:** {{default_visibility}}. Apply that default to everything an agent produces, not only to source: commit messages, branch names, issue text, code comments, error strings, test fixtures and documentation. A private repository is not a guarantee of privacy — it gets shared with contractors, attached to due diligence, or opened later — and the cost of a leaked detail is not recoverable by deleting it afterwards. ## Licensing obligations run in both directions **Inbound.** Every dependency carries terms. Before adding one, check the licence is compatible with how this software is distributed and charged for. Copyleft terms that would extend to the whole work are the ones that matter most and are easiest to miss, because the package installs identically either way. Record what was added and under what terms in the project's licensing documentation. **Outbound.** How this software is licensed to others is a commercial decision with legal effect, not a file to tidy. Do not add, change or remove a licence file, a licence header or a copyright notice without an explicit instruction. If one looks wrong, say so rather than fixing it. ## What is not in this file Project-specific commercial detail — pricing, channels, revenue stage, launch plans — belongs in **that project's own documentation**, not here. This file covers what is true across everything the entity owns; a single project's commercial position changes on its own schedule and would go stale here while looking authoritative. If a project has a commercial dimension, expect that detail in its documentation set. If it is absent, ask rather than assume the project is non-commercial. ## Decisions that need a human These are not judgement calls an agent should make alone, however clear the answer looks: - **Anything with legal effect** — licence changes, terms, privacy notices, contractual language, claims about compliance. - **Anything that changes what a customer pays or receives** — pricing, limits, entitlements, what a tier includes. - **Anything published under the entity's name** — public pages, release notes, announcements, support responses. - **Anything that contradicts an existing public commitment**, including quietly. If a page says a feature works a certain way, changing the behaviour is a commitment change, not a bug fix. - **Adding a dependency**, which is a licensing and supply-chain decision as much as a technical one. The pattern: an agent may **prepare** any of these, and should. It should not **enact** them. Preparing a well-argued change and leaving the decision is the useful contribution. ## Public commitments are constraints Anything stated publicly — a feature list, a support promise, a privacy claim, a pricing page — is a constraint on the code, and one the code does not express. Where behaviour is load-bearing for a public commitment, that belongs in the project's decision log with a note saying so, precisely because it will otherwise look like an arbitrary implementation detail to whoever refactors it next. Treat "this seems unnecessary" about anything touching billing, entitlements, data retention or user-facing guarantees as a question rather than a finding. ## For the agent working here - **Read this before reasoning about anything commercial**, and say when a request runs into one of the above rather than proceeding and mentioning it afterwards. - **Prefer asking to assuming.** Commercial facts are cheap to ask about and expensive to guess. - **Flag, do not fix**, anything in the licensing, legal or public-commitment categories. - **Assume the default visibility applies** to whatever you are writing right now, including this sentence's equivalent in a commit message.