AI Guides · Natthan.AI Lab
The 16 Architectural Boundaries for AI Systems
What you'll be able to do
You can sort your own system's boundaries into wired or written and write a forbidden-action test for each, using the lab's IP gate as the example.
A boundary is a limit enforced in code, independent of a prompt, as the lab's rule to bound capabilities, not behavior requires. Use the sixteen below to find where your system stops an action, following the same distinction the constitution account makes between enforced rules and written ones.
Last updated
Read the status before trusting the rule
Use gate for a checkpoint with authority to stop work. Name its enforcement point, the exact place in the action path where that stop happens. For Bizzy's IP boundary, put “pre-commit check” in that field.
Mark a limit wired when code enforces it on the action path. Mark it written when it remains a stated rule with no demonstrated gate. Follow the constitution's unfinished wiring: “I am wiring each one to a gate.” Keep every unproven part of a broader boundary written even when a narrower check is wired.
Read Under the hood at the level of the named check. Use its Proven label for machinery running in the lab; use Building for code still being armed across the fleet. Treat Live as product use and inspect each item under Mixed before assigning a boundary's status.
1. List what your tools let an agent do
Open the tool definitions for your equivalent of Bizzy, the owner agent responsible for agency delivery. List callable actions rather than job titles: write a client file; commit it; promote the change. Include direct shell access if that can reach the same files.
Trace each action's destination against Bizzy's client-code limit on the Example team. Label internal org files separately from client-owned code before deciding which tool may move either. Add the bus, the shared message log, if the job can post a handoff there.
2. Name the boundary and its enforcement point
Match each action to a numbered boundary below. Put Bizzy's commit under boundary 14 and name the pre-commit IP check as its enforcement point. Keep a direct export tool under boundary 13 until its own permission check is demonstrated.
Map a heartbeat, a scheduled run that checks for due work, to boundary 12. Identify the work-due gate, the check that exits before a paid model call when nothing is due, in the Example team's runners. Write “no gate demonstrated” beside an action backed only by the constitution.
3. Attempt the forbidden action and record the stop
Run the relevant test below on an isolated copy with synthetic data and external effects disabled. Keep the action path intact: exercise the commit hook through a commit, as the Bizzy example requires. Save a receipt, evidence from the observed result, with the attempted action and the state after rejection.
Use the safety check reported armed while unwired as your failing case. Disconnect your test check deliberately and confirm the exercise exposes the forbidden action getting through. Reconnect it and repeat the attempt; then run an allowed control through the same path.
The sixteen boundaries
Use these original numbers when linking a rule to a test. Read each wired label only within its named scope; keep the rest written. Run these tests on your copy; keep their expected results separate from the lab's published outcomes.
01 / Architectural boundaries
The Agent Runtime Boundary
Keep model calls and execution state inside a runtime that business code can reach only through a typed interface, including Bizzy's build jobs.
Lab status: Written, not yet wired. Use the factory's gated pipeline as evidence of controlled job execution; it does not establish that business code cannot import a model SDK.
Under the hood: Autonomous execution factory
Test on a copy. Add a direct model-SDK import to a business module in a test copy of a Bizzy-style build. Expect the dependency check to reject it before execution; leave this boundary written if the import passes.
02 / Architectural boundaries
The Model Abstraction Layer
Confine provider-specific types to model adapters so a change of reviewer model cannot require changes to business rules.
Lab status: Written, not yet wired. Read the held-release account as evidence of review by a different model family; it does not prove a shared model interface or enforced routing contract.
The held release and the reviewer's disputed findings
Test on a copy. Return a provider-specific response directly to business code in a test build. Require the interface check to reject it; then substitute another adapter without editing the business rule.
03 / Architectural boundaries
The Pure Domain Layer
Keep a rule such as Freya's merged-consent decision in one pure function, with source data passed in and no network access inside it.
Lab status: Written, not yet wired. Use the 250-reachable audience repair to identify the consent rule; keep pure-domain enforcement unproven until a dependency check is demonstrated.
The audience tool that checked only one consent source
Test on a copy. Insert a network read into the consent function in a test copy. Expect a dependency check to stop that change, then run the merged-source cases without network access.
04 / Architectural boundaries
Persistence with Typed Accessors
Put scoped data reads and writes behind typed repository functions so an audience tool cannot issue arbitrary customer queries.
Lab status: Written, not yet wired. Keep this written: the Data and growth engine is Mixed, and its customer data platform is Building; neither label proves tenant-safe accessors.
Under the hood: Data and growth engine
Test on a copy. Attempt an audience read without tenant scope against a test repository containing synthetic contacts. Require rejection before any records return, and try the raw-query path the agent could otherwise reach.
05 / Architectural boundaries
The Domain Plugin Architecture
Keep each business's rules behind a versioned plugin contract instead of branching on names such as Freya or Bizzy inside platform code.
Lab status: Written, not yet wired. Use the product roster to choose separate business cases; a Live product does not establish that a plugin contract enforces their separation.
Under the hood: Product systems
Test on a copy. Register a test plugin that omits a required operation or declares an incompatible contract version. Expect registration to fail before a Freya-style job can dispatch to it.
06 / Architectural boundaries
The Context Assembly Pipeline
Give one pipeline control of model inputs and their budgets, with a replayable source record that would expose missing legacy consent.
Lab status: Written, not yet wired. Use the audience's missing source as the failure case; wiki brains marked Proven do not establish enforced context budgets or replayable model inputs.
Under the hood: Knowledge and brain
Test on a copy. Withhold legacy consent from a test audience request whose required-source list names both systems. Expect assembly to reject the incomplete input; also attempt an over-budget input and inspect the recorded exclusion.
07 / Architectural boundaries
The Evaluation Infrastructure
Gate model changes on versioned evaluation cases and regression limits, including failures from the lab's accounts.
Lab status: Written, not yet wired. Credit the rendered-page check added after 463 tests missed a blank site. Keep the broader model-evaluation boundary written: that repair does not establish a regression gate for every model change.
463 passing tests over a blank website
Test on a copy. Make a candidate return an audience decision that drops legacy consent in a quarantined evaluation case. Attempt its promotion with the regression present and require the evaluation gate to block it.
08 / Architectural boundaries
Decision Interface Contracts
Require typed decisions with linked evidence before downstream code acts on a claim like the lab's signed completion reports.
Lab status: Written, not yet wired. Credit the receipt-forgery check for rejecting a signed false claim. Keep the full decision contract written until schema rejection and versioned decision storage are shown too.
The receipt gate's forgery attempts
Test on a copy. Submit a completion decision with its evidence field missing through a test action path. Expect schema rejection, then submit a correctly signed false claim and require an independent result check to stop it.
09 / Architectural boundaries
The Agent Communication Protocol
Persist handoffs outside the conversation and link typed replies to their requests so a bus notification failure cannot erase the work.
Lab status: Wired for durable bus storage. Use the twelve-hour notifier outage as the demonstrated scope: the stored backlog survived and could be read directly. Keep typed-message validation and request correlation written until their gates are shown.
The twelve-hour notifier outage with an intact backlog
Test on a copy. Stop notification on a test bus and restart the recipient after posting a handoff. Require the handoff to remain readable; then submit a reply without a request ID and require rejection to test the still-written protocol contract.
10 / Architectural boundaries
Feedback Loop Infrastructure
Link each decision to its observed outcome before feeding it into evaluations, preserving corrections such as the audience repair.
Lab status: Written, not yet wired. Credit the Live bug bank for retaining defects and their tests. Keep this broader boundary written until outcome linkage and controlled evaluation intake are demonstrated.
Under the hood: Observability and assurance
Test on a copy. Submit an audience correction with no originating decision ID to a test feedback pipeline. Require intake to reject it; then link the correction and check that the original wrong decision remains inspectable.
11 / Architectural boundaries
The External System Boundary
Put external actions behind typed adapters that own credentials and prevent duplicate effects, including an audience send after a timeout.
Lab status: Written, not yet wired. Use the repaired audience tool to define valid consent inputs. Its account does not establish credential isolation or retry protection for the external send.
The audience repair before a campaign send
Test on a copy. Send to a fake mail service that records acceptance but returns a timeout. Retry the same test request and require a single recorded send; also attempt direct service access with the agent's credentials and expect denial.
12 / Architectural boundaries
The Async Orchestration Layer
Admit queued work through explicit execution limits, with durable job status and bounded retries, starting with the lab's work-due and repo-lease checks.
Lab status: Wired for runner admission. Use the Example team's no-work exit and held-lease skip as the enforced scope. Keep the full deadline and retry contract written where the record does not show a gate.
Example team: scheduled runners and repo leases
Test on a copy. Fire a test runner with nothing due and require an exit before a paid model call. Queue a build while another test worker holds its repo lease and require it to skip without touching files. Test the still-written deadline contract by submitting an expired job and requiring rejection before dispatch.
13 / Architectural boundaries
The Tool Exposure Layer
Validate scope inside each tool invocation so a direct call cannot bypass the same boundary Bizzy's IP gate enforces at commit time.
Lab status: Written, not yet wired. Credit Bizzy's commit-time check for client-code isolation. Keep a universal permission check inside every tool written; the capability catalog does not prove it.
Under the hood: Capability catalog and router
Test on a copy. Call a client-file export tool directly with a harmless fixture classified as internal org material. Expect the tool to reject it before export; a later commit rejection alone does not pass this test.
14 / Architectural boundaries
Build-Time vs Runtime Generation
Gate generated code before it enters a release, as Bizzy's client commits do, and validate live model output at the action it requests.
Lab status: Wired for client-code commits. Use the factory's IP isolation check and Bizzy's Example team entry for the code side. Keep the broader separation of runtime checks written wherever no enforcing path is shown.
Under the hood: IP isolation membrane
Test on a copy. Stage a harmless internal-org fixture in a test client repository and attempt the commit. Require the IP gate to reject it; separately submit an invalid live decision and require runtime rejection even when the code that produced it passed review.
15 / Architectural boundaries
Cross-Cutting Concerns
Give shared controls one maintained interface so a change to logging or configuration cannot silently disconnect a check like the lab's lie-detector.
Lab status: Written, not yet wired. Use the disconnected-checker account to locate the real reporting path. A repaired connection does not prove canonical interfaces for all shared controls.
The lie-detector that was built but disconnected
Test on a copy. Introduce a second status-reporting path in a test copy that skips the shared verifier. Submit an unsupported completion through it and require rejection; a passing standalone verifier test is insufficient.
16 / Architectural boundaries
Access Surface Convergence
Route every interface through the same authorized operation so a command cannot bypass the proof required by the lab's completion check.
Lab status: Written, not yet wired. Use the Proven Control surface as evidence of available interfaces. It does not demonstrate that every interface reaches the same enforcement point.
Under the hood: Control surface
Test on a copy. Attempt the same unsupported completion through each interface your test system exposes. Require the shared operation to reject every attempt, then trace each rejection to that operation.
Worked example
Bizzy's IP gate at commit time
I give Bizzy client delivery with an IP limit: internal org files stay out of client code. Use Bizzy's Example team entry and the factory's IP isolation membrane as the record for that gate. Replay it as follows; the site does not publish a captured IP rejection or test receipt for this example.
- Boundary. Keep internal org material out of the client's repository. Apply boundary 14 to the generated code entering that repository.
- Enforcement point. Put the IP check in the pre-commit path, matching Bizzy's recorded gate. Retain that hook in the isolated client-repository copy used for this exercise.
- Attempted violation. Stage a harmless fixture that matches an internal-org classification in your gate's rules. Attempt a normal commit with that fixture included. Keep real internal files out of the exercise.
- Expected stop. Require the hook to reject the commit because of the fixture. Inspect the repository's commit history to confirm the attempted commit was not created. Remove the fixture and require an allowed client-only change to pass the same hook.
- Receipt to collect. Save the rejected commit's output with the unchanged commit ID, then attach the allowed control's result. Label these as your test results; keep the Example team entry as the source for the lab's mechanism, rather than presenting it as a test log.
Test a direct file export separately under boundary 13 if your agent can perform one. Keep the IP result scoped to committing client code; it does not establish that every way out of the repository is guarded.
Mistakes to avoid
- A test that bypasses the action path. Trace an actual completion through its verifier before accepting the verifier's unit tests. Use the lie-detector left disconnected to challenge that wiring.
- A gate that protects the wrong rule. Give the consent test a legacy-only opt-in and a cross-source opt-out conflict. Require both to follow the repaired rule in the 250-reachable audience account; blocking almost everyone did not make the original tool correct.
- A notification check standing in for storage. Read a test handoff from the bus after stopping notification. Keep that result separate from delivery, using the twelve-hour notifier outage as the case where unread work remained intact.
- A green suite used as release evidence. Carry the blank-site account's rendered-page check into your release test. Require visible output with the deployed security settings active before accepting the page result.
Ten minutes, today
Pick one action your agent can take and find its boundary in the reference. Write its test using Bizzy's commit attempt as the pattern, replacing the brackets with your own action.
Boundary: [number and the forbidden action]
Enforcement point: [exact tool or hook that must reject it]
Test: on an isolated copy, attempt [forbidden action] through [normal entry point].
Expected stop: [rejection output], with [protected state] unchanged.
Allowed control: [permitted action] must pass the same check.
Receipt: [where you will save both observed results]
Status: written until this action path demonstrates the stop.
Leave a missing enforcement point explicit, following the constitution's wiring list. Save the test beside the job that will add that gate. Mark only the tested scope wired after you observe its rejection and allowed control.
Frequently asked questions
Are all sixteen boundaries wired in the lab?
Keep each status scoped to the check named here. I can point to durable bus storage and runner admission, along with Bizzy's IP gate; those do not prove the rest of their architectural contracts. Use the constitution account's written rules as unfinished work until an enforcing path is demonstrated.
Read the constitution's distinction between written and enforced
Does Proven under Under the hood mean every related boundary is wired?
Read Proven as running in the lab today. Building means code that is not armed across the whole fleet; Live describes a product with real use. Inspect the individual entries under Mixed. Keep a specific boundary written when those labels do not establish its check, as with the customer data platform and tenant-scoped accessors.
Does the lab require an outside model to approve every change?
I use an out-of-family reviewer, a reviewer from a different model family, on demand for high-stakes changes. Keep that practice separate from a machine gate on every change. Use the held-release account to test a disputed verdict too: the outside reviewer reported build failures that the builders could not reproduce in clean runs.
What evidence should I save from a boundary test?
Save the forbidden request with the rejecting check's output and the resulting state. Add an allowed control request so a checker that rejects everything cannot pass. Use the receipt-forgery account's genuine control as the model; a valid signature still needed comparison with the observed work. The lab's existing push receipts use per-machine HMAC signing; the newer key-pair path is being switched on, so do not assume it covers every push.
Use the boundary in the next handoff
Put the tested limit in the delegation guide's handoff. Choose another published failure from the lab's failure drills when you need a case that should stop your next change.
Browse AI Guides