OSE Reality Filter

From Open Source Ecology
Jump to navigation Jump to search

OSE Reality Filter

The OSE Reality Filter is a standard for evaluating ideas, technologies, partnerships, and proposals.

Its purpose is to keep Open Source Ecology aligned with tangible results, open collaboration, economic sense, and civilization-scale transformation.

OSE welcomes creativity, but creativity must be grounded in physical reality, economic reality, scaling reality, and open-source replicability.

Core Principle

An idea is not ready for serious OSE consideration until it can be explained with numbers, compared to the best known alternative, and shown to have a plausible path to open replication.

Good intentions are not enough.

Excitement is not enough.

Aesthetic appeal is not enough.

The question is:

Does this produce real, measurable, scalable, open-source value?

The Five Gates

1. Physical Reality

Every proposal must include basic physical accounting.

Required questions:

  • What are the material inputs?
  • What are the energy inputs?
  • What are the outputs?
  • What is the conversion efficiency?
  • What is the mass balance?
  • What is the energy balance?

If the basic physics are unclear, the proposal is not ready.

2. Economic Reality

Every proposal must include basic economic accounting.

Required questions:

  • What does it cost to build?
  • What does it cost to operate?
  • What is the cost per unit output?
  • What is the labor requirement?
  • What is the maintenance requirement?
  • What is the payback time?
  • What is the comparison to the current best alternative?

If the economics are unclear, the proposal is not ready.

3. Scaling Reality

Every proposal must explain what happens at larger scale.

Required questions:

  • What breaks at 10x scale?
  • What breaks at 100x scale?
  • What breaks at 1000x scale?
  • Is the feedstock abundant enough?
  • Is the labor model scalable?
  • Is the land area realistic?
  • Is the supply chain realistic?

If the system cannot scale, it may be useful as a local experiment, but it is not a core civilization-scale solution.

4. Comparative Advantage

Every proposal must compare itself to the strongest known alternative.

Required questions:

  • Why this instead of the best existing solution?
  • What category is this actually competing in?
  • Is it an energy solution, soil solution, housing solution, manufacturing solution, governance solution, or education solution?
  • Does it outperform the benchmark?
  • If it does not outperform the benchmark, what strategic reason justifies it?

A technology may be useful in one category and weak in another.

For example, biochar may be useful as a soil amendment, but that does not automatically make biomass pyrolysis a strong primary energy strategy.

5. Openness and Replicability

Every proposal must be compatible with open-source civilization building.

Required questions:

  • Is the design open source?
  • Are the plans, data, schematics, and build instructions public?
  • Can ordinary builders replicate it?
  • Can it be built with common tools?
  • Can it be repaired locally?
  • Can it be improved by a global collaborative community?
  • Is it free of proprietary lock-in?

If the system is a black box, it is not aligned with OSE core strategy.

Decision Categories

Core

A Core proposal passes the Five Gates and has strong potential for scalable, open-source, economically significant transformation.

Core proposals may receive serious attention, design time, build time, funding, and recruiting effort.

Experimental

An Experimental proposal is promising but incomplete.

It may have useful potential, but it still needs stronger numbers, prototypes, documentation, or comparison to alternatives.

Experimental proposals may receive limited resources.

Parked

A Parked proposal is not rejected as worthless, but it is not ready for OSE focus.

Reasons may include:

  • no numbers
  • weak economics
  • unclear scaling path
  • proprietary design
  • no comparison to alternatives
  • category confusion
  • excessive complexity
  • poor fit with OSE priorities

Parked ideas may be revisited if stronger evidence becomes available.

Culture Standard

OSE culture is friendly to imagination but disciplined by reality.

The standard is:

Show the numbers.

Compare to the best alternative.

Explain the scaling path.

Make it open source.

Produce tangible results.

Self-Test for Proposing an Idea

Before proposing an idea for OSE consideration, answer the following questions.

1. What is the claim?

What exactly are you proposing?

What problem does it solve?

What output does it produce?

2. What category is it in?

Choose the main category:

  • energy
  • housing
  • food
  • soil
  • manufacturing
  • materials
  • transportation
  • education
  • governance
  • finance
  • other

Do not mix categories without explaining the difference.

3. What are the three most important numbers?

Provide at least three numbers.

Examples:

  • cost per unit
  • energy per unit
  • labor hours
  • land area
  • throughput
  • efficiency
  • payback time
  • material quantity
  • production rate

If you cannot provide three numbers, the idea is not ready.

4. What is the best alternative?

What is the strongest existing solution?

Why is your proposal better?

If it is not better, why should OSE still consider it?

5. What is the scale path?

What does this look like at:

  • one unit
  • 10 units
  • 100 units
  • 1000 units

What breaks first?

What becomes expensive?

What becomes scarce?

6. What is the open-source path?

Can the system be fully documented?

Can it be built by others?

Can it be repaired locally?

Can it be improved by a distributed community?

Is any critical part proprietary?

7. What tangible result will be produced?

What can be built, tested, measured, sold, replicated, or taught?

What is the concrete deliverable?

8. What would falsify the idea?

What result would show that the proposal is not worth pursuing?

Examples:

  • cost is too high
  • efficiency is too low
  • labor requirement is too high
  • feedstock is too limited
  • system is too complex
  • proprietary dependency cannot be removed
  • benchmark alternative is clearly better

Minimum Proposal Template

Use this template for new proposals.

Proposal Name

Name:

Proposer:

Date:

Summary

One paragraph summary:

Problem Solved

What problem does this solve?

Category

Primary category:

Secondary category, if any:

Three Key Numbers

Physical Inputs and Outputs

Inputs:

Outputs:

Energy balance:

Mass balance:

Economics

Build cost:

Operating cost:

Cost per unit output:

Labor requirement:

Payback time:

Best Alternative

Benchmark alternative:

Comparison:

Why this proposal is better or strategically useful:

Scaling Analysis

At 1 unit:

At 10 units:

At 100 units:

At 1000 units:

Main scaling bottleneck:

Open-Source Replicability

Documentation path:

Tools required:

Materials required:

Repairability:

Proprietary dependencies:

Tangible Deliverable

What will be produced?

How will it be tested?

How will success be measured?

Decision

Core / Experimental / Parked

Reason:

Next step: