Janus Facing Applications: Addressing the Red Queen Race in Information Economics

Network Theory Applied Research Institute

Document ID: P3-011

Version: 1.0

November 2025

Abstract

Platform applications maintain power through information asymmetry—they create separate interfaces for different user classes while obscuring the relationships between them [i.e. DoorDash Dasher (for drivers), DoorDash Order Manager (for restaurants), and the DoorDash customer app (for customers)]. We propose "Janus Facing Applications" (JFAs): a framework replacing siloed interfaces with transparent, multi-role architectures where all participants access complete system information. Drawing on Acemoglu and Robinson's concept of the "Janus-faced" state from The Narrow Corridor and applying contemporary metacommunication theory, JFAs enable communities to operate coordination platforms cooperatively without information asymmetry. This enables democratic governance at platform scale.

1. The Problem: Information Asymmetry as Architectural Feature

1.1 Contemporary Metacommunication Theory: The Architectural Foundation

Modern communication theory has evolved significantly beyond mid-20th century frameworks, yet the fundamental insights about how communication constructs power relationships remain central. Drawing on Watzlawick, Bavelas, and Jackson's (1967) foundational work on the pragmatics of human communication, contemporary scholars emphasize that all communication operates on multiple simultaneous levels:

Content/Relationship Distinction:

Every communication carries both:

• Content dimension: The literal information the message conveys

• Relationship dimension: Meta-information about the relationship between communicators that determines how receivers should interpret the content

The relationship dimension frames the content—it provides the interpretive context through which receivers understand all information. The same content message means something entirely different when speakers communicate it between peers versus between hierarchically positioned parties. The relationship dimension is metacommunicative: it's communication about how to interpret the communication.

Symmetrical vs. Complementary Relationship Structures:

Communication systems construct two fundamental types of relationships:

• Symmetrical relationships: Based on equality, where participants have equivalent access to information and decision-making power

• Complementary relationships: Based on difference, where one party occupies a superior position and the other a subordinate position

Complementary relationships aren't inherently problematic—mentor-student, expert-novice, or care provider-recipient relationships serve important functions. However, when complementary relationships become rigid and unchangeable, they create communication pathologies where the subordinate party cannot challenge the relationship structure itself.

Architectural insight: Communication systems don't just transmit content—they construct and enforce relationship structures through what information they make accessible to which participants. When a platform grants asymmetric access to system-level information (economics, algorithms, comparative data), it architecturally enforces a complementary relationship where the platform operator occupies the permanent superior position.

Platform participants cannot challenge this structure because they lack access to the metacommunicative level—the relationship-defining information itself. This creates what contemporary scholars term "structural paradox": the platform tells participants they're independent agents or valued partners (content level) while the architecture simultaneously communicates their subordinate position (relationship level) by withholding system information.

1.2 Structural Verification

Contemporary platforms structure fees and payments across multiple categories with language emphasizing variability and discretion. Fee documentation typically includes phrases like "may apply," "subject to change," "varies by location," and "depends on demand"—language that prevents verification even in principle.

The fundamental problem: No participant can verify claims or understand the complete transaction. Consider what each participant class actually sees:

A consumer initiating a transaction sees:
├─ Base cost: [amount]
├─ Service Fee: [variable by undisclosed factors]
├─ Coordination Fee: [percentage that "may increase"]
├─ [Potentially] Additional charges based on context
└─ Total: Unknown until late in process, varies between transactions

The consumer cannot know:
• How much the service provider receives
• How other stakeholders receive compensation
• What factors determine variable fees
• Whether fee structures changed since previous transactions
• How value distributes among local vs. platform entities

The service provider sees:
├─ Task offer: [compensation for specified work]
├─ [After acceptance] Full transaction details

The service provider cannot know:
• Consumer's total payment
• How the platform calculated compensation
• What portion represents different payment categories
• How other stakeholders' compensation affects economics
• Whether offer amounts adjust based on acceptance patterns

Additional stakeholders see:
├─ Transaction notification
├─ Their portion: [percentage or fixed amount]

These stakeholders cannot know:
• Complete payment flows
• Why their compensation has specific structure
• What platform operating costs actually are
• Whether other participants understand the economics
• How to verify platform claims about cost structures

The architectural feature: Designers built this opacity into separate application interfaces. Each participant class receives exactly enough information to complete their role and insufficient information to verify platform claims, negotiate collectively, or build alternatives.

The hidden information functions as the relationship dimension (metacommunication)—it classifies how receivers should interpret the content. The platform's systematic withholding of system economics communicates the relationship structure: "You occupy a subordinate position where you must trust undisclosed calculations." The architecture enforces complementary relationships where verification becomes structurally impossible.

Service providers cannot "take the role of the other" (Mead, 1934)—they cannot see how consumers or other stakeholders experience the same transaction. The architecture prevents the shared understanding necessary for recognizing common interests and coordinating collective action.

Janus Facing Architecture transforms this completely:

All participants see identical transaction breakdown:

Consumer payment: [total amount]
├─ Primary cost: [amount] → Recipient A receives: [amount]
├─ Service delivery: [amount] → Recipient B receives: [amount]
├─ Platform operations: [percentage] → Covers operational costs
│   ├─ Infrastructure: [amount]
│   ├─ Transaction processing: [amount]
│   ├─ Development: [amount]
│   └─ Overhead: [amount]
└─ Optional gratuity: [amount] → Recipient B receives: [amount]

The platform makes operations breakdown visible to all:
• Monthly infrastructure: [fixed cost serving transaction volume]
• Transaction processing: [per-transaction cost]
• Development cooperative: [transparent labor costs]
• Insurance and reserves: [shared cost basis]

Algorithmic transparency:
• Matching logic: [documented, deterministic]
• No hidden variable pricing factors exist
• Flat operational cost structure
• The platform publishes all calculation methods

Democratic governance:
• Any participant can propose changing cost structures
• Regular votes with complete financial modeling
• All platform costs become auditable in real-time
• Members decide surplus allocation collectively

The transformation: Moving from complementary (hierarchical, verification impossible) to symmetrical (equal, verification built-in) relationships. Participants can switch between roles and verify all claims because the architecture provides complete information access to all parties. The relationship dimension shifts from "trust our authority" to "you are peers in governing this infrastructure."

Economic advantage: The community can redistribute value retained within transactions through democratic governance as: higher compensation for service providers, lower costs for consumers, improved quality across the system, or community reinvestment. Value circulates locally rather than extracting to distant shareholders.

1.3 Why "Janus Facing"?

In The Narrow Corridor (2019), Daron Acemoglu and James Robinson describe the state as inherently "Janus-faced"—it simultaneously enables collective action while potentially becoming an instrument of oppression. Like the Roman deity Janus who looked in two directions, the state must be both powerful (to coordinate) and accountable (to prevent tyranny).

Liberty exists when state capacity and societal capacity to check power evolve together. When power evolves faster than checking capacity, liberty erodes.

The same dynamic applies to digital platforms: Current platforms coordinate economic activity (enabling face) while extracting value through information asymmetry (exploitative face). The architectural challenge: how do we build platforms that retain coordinating power while eliminating exploitative capacity?

Janus Facing Applications are platforms that simultaneously face toward multiple user roles while maintaining complete transparency for all participants—powerful enough to coordinate, transparent enough to prevent capture.

2. Janus Facing Architecture: Core Principles

2.1 Four Architectural Transformations

1. Multi-Role Unified InterfaceAll user classes access the same application with role-appropriate views, not separate siloed apps. Users can switch roles with a single click.

2. Complete Information TransparencyThe system makes system-level data (matching algorithms, pricing structures, platform economics) visible to all participants. No privileged information access exists.

3. Reversible Role Assignment (Prosumer Capability)Users can switch between or simultaneously occupy multiple roles: consumer, producer, service provider, investor, platform governor.

4. Integrated Democratic GovernanceTransparency enables informed decision-making. All participants vote on platform rules, fee structures, and policies with complete understanding of implications.

2.2 The Metacommunication Shift

Every platform architecture communicates on multiple levels simultaneously:

Level 1 - Explicit Functionality: "This interface element performs this action"

Level 2 - Implicit Relationships: Separate interfaces communicate "You are different classes with different rights"

Level 3 - Power Structure: Hidden information communicates "Platform operators make decisions"

Level 4 - System Nature: Proprietary code communicates "This is a product you use, not infrastructure you govern"

Platform interfaces don't just convey information—they construct and maintain power relationships between participant classes. Metacommunication (communication about how to interpret communication) shapes understanding of social systems.

Participants develop understanding through imagining how others perceive them and the system. When platforms create separate interfaces, participants cannot understand how other user classes experience the system, preventing the shared understanding necessary for collective action.

Concrete Example of Metacommunicative Transformation:

When a service provider in a traditional platform sees "Task available," the explicit message (Level 1) is functional. But the interface's refusal to show complete transaction economics until after commitment communicates (Level 3) "The platform controls information access based on your compliance." The provider cannot see other participants' perspectives, and other participants cannot see the provider's constraints. No one can verify the platform's claim that matching is optimal.

In a Janus Facing application, the same task displays complete information: all compensation amounts, all fee structures, recipient allocations, and matching rationale.

The metacommunication shifts completely:

• Level 2: "You are peers with complete information" (not subordinates with controlled access)

• Level 3: "You can verify claims and coordinate alternatives" (not "trust our authority")

• Level 4: "This is infrastructure you collectively govern" (not "this is our proprietary system")

The service provider now understands other participants' experiences, complete value flows, and platform overhead. This shared understanding enables taking "the role of the other"—participants can imagine others' perspectives because the architecture makes those perspectives mutually visible.

Janus Facing Applications transform all four levels:

Level 1: Role-specific interfaces + transparent system informationLevel 2: The unified app communicates "You are participants in a shared system"Level 3: Distributed information communicates "All participants contribute to decision-making"Level 4: Open-source AGPL-3 communicates "This is infrastructure you govern collectively"

The architectural transformation changes not just information flow, but what the information flow itself communicates about participants' relationship to the platform. This is why cooperative ownership without architectural transformation struggles to achieve its democratic potential—the metacommunication of information asymmetry maintains power concentration regardless of formal ownership structure.

3. Implementation Through Clean-Room Development

Municipalities seeking to deploy platform cooperatives face a practical problem: the coordination platforms their residents need—ridesharing, delivery, housing, care services—exist only as proprietary corporate applications. Simply copying these platforms would violate copyright law. Building from scratch requires duplicating years of development work and user experience refinement.

Clean-room reverse engineering solves this dilemma. It's a legal methodology for recreating software functionality without accessing or copying the original source code. The process works by strictly separating observation from implementation: one team documents what the application does (observable features and behaviors), while a completely separate team builds a new implementation based solely on those specifications, never seeing the original code. Courts have consistently upheld this methodology as creating legally independent work.

For platform cooperatives, clean-room development serves as a renovation method—it enables municipalities to recreate essential coordination applications that don't yet exist in the public domain, release them under AGPL-3 as permanent commons, and add the transparency features that transform extractive platforms into democratic infrastructure. Each successful implementation strengthens the entire cooperative movement rather than creating new proprietary silos.

This methodology protects cooperatives from legal challenges that could destroy platforms before they achieve scale, while simultaneously preventing corporate enclosure of community-developed tools.

3.1 Legal Framework

Clean-room reverse engineering creates legally independent implementations:

Step 1 - Specification Team: Documents observable functionality, no implementation details

Step 2 - Copyright Review: Verifies specifications contain no proprietary elements

Step 3 - Implementation Team: Builds from specifications only, never sees original code

Step 4 - Janus Facing Expansion: Adds multi-role interface, transparency, and governance tools

This methodology ensures legal compliance while enabling architectural transformation from information asymmetry to transparency.

Patent Considerations

While clean-room methodology addresses copyright concerns, it does not inherently protect against patent infringement. Patents protect functionality (what the system does) rather than expression (how developers write code), meaning a clean-room implementation can still infringe patents if it reproduces patented methods.

Common Platform Patents:

• Matching algorithms (e.g., optimization methods for pairing service providers with consumers)

• Dynamic pricing mechanisms (surge pricing, demand-based fee adjustment)

• Reputation and rating systems (specific scoring methodologies)

• Route optimization and logistics coordination

• Real-time tracking and notification systems

Mitigation Strategies:

1. Patent Landscape Analysis: Before development begins, teams conduct thorough patent searches in relevant jurisdictions to identify existing patents covering target functionality. Tools like Google Patents, USPTO database, and professional patent searches can identify potential conflicts.

2. Design-Around Development: When teams identify patents, they implement alternative methods that achieve similar outcomes through different technical approaches. For example:

   • If someone patented proximity-based matching with specific optimization criteria, developers use different optimization objectives (environmental impact minimization, workload balancing)

   • If someone patented dynamic pricing algorithms, developers implement transparent fixed-rate or democratically-determined pricing structures

   • If someone patented specific reputation scoring methods, developers create alternative evaluation frameworks

3. Defensive Publication: Teams document and publicly disclose novel coordination methods, algorithmic approaches, and governance mechanisms they develop for JFAs. This creates prior art that prevents others from later patenting these methods and establishes freedom to operate.

4. Patent Pool Participation: Cooperatives can form patent pools or join existing ones (like Open Invention Network for software) where members cross-license patents, creating patent-free zones for cooperative platform development.

5. Geographic Considerations: Patent rights are territorial—a patent granted in one country doesn't apply in others. Teams may reduce risk through initial deployments in jurisdictions with fewer relevant patents or stronger fair use provisions.

6. Functional Differentiation: JFAs' fundamental architectural differences (multi-role interfaces, complete transparency, democratic governance) often require functionally different implementation approaches that naturally avoid infringing specific patented methods that designers created for opaque, hierarchical systems.

JFA Advantage:

Transparency requirements actually support patent avoidance. When all algorithmic logic must receive documentation and democratic approval, platforms naturally develop simpler, more explainable coordination methods rather than complex proprietary algorithms that might be patented. Democratic governance processes tend toward transparent matching rules (geographic proximity, chronological queuing, member preference) rather than opaque optimization functions.

Additionally, the architectural expansion to multi-role transparency often requires novel technical implementations that constitute genuinely different methods—not merely reproductions of existing approaches. The shift from information asymmetry to symmetry necessitates different data structures, interface architectures, and coordination mechanisms.

Risk Assessment:

Patent risk varies significantly by:

• Platform type: Logistics and matching platforms face higher patent density than payment processing or marketplace platforms

• Jurisdiction: US has more platform-related patents than most other jurisdictions

• Implementation specifics: Novel approaches to transparency and democratic governance are less likely to conflict with existing patents that designers created for extractive platforms

Recommended Approach:

For each JFA implementation:

1. Teams conduct targeted patent searches for the specific platform type and core functionality

2. Teams document design decisions showing independent development and functional differentiation

3. Teams prioritize transparent, democratically-governed coordination methods that differ from patented optimization algorithms

4. Teams engage patent counsel for high-risk implementations (especially in logistics and dynamic pricing domains)

5. Teams contribute innovations to defensive publication databases

This multi-layered approach addresses patent concerns while maintaining the architectural transformation goals central to JFAs.

3.2 Janus Development

Traditional clean-room reproduces existing functionality:

• Consumer interface → consumer interface (equivalent)

• Provider interface → provider interface (equivalent)

• Stakeholder interface → stakeholder interface (equivalent)

• Result: Multiple separate interfaces, same information asymmetry

JFA clean-room expands functionality architecturally:

• Multiple siloed interfaces → Unified platform with role-switching

• Hidden system logic → Transparent algorithms and economics

• Separate user classes → Prosumer fluidity

• Centralized control → Distributed democratic governance

• Result: Single application, complete transparency, cooperative capability

The expansion doesn't violate copyright because it creates functionality that didn't exist in the original system.

3.3 AGPL-3 as Structural Protection

NTARI publishes all clean-room implementations under AGPL-3 (GNU Affero General Public License) to prevent recapture:

Key Protections:

• Network copyleft: Developers must release modifications to network services under AGPL-3

• Viral sharing: Incorporating AGPL-3 code requires releasing the entire platform under AGPL-3

• Irrevocable commons: Code remains in commons permanently

For Cooperatives:

• Prevents corporate acquisition and enclosure

• Enables federation (multiple municipalities share codebase)

• Discourages corporate competition (cannot incorporate without opening entire platform)

• Protects community investment in commons

AGPL-3 creates an "immune system" against corporate capture—architectural protection for democratic infrastructure.

4. JFA-Specific Definitions

Beyond standard open-source development practices, JFAs require four architectural features that distinguish them from conventional platforms:

4.1 Multi-Role Unified Identity

JFA systems must maintain unified data models supporting simultaneous role occupancy. A single user identity enables holding multiple roles (consumer, provider, stakeholder, governor) without separate accounts. All role-related permissions and views derive from this single identity. Role switching must require only a single interaction (one click/tap) with no logout or re-authentication. The interface must clearly indicate current role and make all available roles immediately accessible.

Why this matters: Conventional platforms architecturally separate user classes to maintain information asymmetry. Unified identity enables "taking the role of the other" (Mead, 1934)—participants can experience the system from multiple perspectives, building shared understanding necessary for democratic coordination as envisioned by platform cooperativism advocates (Scholz & Schneider, 2016).

4.2 Complete Transaction Transparency

Transaction records must capture and expose complete economic breakdowns visible to all participants in real-time:

• All value flows (to all recipients, amounts, and rationale)

• Complete fee structures (what each fee covers, calculation methods)

• Platform operational costs (infrastructure, processing, development, reserves)

• Matching algorithm used (version number, human-readable rationale, alternatives considered)

Every transaction links to algorithmic documentation. Platform cost structures update in real-time and remain visible to all participants. All system-level information must be accessible through public APIs (authenticated but universally available to members).

Why this matters: Transparency eliminates the architectural impossibility of verification. When participants can verify all claims, information asymmetry cannot maintain power concentration.

4.3 Embedded Democratic Governance

Governance capabilities must be embedded within functional interfaces, not isolated in separate administrative systems:

• Proposal systems include integrated financial impact modeling visible to all members

• Voting mechanisms accessible from any role view

• Implementation status and outcomes tracked and publicly visible

• All matching and coordination algorithms approved through democratic governance processes

• Algorithmic decisions logged for governance review and system improvement

Why this matters: Separating governance from operations maintains the complementary relationship structure. Embedding governance in functional interfaces communicates "you govern this infrastructure" at every interaction.

4.4 Federation Architecture

Technical architecture must support federation—multiple independent instances sharing protocol standards and optionally sharing data:

• Local instances retain full autonomy while benefiting from network effects

• Protocol standards enable cross-instance coordination without centralized control

• Open protocols published under AGPL-3 prevent enclosure

• Interoperability prevents winner-take-all dynamics from recreating monopolies

Why this matters: Federation enables cooperative networks to achieve scale while preventing power consolidation. This is the architectural answer to "platform cooperatives can't compete at scale"—they don't compete individually, they federate.

5. Research Agenda

5.1 Critical Questions

Economic:

• What actual local multiplier effect occurs when value remains within communities?

• How do cooperative customer acquisition costs compare to venture-funded platforms?

• What operational efficiency differences emerge from transparency?

• How does democratic governance affect platform adaptation speed?

Governance:

• What participation rates do members achieve in democratic governance?

• How does transparency affect governance quality and member satisfaction?

• What decision-making structures work best at different scales?

• How do federated platforms coordinate governance across localities?

Technical:

• Which transparency features do members actually use and value?

• How can federated platforms maintain coordination without centralized control?

• What technical barriers prevent or enable adoption?

• How does open-source development affect platform security and reliability?

Social:

• How does cooperative ownership affect participant dignity and satisfaction?

• What cultural factors enable or inhibit adoption?

• How do communities transition from extractive to cooperative platforms?

• What educational frameworks support democratic platform governance?

6. Conclusion: Establishing Information Liberty

Platform capitalism extracts substantial value through architectural choices that create information asymmetry. Cooperative ownership alone cannot solve this—member-owned platforms with siloed interfaces still concentrate power through information control. Liberty depends on maintaining balance between coordination capacity and checking capacity. When platforms evolve faster than participants' understanding, liberty erodes toward algorithmic authoritarianism. Democratic institutions must evolve at the speed of platform technology or freedom diminishes.

Janus Facing Applications offer the architectural alternative: transparent, multi-role platforms where information symmetry enables genuine democratic governance. The technical capacity exists. Legal frameworks are established. The economic case is clear. What remains is building first implementations, proving the model, and catalyzing transition from platform capitalism to platform cooperation.

NTARI's clean-room development of Janus Facing Applications under AGPL-3 creates permanent commons—infrastructure communities can deploy, modify, and govern democratically without fear of enclosure. Municipalities can enable transition through seed funding, procurement preferences, and regulatory clarity. Cooperatives can adopt replicable templates, with early adopters accelerating movement-wide transition. Developers can innovate in architectural transparency, implementing democratic infrastructure that doesn't exist in proprietary platforms. The goal is not better applications but fundamentally different economic architecture that distributes power rather than concentrating it.

Like Janus looking simultaneously to past and future, Janus Facing Applications look to coordination and accountability—powerful enough to organize complex economic activity, transparent enough to prevent capture and extraction. This is infrastructure for the narrow corridor. This is liberty at platform scale.

References

Acemoglu, D., & Robinson, J. A. (2019). The Narrow Corridor: States, Societies, and the Fate of Liberty. Penguin Press.

Mead, G. H. (1934). Mind, Self, and Society: From the Standpoint of a Social Behaviorist. University of Chicago Press.

Scholz, T., & Schneider, N. (Eds.). (2016). Ours to Hack and to Own: The Rise of Platform Cooperativism, A New Vision for the Future of Work and a Fairer Internet. OR Books.

Watzlawick, P., Bavelas, J. B., & Jackson, D. D. (1967). Pragmatics of Human Communication: A Study of Interactional Patterns, Pathologies, and Paradoxes. W.W. Norton & Company.

Contact: info@ntari.org

"When the work is done and their aim fulfilled, the people will say, 'We did it ourselves.'" — Tao Te Ching, 17

"Liberty does not emerge from a vacuum... It is the result of a continuous struggle to balance power between state and society." — Acemoglu & Robinson