Architecture

SynchroLabs builds infrastructure for sovereign knowledge and governed coordination. The site calls this Augmented Collective Intelligence: the capacity of a group to turn sovereign knowledge into shared understanding, coordinated action, and better-directed capital, with the knowledge staying under its owner's governance and a human deciding at every surface that acts. The architecture is what makes that capacity possible. It addresses the condition in which people, organizations, and territories hold knowledge that is neither shared by default nor safely combinable by an AI system: provenance is lost when knowledge is pooled, relations are inferred without consent, and a system that can act on inference has no human between inference and consequence. The architecture is one canonical knowledge layer per trust domain, joined to other domains only by explicit bridges, in four parts: a sovereign data layer, a Knowledge Membrane, a coordination layer, and applications. Its distinctive commitments are that sovereignty is implemented as self-governance over a storage-neutral knowledge bundle and is to be demonstrated by export, that AI output proposes and a recorded human decision disposes at every surface that would act on someone's behalf or bind them, and that external protocols are composed with and never built. As of August 2026 one territorial application runs in production, one domain-scoped coordination capability runs as code, the Membrane and bridge model are adopted architecture with full implementation across domains not yet established, coordination at network scale is specified, and the governed export that demonstrates non-custody is specified and scheduled as an acceptance criterion in the first deployment where portability is in scope (§Status and maturity carries each component with its state and date).

The table summarizes the layers, their responsibilities, and their status as of August 2026.

The architecture must hold knowledge that belongs to more than one governing party. A person, an organization, and a territorial community can share members and still govern their own knowledge separately; the system must keep those governing contexts distinct.

Knowledge must cross between governing parties only with that party's consent, expressed as explicit permissions. Nothing is shared by default, and a permission names what crosses, to whom, and for what use.

Every claim must carry provenance, and asserted, inferred, and unrecorded facts must remain distinct. A model working over ungoverned text infers relationships that nobody asserted, verified, or consented to, and an absent connection may mean unrecorded, not nonexistent. Inferred relations must not be stored or acted on as asserted.

A human decision must stand between inference and any consequence. An output that would act on behalf of a person or community, or bind them to an obligation, must carry a recorded human disposition or an authored, revocable delegation.

Knowledge must survive a change of carrier. The storage system and the protocol that hold a domain's knowledge must be replaceable without loss of identity, provenance, or governance context.

The architecture must serve a role rather than a market segment: an organization accountable for coordinating a field of participants, knowledge, and activity. Personal and territorial deployments must be governed by the same rule at a different scale.

Five decision rules govern the architecture. Each is applied in the section named beside it.

The architecture has four parts on one rule, each instantiated per trust domain: a sovereign data layer, a Knowledge Membrane, a coordination layer, and applications. The sovereign data layer holds a domain's knowledge. The Knowledge Membrane governs the boundary through which knowledge enters the domain, becomes usable, and leaves it. The coordination layer reads what the Membrane exposes and returns patterns, matches, measurements, and proposals for people and organizations to act on. Applications are the interfaces through which people use a bounded combination of the other three.

Read as a flow, the same architecture is data → connectors → graph → agents → engines → interfaces, and every element in the flow maps to one part and one trust domain. Data resides in the sovereign data layer. Connectors carry permitted material through the Membrane in either direction. The graph represents entries and relations within the sovereignty scope in force. Agents operate on the context they are permitted to receive. Engines formulate outputs. Interfaces present information, request a decision, or execute an action under an explicit delegation. The flow locates the controls: provenance at entry, sovereignty scope at connectors and graph, supplied context at agents and engines, and human disposition at every engine surface.

A trust domain is the set of people, information, permissions, and decision authority governed together for a defined context. A person, an organization, a territorial community, and a program inside an organization can each constitute a trust domain, and one person can participate in several at once without merging them.

A bridge is the only path by which information or capability crosses between domains, and it carries defined permissions. A bridge states what each side contributes, what each side receives, and for what use; a connector that crosses a bridge must inherit exactly those permissions.

adopted architecture · full implementation across intended domains not established · see §Open questions and collaboration

A personal domain inside an organizational deployment remains personal. The organization does not inherit a person's knowledge by association, and the bridge permissions state what enters the shared scope, what stays private, and what can leave.

The same rule holds at every scale the architecture is intended to serve. A person, two people working together, an organization accountable for an ecosystem, and a network of networks are distinct trust domains under the same rule, and a single organization or a single cohort is where the rule can first be put to a bounded test.

The sovereign data layer holds a trust domain's knowledge as cargo under that domain's self-governance. Cargo is the knowledge bundle whose identity and governance are defined to survive a change of carrier, the storage system or protocol that holds it at a given time. Sovereign means self-governed: the trust domain itself governs who may hold its knowledge, who may use it, what may cross its boundary, and who can change those permissions.

Every entry in the cargo carries six properties, and the entry schema is storage-neutral by adopted rule. An entry is one unit of knowledge in the cargo. The properties are:

Inputs enter and outputs leave only through the Knowledge Membrane. The sovereign data layer exposes no path around the Membrane; connectors, exports, and bridges all traverse it.

The layer is designed to preserve identity, provenance, and governance context across a change of carrier; that preservation is specified, and it is demonstrated by the export procedure in §Portability and custody, which has not yet run. For the same reason the layer does not yet guarantee non-custody: custody is currently on infrastructure operated by SynchroLabs while governance remains the domain's, and non-custody is demonstrated by the same export, scheduled as an acceptance criterion in the first deployment where portability is in scope.

governance: adopted · custody: operator-run · export: specified

The layer depends on a replaceable storage carrier and on no particular protocol. A community's choice of protocol is a carrier decision and does not change the cargo definition.

The Knowledge Membrane is the governed boundary of a trust domain: knowledge enters the domain through it, becomes usable inside the domain through it, and leaves the domain through it. It is implemented as a layer between the sovereign data layer and the coordination layer. Every entry receives its sovereignty scope as it enters, and by the design rule the Membrane is the structure that enforces that scope at every crossing; no separate step to apply it is needed.

Knowledge enters a domain only from an allowed source or connector, and every entry receives provenance and a sovereignty scope at that moment.

Knowledge leaves the Membrane in two ways only: exposure to coordination functions inside the domain, and exit from the domain through an explicit export, an interface action, or a bridge with defined permissions. By the design rule, nothing else crosses the boundary in either direction.

The Membrane guarantees that every entry keeps its source and that asserted, inferred, and unrecorded facts remain distinct. An absent connection is represented as unrecorded, and a relation inferred by a model is stored as inferred until a human asserts it.

The Membrane governs a personal domain by the same design as an organizational or territorial one, and a capability demonstrated at one scope is not claimed at another. Enforcement of its rules is evaluated per surface under §Human authority and engine surfaces.

adopted architecture · full scope specified · implementation per deployment · see §Status and maturity

People and organizations act together on permitted knowledge; the coordination layer supplies what that action needs: who should act, what to do, and what changed. It returns these as patterns, matches, measurements, and proposals, and it operates only on what a domain's Knowledge Membrane exposes, never on the sovereign data layer directly.

Its outputs divide into informative computations and engine surfaces, and the distinction determines where the human-authority rule binds. Informative computations are results a person asks for and reads before deciding: a search, a ranked list, a similarity match, or a summary of permitted knowledge. Engine surfaces are outputs that would act on behalf of a person or community or bind them to an obligation: sending a message in their name, publishing on their behalf, applying a change to their records, or moving money or resources for them. The human-authority rule binds at engine surfaces only.

Status is stated per capability and per scope. A capability running in one trust domain is not thereby running across domains or in another domain; §Status and maturity lists each capability at the scope where it runs.

The layer depends on external AI model providers wherever a capability calls a model. That dependence is running and dated August 2026; moving it to an organization-held account with a named alternate provider is open work (§Open questions and collaboration). It also depends on a self-hosted agent runtime, operated by the team, that hosts its agents; that dependence is running and dated August 2026 (§Status and maturity).

An application is an interface through which people use a bounded combination of the sovereign data layer, the Knowledge Membrane, and the coordination layer; it has its own audience and workflow, and the knowledge it presents remains under the governance of the trust domain it came from. An application changes how knowledge is used, never who governs it. Applications include a territorial guide, an organizational map, a funder-facing view, and a community's own platform for membership, events, and trusted introductions.

Applications take permitted knowledge and coordination outputs as inputs, and they present information, request a decision, or execute an action under an explicit delegation. An application may display information from several sources only to the extent that each source permits that use.

Reuse of the three layers beneath an application is a design property; current applications and their individual states are listed in §Status and maturity.

Any output that would act on behalf of a person or community, or bind them to an obligation, requires a recorded human decision or an explicit, revocable delegation authored by the decision holder.

adopted rule

The rule applies only where an output would act or bind; reading, searching, and summarizing are not governed by it. A person may ask for and read a search result, a ranked list, or a summary of permitted knowledge without the rule triggering; an output that sends, publishes, changes records, or moves resources on someone's behalf triggers it.

Delegation is authored, bounded, revocable, and recorded. A decision holder may author a standing delegation for a bounded class of actions; the system records that it was authored, by whom, and for what, and the holder may revoke it at any time. Revocation withdraws the authority to act; whether it can withdraw access to knowledge already received across a bridge is not specified (§Open questions and collaboration).

Technical enforcement of the rule is specified per surface and is implemented with each deployment's first surfaces; no blanket enforcement is claimed. An enforcement claim for a given surface requires evidence of its primary constraint, permission, or trigger; such claims are published surface by surface as they are verified, and contributions are invited in §Open questions and collaboration.

per-surface enforcement: specified

Portability is the property that a trust domain's cargo can be exported to open formats and reconstructed elsewhere with identity, provenance, and governance intact; it is specified and not yet performed.

The export procedure has four steps. The steps are:

The first export runs as an acceptance criterion in the first deployment where portability is in scope, and its result is published and reflected in this page. A verified export requires a real domain and real cargo, so the procedure is tied to deployment and is not run on synthetic data.

export: specified · scheduled with the first portability-in-scope deployment

Custody today is on operator-run infrastructure, and hosting is a replaceable carrier. A community or an implementation partner can replace SynchroLabs hosting with another carrier, including an existing open protocol; the cargo definition is what makes that replacement possible, and the invitation to do so is open. Non-custody becomes demonstrated when step 4 has been verified for a governed domain.

Code is licensed in layers, and community knowledge is not licensed by SynchroLabs. The posture is network copyleft on the code of the data and knowledge core, permissive on the application layer, and share-alike on public schemas and documents. A community's cargo belongs to the community, and the code license claims nothing over it. Implementation across repositories is in progress.

posture: adopted · implementation: in progress

Interoperability is achieved by composing with external protocols and by carrier-independent cargo. SynchroLabs composes with the protocols and rails a community chooses and builds no protocol of its own. A protocol is a carrier and a bridge target, and adoption in one domain does not transfer to another.

Status is labeled per component and dated. The labels are running (in production against real use, with a date), implemented-unverified (code or prototype without verified evidence at the claimed scope), specified (designed and documented, not built), planned (intended, not yet specified), and adopted architecture (a design rule in force whose implementation state is given per deployment). Dated figures travel in SynchroLabs' dated documents.

The architecture builds no protocol, requires no blockchain, operates no social network of its own, and licenses no community knowledge. These are exclusions by design:

Capabilities that are specified but not yet running are listed, with what brings each into implementation, in §Open questions and collaboration. Those limits are scheduled, not deferred.

SynchroLabs already works with a circle of collaborators across measurement, protocols, identity, and territorial practice, who appear on its surfaces only with their consent; this section names where further contribution is sought.

Four capabilities are in progress and open to contributors. Each enters implementation with the engagement that requires it:

Five design questions are open, and each is a collaboration surface. The questions are:

Four specifications are defined per deployment and per surface and are not published on this page. They are the identity of persons and domains, the record of a human decision and its auditability, logical versus physical isolation of a trust domain, and the location of the canonical entry schema.

Collaborators working on any of these questions are invited to contact the team directly. The areas where contribution is sought are identity, consent architecture between sovereign parties, portability and export tooling, per-surface enforcement mechanisms, shared-engine governance, and measurement.

The definitions below restate the inline definitions verbatim.