The STOA Protocol

Designing Transparency Infrastructure for Algorithmic Governance

Independent Research & Practice · Mindful Studio 6 months · Solo design science engagement · Published preprint · IHCI peer-reviewed paper 2026 (forthcoming)

| 166-page technical specification produced in 6 months | 3-component architecture: canonical data model, symbolic reasoning engine, federated audit ledger | Figma Make prototype built and tested using prompt design to simulate SRE reasoning behavior | Active validation: social media literacy classes with tweens and parents · IHCI 2026 forthcoming |


Overview

Role: Independent Researcher, Systems Architect & Prototype Designer

Organization: Mindful Studio LLC

Engagement Type: Design Science Research, Technical Architecture, AI Governance System Design, Rapid Prototyping

Status: Published preprint (Zenodo) · Interactive prototype built and tested · Active validation · Forthcoming: IHCI 2026

Focus: AI governance transparency, algorithmic accountability, knowledge representation, rights-aligned system architecture, federated audit infrastructure

Tools: Design science methodology, Figma Make, prompt design, JSON-LD schema design, Merkle DAG architecture, symbolic reasoning specification, expert consultation protocols

Background

The problem: AI and algorithmic systems make governance decisions that affect billions of people — content moderation, account suspension, algorithmic amplification, automated enforcement, and produce no auditable reasoning. The existing transparency mechanisms are fragmented, proprietary, and insufficient. Model cards describe training data. Algorithmic audits describe aggregate behavior. Platform transparency reports describe volume. None of them documents the reasoning behind a specific governance decision in a way that can be independently verified, rights-grounded, or appealed against on the basis of a stable evidentiary record.

This is not a policy gap. It is an information architecture gap — and information architecture gaps are design problems.

STOA (Standards for Transparent Online Agency) is the architectural response: a rights-aligned, platform-independent protocol for documenting and explaining digital governance actions using a structured, auditable, cryptographically verifiable reasoning chain — without requiring platform cooperation, personal data ingestion, or access to proprietary moderation systems.

The question that initiated the work was direct:

Food has nutrition labels. Financial products have disclosure requirements. Social media shapes what billions of people believe and offers no way to understand how or why. What would a transparency protocol actually look like — specified precisely enough to be built, governed, and audited?

Six months later, the answer was a 166-page technical specification, an interactive prototype, and an active validation program.

The Design Science Approach

Why Design Science — and What It Required

Design science is the appropriate methodology for problems where the knowledge gap is not empirical but architectural — where what is missing is not data or theory, but a designed artifact that, by existing and being evaluated, advances understanding of what is possible.

STOA required design science rather than conventional research because the problem was not "what is happening?" but "what should exist?" — and answering that question required actually designing the thing, specifying it precisely, prototyping it, and submitting it to expert critique. Not describing what it might look like in general terms.

The six-month engagement followed a structured design science cycle:

Phase 1 — Problem Identification and Requirements Definition

Precisely defining the gap: what transparency mechanisms exist, where they fail, what a functional transparency protocol would need to do that existing mechanisms cannot.

This phase produced the core requirements — platform independence, rights alignment, privacy preservation, cryptographic verifiability, and human oversight architecture — before any system design began.

Phase 4 — Prototype Design and Real-World Testing

Building an interactive prototype in Figma Make to test how STOA would operate in the real world — specifically, whether the user-facing governance explanation experience was legible, navigable, and actionable for non-expert users.

Prompt design was used to simulate the Symbolic Reasoning Engine's behavior, translating the formal specification into conversational outputs that could be tested against real users.

Phase 2 — Architecture Design

Designing the three-component system architecture in sufficient technical detail to be evaluated by protocol engineers, legal scholars, AI ethicists, and civil society practitioners simultaneously.

This required translating requirements into formal specifications — JSON-LD schemas, reasoning flow diagrams, ledger record types, API definitions — rather than conceptual frameworks.

Phase 5 — Specification, Publication, and Ongoing Validation

Producing a complete normative technical specification and publishing it as a preprint for academic review and civil society evaluation, while running active validation through social media literacy classes to test the human comprehension layer of the framework.

Phase 3 — Expert Consultation and Iterative Refinement

Engaging subject matter experts across digital rights, platform governance, regulatory compliance, AI ethics, child safety, and civic technology — not for endorsement, but to surface structural blind spots, safety risks, jurisdictional tensions, and practical limits.

Expert input drove major architectural changes between v1.0 and v1.1.

This is the same design science approach applied to client problems across the other engagements in this portfolio — the difference is that here, the problem was self-identified, the scope was self-defined, and the output was a public contribution rather than a client deliverable.

The Problem With Existing Transparency Mechanisms

What Already Exists and Why It Isn't Enough

The existing transparency infrastructure for AI and algorithmic governance is meaningful but insufficient for the specific accountability problem STOA addresses:

Model cards document training data, evaluation metrics, and intended use cases. They describe what a system was designed to do in aggregate — not why it made a specific decision about a specific piece of content.

Algorithmic audits evaluate system behavior across populations. They surface patterns of bias or inconsistency in aggregate, not the reasoning chain behind an individual governance event.

Platform transparency reports document enforcement volume by category and region. They describe how many decisions were made — not why any particular decision was made or whether that reasoning was rights-compliant.

The EU Digital Services Act introduces new obligations for explainability and public disclosure. It establishes regulatory requirements but lacks a common protocol to standardize interpretive reasoning across heterogeneous systems. Different platforms, different jurisdictions, and different AI systems produce explanations in incompatible formats that cannot be independently compared or audited.

The gap is not a lack of effort in transparency. It is the absence of a shared, neutral, implementation-agnostic method for representing the context of a governance event, its ethical and legal basis, and a verifiable chain of reasoning that can be audited without exposing personal data or requiring platform cooperation.

That is the architectural problem STOA was designed to solve.

The Architecture

Three Components, One Auditable Pipeline

STOA's technical architecture comprises three interdependent components that together produce a structured, independent, and auditable transparency pipeline:

Component 1: The Canonical Social Object Model (CSOM)

A structured, non-personal data model capturing governance-relevant attributes of a content object without storing the content itself. The CSOM captures semantic fingerprints, rule references, jurisdictional constraints, and ethical basis indicators — the information necessary to reason about a governance decision without exposing users or auditors to the underlying material.

v1.1 eliminates all raw content fields entirely. The CSOM operates on meaning extraction, not content reproduction — a design decision driven by expert consultation that significantly strengthened both the privacy architecture and the safety model for prohibited content categories.

Why this matters for AI governance: Most AI explainability frameworks struggle with the same problem — how do you explain a decision without reproducing the sensitive input that triggered it? The CSOM's meaning-extraction architecture is a generalizable solution to that problem, applicable to any AI system that makes decisions on sensitive content.

Component 2: The Symbolic Reasoning Engine (SRE)

A verification-oriented reasoning system that formalizes why a governance decision occurred. The SRE generates symbolic proofs grounded in universal rights instruments — the Universal Declaration of Human Rights, the International Covenant on Civil and Political Rights, the Convention on the Rights of the Child — user-selected context layers, and jurisdictional overlays defined by the Rights Exception Registry.

The SRE's three-tier reasoning architecture establishes a clear precedence hierarchy: rights constraints take precedence over contextual interpretation, which takes precedence over jurisdictional overlays. This hierarchy is not a policy position — it is a formal specification that makes the reasoning auditable and the precedence structure explicit.

The role of AI within the SRE is explicitly constrained. ML and AI signals are permitted as non-normative inputs — informing the reasoning process — but are prohibited from serving as the primary basis for a governance decision. Every decision that carries rights implications must be traceable to a symbolic proof, not a model confidence score. This is the human-in-the-loop architecture specified at the protocol level rather than left to implementation discretion.

v1.1 adds multi-framework ethical evaluation — utilitarian, deontological, care ethics, and justice-as-fairness perspectives — and interpretive confidence scoring that makes uncertainty explicit rather than hiding it behind a binary enforcement decision.

Component 3: The Context Ledger

A standardized, append-only, federated ledger that records what occurred — including rule triggers, Rights Exception Registry references, timestamps, system states, classifier signals where applicable, and ethical considerations. The v1.1 redesign introduces Merkle-committed entries, regional and local node governance, and cryptographically signed reasoning artifacts to support independent verification and public auditability.

The Context Ledger is federated by design — no single entity controls the record. Regional and local nodes can maintain governance appropriate to their jurisdiction without compromising the integrity of the global audit trail. Merkle DAG commitments make tampering detectable without requiring trust in any single node operator.

The ledger records reasoning, not content. Users, researchers, and regulators can audit whether a governance decision was made in accordance with stated rules and applicable rights frameworks — without access to the underlying content or the affected user's personal data.

Human Oversight as a First-Class Design Requirement

One of the central design science contributions of STOA is the treatment of human oversight not as a fallback mechanism but as a first-class architectural requirement — specified in detail, with defined roles, decision domains, and review processes.

The governance model establishes four bodies with distinct and non-overlapping mandates:

The Context Review Council (CRC) — a multi-stakeholder body responsible for reviewing and approving Context Layers, managing appeals that reach the protocol level, and ensuring that the interpretive framework remains aligned with evolving rights standards. Composition requirements ensure representation across legal, civil society, technical, and affected community perspectives.

The Technical Verification Committee (TVC) — responsible for security auditing, schema validation, and ensuring that implementations conform to the normative specification. The TVC leads annual technical audits and quarterly adversarial resistance reviews.

The Ethics and Rights Advisory Board (ERAB) — responsible for the ethical framework underlying the Baseline Rights Layer and the Rights Exception Registry, and for evaluating requests for jurisdictional exceptions that would modify the default rights protections.

Civic and NGO Partners — formal participants in the governance model, not advisory ornaments. STOA's participatory development model requires ongoing structured engagement with civil society organizations and communities most affected by opaque governance systems.

This governance architecture reflects a specific design science position: a transparency protocol that is itself opaque in its governance is not a transparency protocol. Every governance body, decision domain, review process, and appeal pathway is specified in the normative document — not left to implementation discretion.

The partner model is a critical architectural feature: approved organizations — civil society groups, digital rights organizations, academic institutions — can author and maintain their own Context Layers within the STOA framework. A user might choose to apply a Context Layer maintained by a trusted media accountability organization, which would inform how governance decisions affecting that user are interpreted and explained. Partners are approved through the CRC process, operate under defined accountability requirements, and are subject to the same audit infrastructure as the protocol itself.

The Governance Architecture

The AI Governance Contribution

What STOA Adds to the AI Oversight Conversation

The current AI governance landscape has a specific and underappreciated gap: most AI accountability frameworks focus on model behavior in aggregate, not on individual decision reasoning in specific high-stakes contexts. STOA addresses the latter.

Three specific contributions to the AI governance conversation:

1. A rights-grounded constraint architecture for AI decision systems

The SRE's precedence hierarchy — rights constraints over contextual interpretation over jurisdictional overlays — provides a formal model for how AI signals should be subordinated to rights frameworks in governance contexts. This is not a policy recommendation. It is a specified architecture that can be adopted, evaluated, and improved by any system that needs to make AI-assisted governance decisions in a rights-relevant context.

2. A specified human-in-the-loop protocol for AI governance decisions

Rather than leaving human oversight to implementation discretion, STOA specifies exactly when human review is required, what information must be presented to the human reviewer, what the reviewer is authorized to decide, and how that decision is recorded in the audit ledger. This is the level of specificity that human-in-the-loop requirements need to be operational, not aspirational.

3. A privacy-preserving audit architecture for AI-assisted decisions

The CSOM's meaning-extraction approach and the Context Ledger's content-free record structure together solve a problem that most AI audit frameworks don't address: how do you audit a decision about sensitive content without reproducing that content in the audit record? The answer STOA provides — semantic fingerprinting, cryptographic commitment, and meaning-level rather than content-level reasoning — is a generalizable contribution to AI audit infrastructure.

AI as Operational Infrastructure, Not Interpretive Authority

STOA is designed for large-scale digital environments where AI and machine learning systems are unavoidable for handling volume, velocity, and diversity of content.

At a global scale, AI is required to:

  • generate content-understanding signals across languages and media types

  • support triage, prioritization, and anomaly detection

  • monitor drift, bias, and systemic failure patterns

  • enable safety and non-exposure guarantees reliably

STOA does not treat AI outputs as decisions or truth.
Instead, AI-generated outputs are treated as fallible, probabilistic signals.

The protocol's core contribution is to define how those signals are represented, constrained, reasoned about, and explained.

Within STOA:

  • AI/ML systems generate signals

  • CSOM standardizes those signals with provenance and confidence

  • SRE determines how—and whether—those signals are applied under explicit rules, priorities, and exceptions

  • the Context Ledger records the reasoning path for audit and review

This separation allows automation to scale without collapsing accountability.

AI functions as operational infrastructure, not interpretive authority.

Interpretive decisions cannot be explained if the objects under interpretation are inconsistently defined.

In most social platforms, content is represented differently depending on:

  • product surface (feed, story, short video, advertisement)

  • distribution mechanism (organic, boosted, recommended)

  • moderation state (flagged, restricted, removed)

  • jurisdictional or policy context

These representations are optimized for delivery and enforcement—not for explanation.

The Canonical Social Object Model (CSOM) establishes a single, platform-independent representation of a social object that includes:

  • the content itself (text, media, references)

  • core metadata (source, time, relationships)

  • distribution context (how and where it appeared)

  • interpretive signals (sensitivity, amplification, sponsorship)

  • applicable constraints (jurisdictional, age-based, rights-related)

CSOM does not encode platform policy or enforcement outcomes.
It encodes the conditions under which interpretation occurs.

By stabilizing how social content is represented, CSOM makes interpretation:

  • comparable across contexts

  • decoupled from platform implementation

  • stable enough to support explanation, review, and audit

Without CSOM, transparency collapses into ad hoc, surface-level descriptions tied to specific interfaces rather than to meaning.

Canonical Social Object Model (CSOM)

An example of a content explanation pattern that makes recommendation signals visible, qualifies confidence, and prompts reflection—supporting interpretation and user agency rather than judgment or enforcement.

Symbolic Reasoning Engine (SRE)

Where CSOM defines what is being interpreted, the Symbolic Reasoning Engine (SRE) defines how interpretation happens.

The SRE is a rule-based system grounded in symbolic logic, designed to make ethical and governance principles executable rather than declarative.

It is not a machine learning model.
It does not optimize predictions or produce probabilistic judgments.

Instead, it explicitly represents:

  • values and principles

  • constraints and obligations

  • priorities and exceptions

  • uncertainty and scope

This reflects a core design assumption: ethical reasoning depends on explicit rules, conditional logic, and traceable justification, rather than on statistical inference.

The Interpretive Core transforms canonical representations into structured reasoning outputs.

Inputs include:

  • CSOM representations of social objects

  • contextual signals (e.g., jurisdiction, age context, declared preferences)

  • rights-based and safety constraints

  • governance structures (exceptions, review requirements)

How the Interpretive Core Functions

The reasoning process involves:

  • applying symbolic rules to canonical objects

  • resolving conflicts between principles

  • qualifying interpretations with scope and confidence

  • recording provenance and decision paths

Outputs are not enforcement actions, but interpretive explanations designed to be surfaced to users, auditors, or reviewers.

This separation ensures that:

  • interpretation does not automatically trigger control

  • reasoning can be inspected without coercion

  • disagreement is possible without system failure

The federated STOA architecture shows how autonomous local ledgers can be indexed and aggregated across regions without transferring authority or control.

Context Layers

Context layer selection in STOA, where users choose trusted organizations to add explainable signals and insights to their feed—without removing content or limiting expression.

Context Layers represent different interpretive perspectives—such as safety, relevance, amplification, or sponsorship—that can be examined independently.

A key design decision was to separate interpretation from enforcement, allowing meaning to be surfaced without immediately triggering control actions.

Ethics as System Logic

Rather than expressing ethics as abstract policy statements, STOA encodes ethical principles as:

  • constraints (e.g., non-exposure to harmful material)

  • obligations (e.g., surface context when confidence is low)

  • priorities (e.g., rights-based exceptions override preference-based filters)

Ethics, therefore, shape system behavior directly and consistently over time.

Conflict, Priority, and Accountability

Real-world governance involves disagreement.

The Interpretive Core is explicitly designed to:

  • surface when principles collide

  • show which rule took precedence

  • document when exceptions were applied

Rather than hiding complexity, the system makes value conflicts visible in bounded, reviewable ways.

Research & Subject-Matter Expert Engagement

Secondary Research

The project draws on peer-reviewed research in:

  • platform governance

  • transparency and procedural justice

  • algorithmic accountability

  • media literacy

This research shaped constraints on what the system should not do as much as what it could do.

Interviews & Co-Design Workshops

I conducted interviews and participatory design sessions with subject-matter experts across:

  • digital rights

  • AI ethics and safety

  • journalism

  • civic technology

  • human–computer interaction

Rather than soliciting requirements, sessions were structured to surface:

  • reasoning breakdowns

  • ambiguity points

  • safety risks

  • governance constraints

Many design decisions emerged from where experts struggled to explain existing systems, not from explicit prescriptions.

Transparency Observatory

The Transparency Observatory is the governance monitoring layer — the interface through which the oversight ecosystem can observe how transparency, accountability, and rights compliance are operating across the institutions participating in the protocol.

What the screen demonstrates:

  • The partner governance model made visible — Trusted Safety & Compliance Partners shown with their certification status, role in the ecosystem, and accountability tier. This is the approved partner architecture from the specification rendered as an operational interface.

  • The four governance domains — Policy Compliance, Rights Protection, Civil Society, and Global Oversight — map directly to the four governance bodies specified in the normative document.

  • Measurable accountability outputs — the Transparency Score Evolution chart and Overall Score of 85 demonstrate that STOA produces quantifiable governance metrics, not just audit records. The "+3 from last month" indicator shows the system tracks change over time, enabling accountability trends rather than point-in-time snapshots.

  • Security and compliance infrastructure — ISO 27001 Certified, GDPR Compliant, SOC 2 Type II, and End-to-End Encrypted indicators establish that the operational system meets the security requirements specified in the Security Annex.

Developer Dashboard — Protocol Integration

The Developer Dashboard is the technical integration layer — the interface through which protocol engineers connect STOA to existing social infrastructure.

What the screen demonstrates:

  • Platform independence made concrete — AT Protocol, ActivityPub, and DSNP shown as connectable protocol options, each with its own status and integration documentation. This is the platform-independence claim of the specification rendered as an operational developer experience rather than an architectural assertion.

  • Federated system status — the System Status panel showing operational status for ATProto Network (99.9%), ActivityPub Federation (99.7%), DSNP Gateway (98.5% / Maintenance), and OSA Bridge (99.8%) demonstrates the federated architecture operating across multiple independent network nodes simultaneously.

  • The integration model — the "click to connect protocols and build your OSA stack" interaction model — demonstrates that STOA is designed to be composable with existing decentralized infrastructure rather than requiring its replacement.

The tween audience is deliberately the most challenging test. The EU's Digital Services Act extends specific protections to minors. STOA's Baseline Rights Layer incorporates the provisions of the Convention on the Rights of the Child. If the reasoning framework is legible and actionable for young people aged 10-14 — with parental participation as the human oversight layer — it establishes a baseline of comprehension that adult populations should be able to meet or exceed.

The parent inclusion is not incidental. It is a design decision: inviting the trusted adult into the session mirrors the human-oversight architecture that STOA specifies for minor-adjacent governance decisions. The session format itself is a prototype of the multi-stakeholder accountability model.

Validation Approach

Two Methods, One Question

Can the Framework Be Understood and Used by the People It Is Designed to Protect?

Securing institutional funding or formal program entry to run the originally planned pilots proved unsuccessful. Rather than wait, I designed two alternative validation approaches that together address a question no institutional pilot would have surfaced as directly.

Method 1: Interactive Prototype Testing

The Figma Make prototype provided the first validation layer: does the user-facing governance explanation experience produced by simulating the SRE's reasoning behavior make sense to someone encountering it for the first time? Building the prototype required designing prompts precise enough to generate outputs consistent with the specification's reasoning framework — surfacing gaps between what the specification described and what the interface could actually communicate.

Method 2: Social Media Literacy Classes

I am currently running social media literacy classes for tweens — young people aged 10-14 — conducted online, with parents invited to participate alongside their children. The sessions teach participants how algorithmic governance works, why content decisions are made, and what transparency about those decisions would look like — using the STOA framework as the explanatory model.

This approach does three things that institutional pilots cannot:

1) Tests the human comprehension layer at maximum difficulty. If a transparency protocol cannot be explained to a 12-year-old in terms they can engage with, the protocol has a legibility problem regardless of its technical rigor. These sessions surface exactly where the reasoning framework becomes abstract, where the rights grounding resonates, and where the explanation model needs to be redesigned.

2) Tests the multi-stakeholder dynamic in real time. Parents and children frequently have different intuitions about platform governance — what counts as fair, what counts as adequate explanation, what counts as recourse. Observing that dynamic live is the closest available proxy to the multi-stakeholder governance model STOA specifies, and it surfaces tensions that expert consultation alone cannot anticipate.

3) Generates qualitative evidence about the human layer of AI governance. Every session produces data on how non-expert users understand algorithmic decision-making — data directly relevant to the human-in-the-loop specification, the interpretive confidence-scoring model, and the user-facing interaction design of the Context Ledger.

Key Takeaway

The most urgent AI governance problem is not which model to use or how to make models more accurate. It is the absence of infrastructure for documenting, explaining, and auditing AI-assisted decisions in ways that are rights-grounded, platform-independent, and resistant to the institutional incentives that make opacity profitable.

Public Artifacts

Technical Specification (Preprint)

https://zenodo.org/records/18154981

Share STOA App Feedback

Click link to try STOA App Prototype

Current Status

v1.1 — Published

Preprint under CC BY-NC-ND 4.0. Available for academic review, expert consultation, and standards development at Zenodo. Non-implementable pending completion of governance, ethical guardrails, and validation methods.

Active Validation

Interactive prototype tested against real-world usability. Social media literacy classes for tweens with parental participation, generating qualitative evidence on framework legibility, rights comprehension, and human-layer governance understanding.

v1.2 / v2.0 — In Development

Incorporating feedback from v1.1 expert review cycle, prototype testing findings, and tween validation sessions. Forthcoming publication: "Designing for Context, Not Control: A Rights-Aligned Interaction Model for Transparent Digital Governance," IHCI 2026.

STOA demonstrates that this infrastructure can be designed—precisely, technically, and with sufficient rigor—for simultaneous evaluation by protocol engineers, legal scholars, and civil society practitioners. It demonstrates that a design science approach can produce a contribution of this scope and specificity in six months, without institutional backing, because the methodology provides the structure that institutions typically provide.

When institutional pilots were unavailable, the validation moved in two directions simultaneously: a Figma Make prototype that tested the reasoning framework at the interface layer, and social media literacy classes that tested it at the human comprehension layer with the most demanding available audience. Neither was a compromise. Both were the most direct available tests of whether the transparency architecture works where it ultimately has to function.

This work also demonstrates something the portfolio's client case studies cannot: that the commitment to making AI systems accountable, transparent, and genuinely safe for the people they affect is not just a professional practice — it is a considered position, independently pursued, about what this technology requires in order to be responsibly deployed at the scale at which it is being deployed.

Next
Next

Designing a Staffless Retail Operating System