Give the Machine the System

Chapter 04 was about discovering what is worth bringing into existence. This chapter is about the world that new thing must inhabit.

An imagined possibility becomes buildable only when it meets reality: the client’s systems, the users, the infrastructure, the permissions, the obligations, and the things that cannot be compromised. My central claim is simple.

The machine needs to understand the world it is building within.

A machine can propose almost anything. My responsibility is to establish what it is allowed to build, what it must work with, and what cannot be compromised. That sounds like restriction, but it reads better in practice: once the machine understands the environment, it stops proposing elaborate systems that cannot be deployed and starts exploring solutions that are actually useful. Constraints, stated clearly, improve creativity rather than merely limiting it.

Your idea meets reality

Every intention from the previous chapter arrives with an entourage of conditions. A reporting tool must run on the client’s existing Windows infrastructure. A document assistant must never send customer records to an unapproved provider. A workflow must respect permissions the client defined years ago and has no intention of renegotiating.

None of this diminishes the idea. It locates it. The gap between what I want to build and the environment it must inhabit is where some of the most instructive failures in my own work have happened — not in the code the machine writes, but in the world that code was never told about. I have repeatedly seen locally brilliant implementations turn out systemically wrong: correct against the request, incorrect against the reality. I offer that as observed experience, not a measured distribution of defect causes.

So before the machine chooses an implementation, I establish the reality. I think of that reality in four categories.

First, the environment: what already exists. Operating systems, frameworks, databases, legacy systems, networks, deployment infrastructure, APIs, and the body of existing code the new software must live alongside.

Second, the people: who this is for. What users need, what the client already owns, what knowledge I bring, and who will maintain the software after the machine has written it.

Third, the non-negotiables: what cannot be compromised. Security, personal data, access permissions, regulatory obligations, reliability, cost ceilings, approved technologies, contractual restrictions, and the human authority that governs consequential actions.

Fourth, the choices still available: where freedom remains. Which technologies can change, which components can be reused, what can be replaced, which trade-offs are permitted, and where the machine should explore alternatives. This last category matters most and is easiest to neglect. A thousand prohibitions with no room to manoeuvre does not produce a better solution; it produces a compliant mediocrity. I want the machine to see the boundaries and the open ground alike.

Elicit the non-negotiables

Some constraints announce themselves; the most dangerous ones do not. A client will usually state the obvious commercial terms, but security obligations, data-handling rules, and regulatory duties often surface only when asked directly — or worse, after they are violated. I elicit non-negotiables explicitly, from the people with authority to declare them, before the machine starts proposing architectures that assume them away.

The questions are direct. What must the software never do? Which data must never leave which boundary? Whose permission gates which action? What regulations apply, and who attests compliance? What reliability is contractually owed, and what happens if it is missed? What may the AI itself access during development — and what must it never see? For each answer I identify the accountable owner or the documented source: the client’s security officer, the contract clause, the regulation itself. Binding obligations do not evaporate when nobody has been named — a legal duty or a privacy restriction applies whether or not the project has worked out who administers it. What the missing owner changes is what I do next: an obligation without an identified authority is escalated, not interpreted as permission to proceed. When two constraints conflict — the client wants the cheapest hosting and the regulator wants domestic data residency — that conflict is resolved by human authority, recorded, and never silently traded off by the machine.

The operating rule follows: the machine must stop and report a conflict rather than reinterpret a non-negotiable — but an instruction is not an enforcement mechanism, and I do not treat it as one. Telling the machine that customer records must never reach an unapproved provider is good practice; the boundary itself must live in the machinery, not the prompt. Access to the data is granted through authorised sources only, provider routing is controlled outside the model’s discretion, credentials permit only what they permit, tool permissions are scoped, execution authority is separate from conversational willingness, and spending is capped by budgets the model cannot lift. The prompt states the rule so the machine can reason about it; the tools, credentials, policies, and approval mechanisms enforce the boundary independently of whether the model complies. Such mechanisms reduce and control risk — they do not make failure inconceivable, which is why defence runs in layers — but a boundary that lives only in a prompt is a request, not a control. Detailed governance architecture belongs to the later safety chapter; here the principle is enough: instructions guide, mechanisms bind. A machine that quietly widens its own permissions has not been creative; it has escaped supervision — which is why supervision must never rest on willingness alone.

Discover the existing system

Constraints cannot be declared from memory; they must be discovered. For a client project I work through the questions the machine will otherwise answer by guessing:

Area	The question for the developer and the machine
Data ownership and location	Where does the data live? Who owns it? Can it leave the client’s environment? How is it retained or deleted?
Identity and permissions	Who can do what? Which roles already exist? What must the new software never be able to access?
Existing investments	Which databases, services, APIs, licences, and tools has the client already paid for? Can they be reused?
Integration contracts	Which interfaces must the solution respect? Which schemas, limits, protocols, or workflows cannot change?
Deployment and operations	Who installs, updates, backs up, monitors, and repairs this system? Local, cloud, or private network?
Reliability and recovery	What happens when a service fails, an upgrade breaks compatibility, or data must be restored? Can the change be rolled back?
Commercial and legal boundaries	What licences, contracts, regulations, procurement limits, or support commitments apply?
Uncertainty and missing knowledge	What do we not know yet? Who can answer it? What should be investigated before designing anything?

I emphasise the last row deliberately. An unknown is not the same as an unconstrained decision. Suppose a client asks for an integration with its existing customer system, but nobody has explained that system’s permissions, data model, or API limits. The machine should not invent an integration architecture on assumptions and begin coding it. The correct action is to investigate the environment, document what is known, and mark which decisions cannot yet be made. Unknowns are tasks for research, not blanks for the machine to fill with confidence.

Discovery itself is a small discipline. I walk the repository rather than skimming its readme: the code shows what the documentation forgot to mention, and the tests show what behaviour someone once cared enough to pin down. I read schemas, interface definitions, and configuration with the same attention, because each is a contract the new software will inherit whether it knows it or not. I ask the system’s owners where the documents run out — nobody knows a legacy integration like the person who has nursed it through three upgrades. And I keep discovered facts visibly separate from working assumptions: a System Charter records the former, while the latter stay flagged as unknowns with a named investigator and a date. A fact without a source is an assumption that has stopped being honest about itself.

Preferences are not constraints

Chapter 02 recorded my preferences: PostgreSQL, Python, ZeroMQ, HTML, YAML. Those are starting choices, and they stand — until someone else’s reality overrules them. Suppose a client already runs its business on a different database and requires the new application to operate against it. My preference no longer determines the decision.

That does not require me to become an expert in their platform overnight. It means the project needs access to the appropriate knowledge — documentation, tools, examples, and verification — before I can responsibly direct implementation there. My own ability to supervise a technology is itself a legitimate constraint, and I state it plainly rather than pretending every platform is equally supervisable. Where my knowledge runs out, the charter must say so, and the configuration must compensate: stronger reasoning, specialist review, narrower work packages, or deliberate learning before delegation.

A simple classification keeps these apart:

Classification	Meaning	Example
Non-negotiable	Must be respected	Customer records never reach an unapproved provider
Existing reality	The solution must account for it	The client operates an established database
Preference	A starting choice, reconsiderable	Python for backend services
Open decision	The machine may explore alternatives	How to structure a new reporting view
Unknown	Investigate before committing	Whether the existing API supports the operation

This is more useful than handing the machine a technology stack. It tells the machine which decisions are already made, which it can help make, and which need further information or human authority. In particular, it gives the machine somewhere legitimate to be creative: the open decisions, where exploration is wanted rather than merely tolerated.

Explore the options that remain

Open ground is where the partnership pays. Within the boundaries, I want the machine proposing alternatives, comparing them honestly, and telling me where my preferences look like habit rather than judgement. A reporting view is genuinely open: the machine might suggest server-rendered pages for simplicity, a client-side cache for responsiveness, or precomputed summaries for scale — each with its costs stated, each revisable. My preference for familiar tools is the default, not the verdict; when the machine argues, with evidence, that a different choice serves the charter better, that argument gets a hearing.

Three kinds of work meet here, and they should not be confused. Where the machine explores, I judge: alternatives are welcome, decisions remain mine. Where my expertise matters most — the client’s domain, the unwritten rules of their operation, the trade-offs only a responsible human can weigh — I lead and the machine assists. And where neither of us knows enough, research comes before design: read the API documentation, probe the limits in a sandbox, ask the vendor, document the answer. An unknown investigated becomes either a new constraint or a new opening. An unknown assumed becomes a defect with a delay on it.

A real example: approval tied to the wrong thing

The clearest case I can document comes from ALIVE’s own source handling, reported on 5 November 2026 and verified against the repository, the implementation, and its tests.

The observed inconvenience was familiar: project approvals kept breaking. Ordinary development — modifying a file — invalidated previously approved sources, and work repeatedly stopped for renewed approval. A superficial fix would have removed checks or automated reapproval clicks. That would have treated the inconvenience while misunderstanding what the system was protecting: the owner’s authorisation to access a project is a security boundary, and dissolving it for convenience was never on the table.

The investigation found three facts bound to one immutable capture: a folder refresh created a new manifest, reads were re-verified against it, and an approval meant those exact bytes plus an expiry — so any change orphaned the approval even when the project and its scope were unchanged. That diagnosis came from reading the actual machinery — project and custody modules, workspace APIs, the dashboard’s refresh flow, the trust and permissions documents, and the existing tests that confirmed the old behaviour — not from theorising about approvals in general. The report names every file inspected, which is itself part of the method: the boundary you are about to redesign should be one you have walked, not one you have imagined. The redesign separated the durable fact from the changing one. A binding records the stable owner authorisation — project, scope, operations — while the current file revision flows beneath it as either a live folder or a pinned snapshot, each revision carrying a derived approval that is a record of use rather than a fresh owner decision.

Crucially, the security boundary survived intact in the paths the report inspected: explicit owner selection of the project root, canonical-path validation, symlink and traversal refusal, secret and ignore policies, scope checks on the reads examined, and revocation that stops future reads. The report is explicit that not every legacy source-consuming path was individually audited, so I make no claim of exhaustive coverage — what was verified is the central workspace path and the controls above, not every read path in every integration. Live mode confers no execution authority and expands no approved root. I describe this as an implemented, partially qualified redesign, not a finished solution: the central workspace path is live-aware, but legacy callers passing old approval references keep the old exact-revision behaviour; background indexing is best-effort; the migration was committed but unapplied at the time of the 5 November report, pending owner approval — its later deployment status is not inferred from that snapshot; and no full slow-suite, container, or paid-model qualification was claimed. Those limits are stated in the report itself.

The lesson is the chapter in miniature. The right solution emerged from understanding what the existing system was protecting, not from removing what annoyed the user. Had the machine been told only “stop asking me to reapprove”, it might have produced exactly the superficial fix — and narrowly written tests, aimed only at making the approval prompts disappear, might have confirmed the friction was gone without ever establishing that the authorisation boundary remained intact.

Give the machine the right context

With constraints established, the remaining question is what the machine gets to see. Here a confusion is common: access is not understanding. Permission to browse the entire web or read every client file does not make the machine wiser. It raises cost, buries the relevant material, and exposes information unnecessarily. What the machine needs is sufficient, accurate, authorised context for the task at hand: the relevant repositories, a map of the architecture, interface definitions, database schemas, configuration that governs behaviour, the tests that encode expectations, and the client’s own documentation.

Web research and broad source access are bounded operations, not default ones. Each excursion needs a reason, a scope, and attention to what may be disclosed, how relevant the material is likely to be, and what it costs in context and tokens. Neither whole-repository reading nor targeted retrieval is always superior; the strategy follows the task and the system’s complexity. A small, well-mapped codebase can be read whole. A large one must be navigated — which is itself a skill to verify, since a machine that cannot find the seams of a system cannot safely change it.

One test I apply before delegating consequential work: can the machine describe the system’s boundaries back to me — what it may touch, what it must preserve, and where it must stop and ask — with references to the actual files, documented interfaces, database structures, and permission policies that support each claim? A fluent summary is not enough; fluency is cheap and grounding is the test. If important claims cannot be grounded, they remain assumptions or unknowns requiring investigation, and the System Charter records them as such rather than as verified constraints. If the machine cannot do this at all, the context is incomplete however large it was.

The System Charter

I record all of this in a short, durable System Charter: the target environment, client needs, existing components, non-negotiables, permitted choices, unknowns, authorised sources, and what acceptance requires. Each entry carries its standing: verified against a named source, or assumed and awaiting investigation. The charter is the project’s shared picture of its world, with the uncertain parts labelled as uncertain. Consider a hypothetical client integration — invented to show the shape of the document, not drawn from any engagement of mine:

System Charter field	Example
What we are building	Internal reporting interface
Who it is for	Sales managers and authorised staff
Existing system	The client’s established customer system
Target environment	Existing Windows infrastructure
Existing integration	Approved customer-system API
Non-negotiable	Preserve existing user permissions
Data boundary	No live customer records sent to unapproved providers
Cost restriction	No additional commercial licences without approval
Our preference	Python and HTML where compatible
Open design choice	Reporting view and caching strategy
Unknown	API capabilities and limits — investigate first
AI access	Approved documentation, sanitised fixtures, selected code
Acceptance	Demonstrate permission enforcement, correct reports, deployment compatibility

The table alone is not the mechanism. The instruction around it is: the machine may examine the options, propose within the open ground, and challenge my preferences with reasons — but it must stop and report a conflict rather than silently violate a non-negotiable, and it must treat an unknown as a question, never as permission to assume. Human approval governs consequential boundary changes, and the charter is updated when such a change is agreed, so the next task starts from the revised world.

I use the charter the way I use the Foundation Charter: as the standard against which proposals are judged. When the machine suggests a new reporting cache, the question is not whether caching is clever but whether it respects the permission model, the data boundary, and the cost restriction — and if it needs an unknown answered first, the proposal says which one. A proposal that cannot show its working against the charter is not ready, however elegant its architecture. Over time the charter becomes the project’s memory of its own world: what was true, what was decided, what is still open, and who is responsible for each.

The conditions of success

There is a philosophy in this worth stating plainly. Constraints are not the machine’s limitations; they are the conditions under which it must succeed. An unfamiliar platform limits my supervision, not necessarily the machine’s ability to produce working software — with stronger reasoning, specialist review, and narrower delegation, the unfamiliar becomes manageable. A client’s required system changes the available solutions, not the worth of the original idea. A data boundary changes model access and testing arrangements, not the underlying goal.

That is what separates this chapter from the last. Chapter 04 asked what could exist. This chapter asks what is possible and permissible in the real environment — and hands the machine a world it can actually build within, with the freedom marked as clearly as the walls.

With intention discovered and the world established, the next step is to divide the work itself into pieces a machine can be trusted to perform. That is the subject of The Work Package.