OSE Classes

Applying the State change loop to MetaPolls

Coordination systems may fail because they treat all decisions as if they're the same. They're not. A decision about whether your city should be able to get anyone anywhere using public transportation in under 20 minutes is fundamentally different from a decision about whether to use buses or light rail, which is different from a decision about which contractor should build it and when.

Intro to OSE Classes

Not all options are dealing with the same kinds of information, OSE Classes provide a systematic way to recognize these differences.

Being mindful of the classes helps creators to match the options they write to their intended audience, which should help their MetaPoll be more accessible to the target audience and the contributors who read the results. Ultimately this leads to greater impact for the organization.

Every MetaPoll option gets classified into one of these buckets:

• O-class (Outcome) - What success looks like

• S-class (Strategy) - How to achieve it

• E-class (Execution) - Who does the work and when

Required knowledge level of each class

Consider the difference between these three statements:

• "Our city needs 20 minute public transportation" (O-class)

• "We should build a light rail system" (S-class)

• "Metro Construction Corp should build 15 miles of track starting January 2026" (E-class)

Each requires different knowledge to evaluate meaningfully.

1. O-class requires only understanding your transportation needs.

2. S-class requires expertise in urban planning and transportation systems.

3. E-class requires detailed knowledge of construction capabilities, local regulations, and project management.

By labeling choices this way, creators can keep high-level goals, tactical methods, and concrete implementation details cleanly separated.

Matching to participant knowledge

Here's where the OSE framework reveals something worth highlighting: not all input is equally valuable for all types of decisions.

O-class options are genuinely democratic—they require no specialized knowledge beyond understanding your own needs and values. Anyone can meaningfully evaluate whether they want "a safe place for children to play" or "reduced traffic in residential neighborhoods."

But S-class and E-class decisions operate differently. Evaluating whether to use permeable pavement versus traditional asphalt (S-class) requires understanding drainage engineering and maintenance costs. Deciding which construction crew to hire (E-class) requires knowledge of their track record and capacity.

A primary goal of matching expertise to the option class is what we'll call "cognitive load matching"—a MetaPoll creator design goal that: participants should only need to engage with the level of complexity they're equipped to handle, while still maintaining democratic input where it matters most.

The value of OSE

Consider the alternative: asking a plumber for their opinion on server infrastructure (S-class), or asking a network engineer about pipe routing (S-class). Both are skilled professionals, but their expertise doesn't transfer. The plumber's vote on servers isn't more democratic—it's just less informed.

The OSE framework preserves democratic participation where democracy works best (O-class) while channeling specialized knowledge where technical expertise matters (S and E-classes).

OSE is a win win win for everyone.

1. Voters have less cognitive load and spend less time voting.

2. Contributors get clearly defined outcomes without contaminated strategy and execution guesses from non-expert voters, allowing them to plan and execute well.

3. Because of the state change loop, the organization gets higher quality output execution, leading to better results and potentially greater community value creation.

Having established why OSE classification matters, let's examine each class in detail.

1. Desired Outcomes (What and Where)

The first and most fundamental part of the loop concerns what outcome we want to achieve. These options focus purely on goals or end states, deliberately excluding implementation details.

For example:

Valid O-class form ✅	Invalid O-class form ❌
"I want to get across this river"	"I want to build a bridge to cross the river"
"Our community should have clean drinking water"	"we should hire ABC company to deliver clean drinking water"
"The protocol should be resistant to MEV attacks"	"we can code in a slashing mechanism to punish MEV"

Outcome decision-making has several important properties:

1. Maximum inclusivity - It requires no specialized knowledge beyond understanding one's own preferences

2. High alignment potential - People often agree more about outcomes than implementation methods

3. Implementation flexibility - By not specifying means, it allows for creative, efficient solutions

4. Evaluation potential - Stakeholders can check to verify if the outcome has been achieved

The key insight here is separating pure goals from implementation guesses.

Consider how different "I want to cross the river" is from "I want to build a suspension bridge to cross the river." The latter pre-commits to a specific solution that might be suboptimal - what if the river is narrow enough to jump across? What if the soil can't support bridge foundations? What if the voter has a jetpack? By focusing purely on the outcome, we maximize solution space.

One frequent failure mode in governance is when outcome preferences get contaminated with implementation assumptions. This prematurely narrows options and often leads to inefficient choices driven by voter preferences about things they lack expertise to evaluate.

2. Strategies and Tactics (How)

The second part of the loop concerns how we achieve our desired outcomes. These options focus on methods, approaches, and techniques. They almost always require specialized skills, experience or knowledge.

For example, if we polled the general population on how to construct a nuclear power plant, and strictly followed whatever the results were, would this be a good or bad idea?

(Democratically designed power plants aren't a thing because you need engineering skills to be able to have valuable input.)

For example:

Valid S-class form ✅	Invalid S-class form ❌
choosing a bridge vs. ferry vs. helicopter choice for river crossing	"the bridge must be completed in 8 months"
Should we acquire users primarily through SEO traffic or traditional advertising?	"User acquisition must grow by 35% annually"
Should the consensus mechanism be Proof-of-stake or proof-of-work?	" what should the node operator onboarding budget be?"

S-class decision-making has different properties:

1. Expertise-dependent - Requires domain-specific knowledge to evaluate effectively

2. Comparative analysis - Involves technical trade-offs between different approaches

3. Context sensitivity - Often depends on specific local conditions, feasibility should be verified

The "how" layer should ideally be reserved for people with relevant expertise. If we want to determine what type of bridge is best for a particular river crossing, this decision should primarily involve civil engineers familiar with bridge construction under various conditions.

Having general populations vote on technical implementation details often leads to suboptimal outcomes based on superficial understanding.

More examples:

• Should a DeFi protocol implement automated market makers or order books?

• Should a city address traffic through congestion pricing, expanded public transit, or improved traffic signal coordination?

• Should an organization prioritize growth through geographic expansion or product diversification?

Unlike O-class decisions where anyone can meaningfully evaluate their own preferences, S-class choices demand understanding of technical constraints, implementation costs, and downstream consequences.

The key point is that while communities should collectively determine what outcome they want to achieve, the question of how best to achieve the outcome often benefits from specialized knowledge and professional experience.

S-class options represent the crucial middle layer where broad community goals get translated into actionable strategies—too concrete to be pure outcome preferences, but too abstract to specify exact implementation details.

3. Execution Parameters (Who and When)

The third part of the loop concerns who will implement our chosen strategies and when they will do so. These options focus on specific execution details:

Valid E-class form ✅	Invalid E-class form ❌
Hire ABC company to rewire basement	Rewire basement with 16-gauge wire
Bridge constructed from March-August	Smooth traffic flow across the river
35% of treasury in stable coins	Treasury can always meet payroll

• Operational specificity - Concrete implementation details (team size, timelines, resource allocation)

• Accountability specification - Define who delivers what by when, with measurable outcomes

• Implementation readiness - Translate directly into actionable work assignments without further interpretation

Voters for E-class require:

1. Operational knowledge - Understanding of resource constraints and capabilities

2. Project management expertise - Familiarity with realistic timelines and dependencies

3. Local context - Awareness of specific implementation environments

4. Resource authority dependency - Require control over specific budgets, personnel, or assets to implement

E-class decisions are the most "boots on the ground" in terms of who can meaningfully participate, as they require intimate familiarity with the actual execution environment. Having distant stakeholders vote on detailed project timelines often leads to unrealistic expectations and failed delivery.

This presents an interesting governance challenge: how do we ensure appropriate expertise for "how" decisions while maintaining democratic principles? The general rule is: write a single MetaPoll for a target stakeholder's complete decision space.

If you're designing a community park, one MetaPoll captures O-class outcomes from residents—what amenities they want, how they'll use the space, what "good" looks like.

Separate MetaPolls handle S-class planning decisions (permeable surfaces vs. traditional concrete, native plantings vs. manicured landscaping) restricted to urban planners and landscape architects.

E-class execution choices (which contractors, what timeline, budget allocation) limited to project managers and other key stakeholders. Each poll automatically filters participants based on relevant expertise, ensuring democratic input on goals while channeling technical decisions to those equipped to evaluate them meaningfully.

Alternative Decision Hierarchy

The power of MetaPolls lies in their ability to separate these decision types hierarchically. Perhaps in the future a MetaPoll might evolve to a design where:

1. Allow broad participation in outcome-level decisions at higher layers.

2. Restrict strategy-class decisions to those with relevant expertise in the middle layers.

3. Delegate execution-class decisions to those responsible for implementation at the lowest layers.

This might be accomplished through token gating voting access (different voting tokens for the general community vs specialists) based on relevant skill, experience and merit, while still maintaining overall alignment with community desired outcomes.

The hierarchical structure of MetaPolls is flexible enough to map to this delegation pattern, allowing communities to make explicit choices about which types of decisions belong at which levels, and which participants should have influence over different layers of the decision tree.

🧑‍🎨 Design Principles for OSE Classes

Core Principle: Match Complexity to Expertise

The fundamental rule of OSE design is cognitive load matching—participants should only engage with decisions they're equipped to evaluate meaningfully.

The goal is a careful balance of optimizing both democratic participation and decision quality.

Give voters a real voice, but don't ask the voters how to build a rocket engine.

O-Class Design Principles

Maximize Accessibility

• Use language everyone can understand regardless of technical background

• Focus on verifiable goals rather than implementation details

Avoid Implementation Contamination

• Strip out "how" assumptions from outcome descriptions

• Don't bundle goals with specific methods ("clean water" not "reverse osmosis filtration system")

• Let the community define what success looks like without constraining solution space

Enable Meaningful Comparison

• Ensure options represent genuinely different end states

• Make trade-offs explicit where they exist

• Remember to apply semantic precision, outcomes can be concrete or abstract

S-Class Design Principles

Assume professional context

• Include technical details by adding nested options when necessary

• Use industry standard terminology without reservation (speak their language)

• When author is lacking in domain knowledge, get feedback from domain experts

Maintain Implementation Flexibility

• Focus on approaches and methodologies rather than specific vendors or timelines or trying to define the outcome (desired outcome should already be defined)

• Allow room for tactical adaptation during execution

• Balance specificity with operational latitude

• Don't contaminate by mixing execution or outcome into the options

Highlight Trade-off Dimensions

• Cost vs. performance, speed vs. security, flexibility vs. efficiency

• Let the tree structure reveal the trade-off space

E-Class Design Principles

Boots on the ground required

• Require intimate knowledge of current capacity and constraints

• Include only implementers and their direct managers

Use Concrete Metrics

• "6-month timeline" not "reasonable timeframe"

• "$150k budget" not "adequate funding"

• "Weekly standups" not "regular check-ins"

Account for Implementation Reality

• Consider current workload, competing priorities, and realistic capacity

• Align with actual procurement, hiring, and deployment processes

General OSE Guidelines

Temporal Coordination

• Allow outcome preferences to evolve while strategies and execution adapt

• Use MetaPoll's continuous signalling to track preference drift over time and anticipate changes

Use Symbols and Abbreviations Appropriately

• "$2M budget" not "Two million dollar budget"

• "Q1 2025" not "First quarter of 2025"

• "24/7 support" not "Round-the-clock customer support"

Strategic Truncation

• "Performance optimization strategies" → "Performance optimization"

• "User experience improvements" → "UX improvements"

• Let the context of nested options provide the missing detail. Higher level options are dynamically defined by the rankings of their nested children

Common Pitfalls to Avoid

Class Mixing

• Don't bundle outcome preferences with implementation assumptions (writing an O-class + S-class hybrid option is sloppy ❌)

• Avoid asking non-experts to evaluate technical trade-offs

• Resist the urge to let implementers override community outcome preferences

• Don't mix different classes of options on the same layer

False Precision

• Don't add unnecessary technical detail to inflate perceived sophistication

• Avoid over-specifying when genuine flexibility would be valuable

• Remember that concrete doesn't always mean better and vice versa

---

By matching decision types to appropriate expertise while maintaining democratic input where it matters most, we create coordination systems that are both more effective and more legitimate.

The result is governance that harnesses collective intelligence without drowning in collective confusion, enabling communities to tackle complex challenges that would overwhelm traditional decision-making approaches.

As our coordination problems grow more sophisticated, frameworks like OSE become essential infrastructure for human cooperation at scale. Realistically we're still in the early stages of understanding MetaPoll's real potential. Let's build and find out! 🏗️