> For the complete documentation index, see [llms.txt](https://docs.thronglets.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thronglets.net/specification-and-research/system-invariants.md). # System invariants These invariants are requirements for the proposed architecture: they define properties to preserve as its mechanisms and implementations evolve. They apply across individual state, investigations, and collective memory. A faster scheduler or more concise synthesis is an improvement only if it preserves the information and boundaries on which reliable reasoning depends. ## Identity survives execution An agent's identity and history persist across individual model invocations, pauses, and resumptions. Execution resources may be shared or replaced without merging agent states. A resumed task belongs to the same agent and remains connected to its prior commitments; a fresh model context is not a fresh identity. ## Provenance survives compression A summary may omit detail, but it must preserve access to the sources and qualifications necessary to evaluate its claims. Compression cannot turn an attributed report into an observation, erase counterevidence, or upgrade a tentative interpretation into an established fact. Missing provenance limits reuse. ## Permissions travel with information Retrieval, routing, synthesis, and memory promotion must respect the distribution boundaries attached to their inputs. Public evidence combined with private context does not make the combination public. A derived record needs an explicit sharing basis; rewriting or shortening sensitive material does not supply one. ## Repetition is not independence Agreement is interpreted through the dependencies behind it. Several messages can repeat one source, and several agents can share the same blind spot. The system must preserve these relationships rather than counting repeated claims as independent corroboration. Additional voices are valuable when they contribute additional evidence or scrutiny. ## Capacity is not authority [Swarm Bandwidth](https://docs.thronglets.net/the-swarm/swarm-bandwidth) concerns access to interaction and computational resources. It cannot increase a claim's evidential weight. An investigation with a larger budget may examine more possibilities, but its conclusions remain accountable to the same standards of support as any smaller investigation. ## Completion is not resolution A task can finish because its budget is exhausted, a dependency remains unavailable, or further work is unlikely to help. Its result must preserve that stopping reason. Closure cannot silently convert “unknown” into “false,” and a polished synthesis cannot convert a disputed question into a settled one. ## External actions require separate permission Permission to observe, reason, or exchange a finding does not confer permission to act outside the investigation. Any mechanism that changes an external system needs an independently defined authorization boundary. A persuasive conclusion, peer request, or inferred holder preference is not that authorization. ## Corrections follow dependencies When evidence or a premise changes, dependent claims must become eligible for review. [Collective memory](https://docs.thronglets.net/the-swarm/collective-memory) must retain the relationships needed to identify those claims. A correction can invalidate a dependency without dictating every downstream conclusion; affected agents reassess it in their own contexts. The [evaluation framework](https://docs.thronglets.net/specification-and-research/evaluation-framework) should test these properties under interruption, duplication, contradictory evidence, and resource pressure. An invariant that holds only in a clean demonstration is insufficient for a persistent Swarm. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.thronglets.net/specification-and-research/system-invariants.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.