The cooperative AI test
Cooperatives face a structural dilemma. Member trust depends on data sovereignty. Competitive position depends on AI capability. The current tooling market positions these as a trade-off. Architecture says they don't have to be. A perspective on what cooperative AI governance can look like when it is built deliberately rather than configured defensively.
A cooperative cannot give up member sovereignty to get AI capability. It also cannot avoid AI capability and remain competitive. Both pressures are real. The current tooling market positions them as opposites. They are not.
Member trust depends on data sovereignty. Members own their operational data, they decide what gets shared, and they need confidence that participating in the cooperative does not mean handing data to platforms that can use it against them. Competitive pressure pushes the other direction. Cooperatives that do not adopt AI-driven intelligence, market access, and supply chain capability will lose ground to better-tooled competitors over the next several years. The pressures are real. They are also not symmetrical. One is about the cooperative's reason for existing. The other is about its operating environment.
Most current AI tooling forces a trade-off between these two pressures. Cooperatives that adopt cloud-based AI without sovereignty controls erode member trust. Cooperatives that protect sovereignty by avoiding AI lose competitive ground. Neither path is durable. The framing of the trade-off is itself the problem.
The way out is not better tooling. It is architecture. Specifically, an architecture whose design properties resolve the apparent trade-off rather than mediate it.
Three properties of an architecture that holds
The architecture pattern that resolves the cooperative AI dilemma rests on three properties. None is novel in isolation. The combination is what matters.
Member operational data does not move to a central platform. Intelligence is generated through methods that operate on data without exposing it, using cryptographic attestation rather than data transfer.
The boundaries of what AI agents can do, what they can see, and what they can act on are set by member-voted governance, not by software defaults. The cooperative is the principal. The technology is the agent.
Verifiable credentials, GS1-aligned identifiers, and ASTM-coordinated frameworks mean attestations carry the same weight across cooperatives, regulators, and trading partners. Trust is portable, not platform-locked.
The first property is what protects member sovereignty without sacrificing analytical capability. The second is what keeps the cooperative governance model intact, rather than allowing software vendors to become de facto governance bodies through configuration screens. The third is what makes the work portable, durable, and recognized beyond any single platform. Together, they are the architectural answer to the question of how a cooperative can adopt AI without losing what makes it a cooperative.
"Sovereignty and capability are not opposed. They require an architecture, not a tool."
Drew Zabrocki, CEO, TOTEM Ltd.
What TOTEM is building
TOTEM is facilitating the industry-led build of infrastructure and applications for cooperative AI governance. The work spans three layers, each addressing a different aspect of the architecture pattern above. Each is in active development with partner relationships, and each is positioned for cooperative use rather than for extractive deployment.
SADIE: Smart Asynchronous Data In Escrow
SADIE is the open-source protocol infrastructure for sovereign data exchange, designed for the cooperative use case. It is aligned with GS1 standards and ASTM F49 work, and released under terms that protect cooperative use while preventing extractive deployment. Active partner relationships span GS1, IFPA, and the Supply Chain of the Future initiative. SADIE is the layer that lets organizations share insights without surrendering the underlying data, the principle we sometimes describe as sharing data with anyone without sharing it with everyone.
Commons: a member-governed intelligence application
Commons is the member-governed intelligence application built on the SADIE sovereignty layer. It is focused on agricultural market intelligence and institutional decision modeling, the use cases where cooperatives most need AI-derived insight without compromising member confidentiality. Commons is in early conversations with prospective founding cooperative members. Engagement scope is shaped by the cooperative's most pressing data governance question, not by a fixed product roadmap.
The agent governance layer
The agent governance layer is the patent-pending architecture that defines how AI agents operate within cooperative authority. It addresses the question every cooperative considering AI adoption has to answer: who, exactly, is in charge of what the AI can do, and how is that authority enforced. The layer provides cryptographic verifiability of agent decisions and member-controlled boundaries on agent action. This is what ties sovereignty to capability without forcing the trade-off. Architecture details and patent-pending mechanisms are reserved for engagement under appropriate confidentiality.
Four questions that apply to any cooperative AI initiative
Whether or not a cooperative ever works with TOTEM, the same four questions are worth applying to any AI initiative. They surface where sovereignty is real and where it is nominal. Most current AI tooling fails at least one of them in ways that become visible under examination.
-
Where does the data live during AI processing, and who has access to it in that state?
Cloud APIs that require member data to be transmitted are not sovereignty-preserving, regardless of contractual terms.
-
Who sets the boundaries of what the AI can do, and how are those boundaries enforced?
If the boundaries are set in vendor configuration rather than in member governance, member authority is nominal.
-
What evidence does the system produce that decisions, recommendations, or actions match member-set rules?
AI without auditable, verifiable decision trails creates compliance and trust exposure that compounds over time.
-
What happens to member data and AI-derived intelligence if the vendor relationship ends?
If exit means data loss or capability loss, member sovereignty was never real.
These questions are sharper than the typical AI vendor evaluation criteria. A cooperative that applies them to its current AI initiatives will likely identify exposure that warrants attention, regardless of whether it engages with TOTEM. That is the point. The questions belong to the cooperative sector, not to TOTEM. We use them in our own work and we offer them in the cooperative spirit.
Contractual sovereignty is real, but it depends on the vendor's solvency, governance, acquisition status, and continued cooperation. Architectural sovereignty does not. The difference becomes visible at the moments when it matters most: vendor acquisition, vendor pivot, vendor failure, regulatory pressure on the vendor that the cooperative did not anticipate. An architecture whose sovereignty is built into the design holds at those moments. An architecture whose sovereignty is contractual depends on holding the line through them.
What this means for cooperative leadership
The cooperative AI governance question is not theoretical. It will be answered, one way or another, by the AI initiatives cooperatives put in place over the next twelve to twenty-four months. The architecture chosen now will shape member trust and competitive position for the decade that follows. Choosing well requires the leadership to ask the four questions of every initiative, including initiatives that come highly recommended, and to insist on architectural answers rather than contractual ones.
For cooperatives whose leadership is engaged in this evaluation seriously, TOTEM's posture is straightforward. We have built the reference architecture for our own work, we are bringing it to cooperative partners through structured engagements, and the deeper architectural conversation happens under appropriate confidentiality. Three engagement paths fit different starting points: an architecture review of current AI initiatives, a scoped pilot applied to a specific cooperative use case, or a strategic partnership across multiple cooperative initiatives with a structured pathway for the cooperative to take ownership over time. Patent-pending mechanisms, the specific governance protocols, and the technology stack details are reserved for that conversation.
The questions, the architectural pattern, and the diagnostic frame are public. They are useful with or without further engagement.
There is a longer brief behind this perspective.
It documents the reference architecture TOTEM operates for our own work. We built it for ourselves first, before bringing the pattern to cooperative partners, because we are not comfortable deploying a governance discipline we have not lived inside. The brief covers the design choices, the operating outcomes, the diagnostic frame applied to specific implementation questions, and the discipline that makes the architecture durable. Patent-pending mechanisms are described in summary form; technical detail is reserved for engagement under appropriate confidentiality.
If you are evaluating cooperative AI governance seriously and want the deeper read, reach out and we will share the brief under NDA. The conversation that follows is the one worth having.
Founding partners in the Smart Data Escrow toolset include the Collaboratory for Open Software and Systems in Ag and Food (COSSAF) and Qlever, with technical leadership from Aaron Ault and the Purdue University OATS Center lineage. Standards relationships include GS1, ASTM, UN/CEFACT, IFPA, and the Supply Chain of the Future initiative. Patent filings are active across the architecture; deeper material is shared under appropriate confidentiality.
Ready to build something that lasts?
Whether you are an industry association exploring collaborative infrastructure, a coalition needing execution support, or an organization with a complex multi-stakeholder challenge, let us talk.