Addi · Architecture Disclosure · Tier 1
Each entry states what the limit is, why it is deliberate, and what moves it. Nothing here is an apology.
Overview · Limits
The register
Every platform carries limits. The useful question for a reviewer is not whether they exist but whether the team knows where they are, chose them on purpose, and has a plan or a trigger for each. This register is our answer. Each entry states what the limit is, why it is deliberate, and what moves it. Nothing here is an apology; where we deferred work, we did it because building it early would have cost more than it protected.
Operational and security posture is described as properties and controls in architecture section 14.
Withheld by design Tier 2 Tier 3
Deeper detail on the items below, including current operational specifics, is held at Tier 2 and Tier 3 by design.The entries
1. The warehouse storage swap is designed, not executed
What: all reference data is reached through one access module, and that boundary was designed so the storage engine underneath can be replaced, with Postgres and PostGIS as the designed target pattern. Today the data lives behind the boundary; the swap itself has not been made, and we state its status plainly: the access path has not yet been exercised against the target engine, so the swap is designed, not proven in anger.
Why this is deliberate: we weighed standing up dedicated warehouse infrastructure on day one against building the access path first and letting the storage engine follow demand. Infrastructure up front would have bought us capacity we did not yet need and a second operational surface to run, patch, and pay for while the product was still finding its shape. The boundary buys us the same optionality at a fraction of the carrying cost, because producers never touch storage directly: no producer knows or cares what sits behind the access module. Our shorthand for this is build the path, not the infrastructure.
The plan and the trigger: the swap is scoped as a one-module change, and its first act when the trigger fires is a proof exercise against the designed target, not a bulk migration. It triggers when scale demands it, not on a calendar date.
2. The isolation ladder's top rung is used where justified, not everywhere
What: tenancy runs on a ladder. Every record carries its tenant, enforcement happens at one verified choke point, and the ladder tops out at physically separate per-customer deployments. The top rung is applied where the case justifies it, which means logical boundaries are not physical boundaries by default.
Why this is deliberate: physical separation for every tenant would multiply deployment surfaces, slow every release, and fragment operational attention, and it would do so to solve a problem most tenants do not present. We chose a single hardened choke point with fail-closed entitlement resolution as the default, and we reserve full physical separation for the situations that warrant it, notably where the agent's blast radius demands a harder wall than logical isolation provides. Physical separation everywhere would be the more comfortable claim, but the honest ladder is the better architecture: it puts the strongest control where the risk actually is.
The plan and the trigger: the ladder already reaches the top rung, so this is not pending work but a standing placement decision, revisited whenever a tenant's risk profile or an agent capability changes the blast-radius calculus.
3. Autonomy is budget-capped while trust accrues
What: the agent works a queue under budget caps: the spend and activity any autonomous session can incur is bounded before it starts. The agent is capable of more autonomy than we currently grant it.
Why this is deliberate: our safety doctrine is budgets plus traceability plus reversibility, never approval gates on writes, and a capability judged genuinely risky ships read-only. Caps are the throttle that lets that doctrine hold while the evidence base grows. We rejected the two obvious alternatives. Uncapped autonomy from day one asks the customer to extend trust the system has not yet earned. Approval gates on every write would smother the agent's usefulness and, worse, train humans to rubber-stamp, which is weaker accountability than a clean audit trail over reversible writes. Caps preserve the write law's guarantees, including that a machine never overwrites a human-confirmed value, while keeping the worst case of any single wake small and fully traceable.
The plan and the trigger: caps loosen as trust accrues, on demonstrated behavior under audit rather than on a schedule. The write law and the one-door contract do not loosen with them; they are permanent.
4. Open design questions we are carrying on purpose
We flag these because carrying a question visibly is a judgment, and hiding it would be a gap. None is blocking; each has a defined trigger.
Learned buy-box preferences before further automation. The buy box is explicit, typed, per-tenant criteria, and auto-reject at the buy box is the only automatic pipeline mover in the product, with reasons recorded. We are phasing in learned preferences from observed human decisions before any further automation. The open question is where the graduation line sits: at what point does an observed pattern earn the right to act rather than recommend? We have deliberately not fixed that line in advance, because the honest answer depends on accumulated human decisions we do not yet have enough of. The trigger is evidence, and until it arrives the agent recommends and a human decides.
The storage engine's moment. Entry 1 above carries its own open question: the trigger is scale, not a date, which means we are deliberately living with not knowing when the swap lands. We prefer that to a committed migration date that the workload might make wrong in either direction.
Retention and deletion against immutable evidence. The evidence chain is versioned and immutable on purpose: what a report said on the day a decision was made stays inspectable, and the corrections mechanism depends on the original claim surviving. Deletion obligations pull the other way: a tenant who leaves, or a lawful request to delete, has to be honorable without quietly breaking the audit property for everyone else. How the two reconcile, what gets tombstoned, and what deletion means for values derived from deleted evidence is a design area we are carrying, not a solved problem we are hiding. The trigger is the first tenant departure or deletion obligation that touches evidence artifacts, and the design work lands ahead of that obligation, not after it.
Adversarial content in what the agent reads. The platform ingests external content, public records, listing text, documents, and submissions, and an agent with real credentials reads what the platform serves it. Content crafted to read as instructions to that agent is a risk we carry, and we name it rather than pretend the house-style gate answers it; a style check is not a defense against injected instructions. The risk is bounded by the ingestion fences, because external content lands as structured, checked data rather than as anything executed, and by the write law: however an agent is misled, its writes still land as machine writes under budget caps, never over a human-confirmed value, traceable and reversible, and capabilities we judge genuinely risky ship read-only. The residual risk, an agent misled inside those bounds, is real. The trigger for hardening further is evidence from the audit trail, which records every agent action precisely so that questions like this one are checkable.
The boundary
It is not a vulnerability list. Security is presented in this package as properties and controls, and we do not publish gap inventories at any tier of a written document; Tier 3 provides for source walkthrough and live review under controlled conditions where such questions can be examined directly.
Withheld by design Tier 2
It is also not exhaustive operational detail: current cap postures, isolation placements per tenant, and swap readiness specifics are Tier 2 material, available on request.