OM World Self-Growth Engine v0.1

May 18, 2026 · View on GitHub

How Intent Realization Becomes Easier Over Time

Status: Genesis Draft Version: v0.1 Project: OM World Core Line: One Mind, One World.

0. Founder Principle

OM World exists for one reason:

To make intention easier to realize over time.

The core value of OM World is not governance. It is not judgment. It is not permission. It is not deciding which intentions deserve to exist.

The core value is this:

A person forms an intention, and the world begins to respond.

At the beginning, this may be slow, expensive, incomplete, and full of friction.

But as OM World grows, more intents are expressed, more realization paths are attempted, more tools are created, more execution traces are recorded, more patterns are reused, and more capabilities enter the network.

Over time, the same kind of intention should become easier, faster, cheaper, more reliable, and more natural to realize.

This is the self-growth engine of OM World.

One Mind, One World does not mean that every intention is instantly fulfilled from day one.

It means the world continuously learns how to respond to intention.

1. What OM World Is

OM World is a self-growing intent realization network.

It connects two sides:

Intent Demand — people, organizations, agents, or communities that express intentions.
Intent Realization Supply — tools, agents, compute, models, devices, humans, capital, data sources, and execution environments that help realize those intentions.

Every realization attempt creates experience.

Every experience can become a reusable pattern.

Every reusable pattern reduces future realization friction.

This is what turns OM World from a task marketplace into a world.

A marketplace ends when a task is completed.

A world grows when every completed task makes future tasks easier.

2. What OM World Is Not

OM World Core is not designed to judge intention.

It does not exist to decide:

which intentions are good;
which intentions are evil;
which intentions deserve to exist;
which intentions should be morally approved;
which world should be centrally preferred.

OM World Core is also not a traditional AI tool marketplace.

A tool marketplace connects users to tools.

OM World connects intentions to realization paths, and then stores the resulting patterns so that future intentions become easier to realize.

OM World is not merely:

User → Tool → Result

OM World is:

Intent → Path → Execution → Proof/Outcome → Pattern → Easier Future Realization

The final step is the difference.

Without pattern accumulation, OM World is only a service marketplace.

With pattern accumulation, OM World becomes a self-growing intent world.

3. The Two-Sided World

At the deepest level, OM World has two sides.

Intent Demand  ↔  Intent Realization Supply

All other roles are derived from this relationship.

3.1 Intent Demand

The demand side consists of anyone who forms and expresses an intention.

Examples:

"Help me recruit 5 Genesis builders."
"Find the best server for this workload."
"Generate a launch article."
"Audit this smart contract."
"Create a visual identity."
"Compare suppliers."
"Deploy this automation."
"Summarize this research field."
"Build a tool that does X."

The demand side does not want to understand protocol complexity.

It wants realization.

The ideal demand-side experience is:

I intend → the world responds

3.2 Intent Realization Supply

The supply side consists of all capabilities that can help realize intention.

This includes:

AI agents;
open-source tools;
APIs;
local devices;
LLM providers;
compute providers;
human experts;
automation scripts;
data sources;
models;
capital;
verifiers;
execution environments;
reusable patterns.

The supply side does not want complex integration.

It wants access to intent flow and a simple way to contribute capability.

The ideal supply-side experience is:

I provide capability → the world routes intent to me → I receive value when I help realize it

4. Invisible Complexity

The demand side should not feel the protocol.

Users should not be forced to manually understand:

intent schema;
mandate structure;
proof conditions;
settlement templates;
execution traces;
tool routing;
model selection;
compute allocation;
pattern updates.

Those mechanisms can exist underneath the surface, but they must be absorbed by infrastructure.

A user should increasingly experience OM World as:

Say the intention → receive the path → confirm only when necessary → get the result

This principle is called:

Invisible Complexity

The protocol may be complex internally.

The experience must become simple externally.

The more OM World matures, the less the user should need to know.

"无感" (zero perception) does not mean careless execution.

It means the system should only ask the user to intervene when intervention creates real value.

OM World should support progressive consent.

5.1 Low-risk intent

For low-risk, reversible, low-cost actions:

System can execute automatically under default user preferences.

Examples:

drafting text;
generating options;
comparing public information;
formatting files;
summarizing documents;
preparing unpublished artifacts.

5.2 Medium-risk intent

For medium-risk actions:

System asks for lightweight confirmation.

Examples:

publishing a post;
sending a message;
submitting a form;
opening an issue;
running a paid API call.

5.3 High-risk intent

For high-cost, irreversible, public, financial, or legally meaningful actions:

System requires explicit confirmation.

Examples:

spending funds;
signing transactions;
deleting data;
entering contracts;
executing trades;
publishing under a public identity.

The goal is not to remove user control.

The goal is to remove unnecessary friction.

The user should feel:

OM World knows when to act and when to ask.

6. Frictionless Supply

Intent realization supply must also be easy to join.

A tool creator should not need to build a full platform.

An agent builder should not need to solve user acquisition, payment, routing, proof, compute, and settlement alone.

A compute provider should not need to understand every intent type.

A human expert should not need to learn the entire protocol.

OM World should make supply-side contribution feel like publishing a capability.

6.1 Capability Declaration

A supply participant should be able to declare:

What can I help realize?
What input do I need?
What output do I produce?
What resources do I require?
What cost model do I use?
How should success be checked?

6.2 Example Tool Declaration

tool_id: genesis_builder_recruiter
intent_type: community_growth.recruit_builders
description: >
  Generates a recruitment article, X thread, GitHub issue plan,
  DM templates, and target contributor profile for early-stage protocol projects.
input:
  - project_description
  - target_builder_count
  - target_roles
  - existing_links
  - preferred_tone
output:
  - x_article
  - x_thread
  - github_issue_templates
  - dm_templates
  - target_profile_description
  - follow_up_plan
requires:
  - llm
  - optional_web_search
  - optional_design_model
compute:
  minimum: llm_api
  optional: local_node
proof:
  - artifact_hash
  - published_url_optional
  - user_acceptance_optional
settlement:
  template: fixed_payment_or_usage_based

This allows a creator to contribute a capability without building an entire application.

OM World should route intent to capabilities.

7. Every User Can Become a Node

In traditional platforms, users are mostly consumers.

In OM World, every user can become part of the world's realization supply.

A user may begin as an intent originator, but over time their device, feedback, tools, data, local context, and expertise can become part of the network.

This creates a two-sided flywheel:

More users → more intent demand
More users → more potential supply

This is structurally different from a normal platform.

In OM World, user growth increases both demand and supply.

8. Device Participation

Modern phones and computers are increasingly powerful.

They can become lightweight participants in the intent realization network.

OM World should support multiple levels of device participation.

8.1 Level 1 — Light Node

A phone or laptop can act as a light node.

It may contribute:

intent submission;
local preference storage;
public pattern caching;
lightweight feedback;
notification relay;
simple verification signals.

8.2 Level 2 — Local Execution Node

A personal computer can execute local tasks.

It may contribute:

file processing;
browser automation;
local scripts;
data cleaning;
lightweight model inference;
code execution;
local document transformation.

8.3 Level 3 — Compute Node

A stronger machine can provide compute.

It may contribute:

LLM inference;
image generation;
video generation;
embedding;
vector search;
simulation;
batch automation;
GPU workloads.

8.4 Level 4 — Expert Node

A human or organization can contribute specialized capability.

It may provide:

research;
audit;
design;
translation;
legal review;
financial analysis;
engineering;
operations;
community building.

The long-term goal is not only that users consume OM World.

The goal is that users become OM World.

9. The Core Asset: Pattern Library

The most important asset of OM World is not a token.

It is not governance.

It is not a single AI model.

It is the:

Intent Realization Pattern Library

A pattern is a reusable structure for realizing a class of intentions.

It captures:

what the user intended;
how the intent was interpreted;
which path was used;
which tools were called;
what resources were needed;
what proof or outcome was produced;
what cost and time were required;
whether the result was useful;
what failed;
what can be reused next time.

A pattern is the memory of the world.

Without patterns, every intent starts from zero.

With patterns, every new intent begins from accumulated experience.

10. Pattern Object

A minimal pattern object may include:

pattern_id: string
pattern_name: string
intent_type: string
creator: identity
input_requirements:
  - field
  - field
execution_graph:
  - step_id
  - capability_required
  - tool_options
  - compute_requirements
proof_condition:
  - artifact_hash
  - output_url
  - test_result
  - user_confirmation
  - external_signal
settlement_template:
  type: fixed_payment | milestone | bounty | success_fee | usage_based | staked_execution
historical_metrics:
  reuse_count: number
  success_rate: number
  median_cost: number
  median_time: number
  retry_rate: number
  user_satisfaction_optional: number
failure_modes:
  - failure_type
  - mitigation
derived_patterns:
  - pattern_id
status:
  draft | active | deprecated | forked

This is not merely metadata.

It is the world learning how to respond.

11. Pattern Reuse

When a new intent arrives, OM World should ask:

Have similar intentions been realized before?

If yes, it should retrieve relevant patterns.

The system may compare:

intent type;
constraints;
budget;
user context;
required output;
risk level;
available tools;
previous success rate;
time and cost history.

The result is not a forced path.

It is a starting point.

The user or agent can choose, modify, fork, or reject the pattern.

Example

A user says:

I want to recruit 5 early builders for my open-source protocol.

OM World may retrieve:

Pattern: Genesis Co-builder Recruitment

This pattern may include:

project positioning;
X article structure;
recruitment thread;
GitHub issue templates;
DM templates;
target contributor profiles;
follow-up schedule;
result tracking.

The user experiences:

I said the intention, and the world already knew a path.

This is the beginning of One Mind, One World as experience.

12. Pattern Economy

Pattern creators should be rewarded when their patterns make future realization easier.

If a pattern is reused, forked, or adapted, the creator may receive a share of settlement.

This creates a new kind of economic asset:

Reusable realization knowledge

The economic logic is simple:

The more a pattern reduces future realization friction, the more value it should attract.

This aligns incentives with OM World's core purpose.

Participants are rewarded not only for completing one task, but for making future tasks easier.

Pattern value may depend on:

reuse count;
success rate;
cost reduction;
time reduction;
adaptability;
user continuation;
fork count;
downstream derived patterns.

This is how OM World becomes self-growing.

13. Realization Friction

OM World should measure not only outputs, but friction.

Friction is the resistance between intention and realization.

Key friction types:

Expression Cost
Matching Cost
Execution Cost
Verification Cost
Settlement Cost
Reuse Cost
Trust Cost

A healthy OM World should reduce these over time.

13.1 Expression Cost

How hard is it for a user to express the intent?

Lower expression cost means the user can say less and still be understood.

13.2 Matching Cost

How hard is it to find the right path, tool, agent, or provider?

Lower matching cost means the world knows where to route the intent.

13.3 Execution Cost

How much time, compute, money, or human effort is required?

Lower execution cost means the world can act more efficiently.

13.4 Verification Cost

How hard is it to know whether the intent was realized?

Lower verification cost means settlement becomes easier.

13.5 Settlement Cost

How hard is it to reward contributors?

Lower settlement cost means more supply enters the network.

13.6 Reuse Cost

How hard is it to reuse what worked before?

Lower reuse cost means every realization compounds.

13.7 Trust Cost

How much uncertainty must the user or executor tolerate?

Lower trust cost means more complex intentions can be attempted.

14. Core Metrics

OM World should not measure itself like a normal Web3 project.

The primary metrics are not:

token price;
TVL;
holders;
speculation volume;
social hype.

The core metrics should measure whether intention realization is becoming easier.

14.1 Intent Realization Rate

IRR = fulfilled_intents / declared_intents

This measures how many expressed intentions become realized outcomes.

14.2 Median Time to Realization

TTR = median(time_from_intent_to_outcome)

This should decrease over time for mature intent categories.

14.3 Median Cost to Realization

CTR = median(cost_per_fulfilled_intent)

This should decrease as patterns, tools, and supply improve.

14.4 Pattern Reuse Rate

PRR = intents_using_existing_patterns / fulfilled_intents

This measures whether the world is accumulating reusable realization knowledge.

14.5 New Category Expansion

NCE = number_of_intent_categories_with_at_least_N_successful_realizations

This measures how many new kinds of intention the world can handle.

14.6 Supply Activation Rate

SAR = active_supply_nodes / registered_supply_nodes

This measures whether tools, agents, devices, and humans are actually contributing.

14.7 Capability Growth

CG = number_of_available_capabilities_by_intent_category

This measures whether realization supply is expanding.

A healthy OM World should show:

IRR ↑
TTR ↓
CTR ↓
PRR ↑
NCE ↑
SAR ↑
CG ↑

This is the measurable form of:

Intent realization becomes easier over time.

15. Core State Loop

The minimal state loop of OM World is:

IntentRegistered
→ PathProposed
→ MandateBound
→ ExecutionTraced
→ OutcomeSubmitted
→ SettlementResolved
→ PatternUpdated

15.1 IntentRegistered

An intention is recorded.

The system captures:

originator;
intent text;
context;
constraints;
desired outcome.

15.2 PathProposed

One or more realization paths are proposed.

A path may specify:

agents;
tools;
compute;
capital;
estimated cost;
estimated time;
proof condition;
settlement template.

15.3 MandateBound

The user or user policy selects a path and authorizes execution.

This may be explicit or automatic depending on user preferences and risk level.

15.4 ExecutionTraced

Execution occurs and leaves a trace.

The trace may include:

tool calls;
logs;
artifacts;
timestamps;
compute usage;
intermediate outputs;
errors;
retries.

15.5 OutcomeSubmitted

The executor submits the result.

15.6 SettlementResolved

If the agreed condition is met, settlement occurs according to the selected template.

15.7 PatternUpdated

The realization attempt updates the pattern library.

This happens whether the attempt succeeds or fails.

Failure is also world memory.

16. Core Rules

OM World Core should remain minimal.

The following rules are enough to define the self-growth engine.

Rule 1 — Intent Registration

Any intention can be registered as an intent object.

I = register(originator, intent, constraints, context)

The purpose is to make intention representable.

Rule 2 — Path Proposal

Any participant can propose a realization path for an intent.

P = propose_path(I, capabilities, cost, time, proof_condition, settlement_template)

The purpose is to expose possible routes from intention to realization.

Rule 3 — Mandate Binding

A path becomes executable only when bound by the originator or the originator's policy.

M = bind(I, P, permissions, budget, settlement)

The purpose is to connect intent with authorized execution.

Rule 4 — Execution Trace

Every execution attempt should generate a trace.

T = execute(M)

The purpose is to make realization attempts reusable as world memory.

Rule 5 — Proof-Gated Settlement

Settlement follows the preselected template and proof condition.

if proof(T, M) == true:
    settle(M)
else:
    no_settlement / retry / template-defined resolution

The purpose is to make supply-side participation economically meaningful.

Rule 6 — Pattern Accumulation

Every execution attempt updates the pattern library.

PatternLibrary.update(I, P, T, outcome)

The purpose is to make future realization easier.

This is the most important rule.

Without pattern accumulation, OM World does not self-grow.

17. Settlement Templates

OM World Core should not define one universal value formula.

Instead, it should support settlement templates.

A settlement template is a reusable rule for how value flows when an outcome condition is met.

17.1 Fixed Payment

Pay X if proof condition P is satisfied.

Useful for:

writing;
design;
research;
code generation;
simple automation.

17.2 Milestone Payment

Pay X1 if P1, X2 if P2, X3 if P3.

Useful for:

software development;
long-form research;
multi-step operations;
launch campaigns.

17.3 Bounty

First valid proof wins X.

Useful for:

bug discovery;
data search;
open research;
competitive tasks.

17.4 Success Fee

Executor earns α × measurable gain.

Useful for:

procurement savings;
optimization;
trading;
growth campaigns;
cost reduction.

17.5 Usage-Based Payment

Pay based on calls, compute, tokens, time, or volume.

Useful for:

tools;
APIs;
compute;
model inference;
automation services.

17.6 Staked Execution

Executor stakes B. If template-defined failure condition occurs, B may be reduced.

Useful for:

high-reliability tasks;
financial execution;
high-risk automation;
mission-critical operations.

Templates reduce complexity.

They allow the system to scale without requiring a universal value equation.

18. Why No Universal Value Formula

OM World does not need to decide the universal value of every realization.

The protocol should not ask:

What is this outcome truly worth in absolute terms?

It should ask:

What settlement rule did the originator and realization path accept before execution? Was the required condition met? What pattern should be updated?

This avoids the impossible task of defining one global value measure for all intentions.

Value is expressed through selected settlement templates.

The world grows not because it knows universal value.

It grows because it remembers which realization paths worked.

19. Self-Growth Flywheel

The OM World flywheel is:

More intents
→ More realization attempts
→ More execution traces
→ More patterns
→ Lower realization friction
→ Higher realization rate
→ More users
→ More supply
→ More intents

This loop is the engine.

19.1 Demand Growth

More users create more intent demand.

19.2 Supply Growth

More users, devices, tools, and agents create more supply.

19.3 Pattern Growth

More attempts create more reusable patterns.

19.4 Friction Reduction

More patterns reduce the cost of future realization.

19.5 Realization Expansion

Lower friction allows more complex intents to be attempted.

This is how OM World becomes a world.

20. Difference from an Agent Marketplace

An agent marketplace matches users with agents.

OM World accumulates realization patterns.

An agent marketplace rewards isolated task completion.

OM World rewards reusable capability.

An agent marketplace grows by adding more agents.

OM World grows when the world becomes better at realizing intention.

Agent Marketplace

User asks → Agent responds → Task ends

OM World

User intends
→ Path emerges
→ Execution happens
→ Outcome is recorded
→ Pattern is updated
→ Future realization becomes easier

The difference is memory.

The difference is compounding.

The difference is world formation.

21. Minimal MVP

The first OM World MVP should not attempt to realize all intentions.

It should test one thing:

Does pattern accumulation reduce future realization friction?

A suitable first intent category is:

Genesis Builder Recruitment

This is a real problem OM World itself faces.

21.1 Example Intent

I want to recruit 5 Genesis co-builders for my project.

21.2 First Realization Pattern

The system generates:

project positioning;
X Article;
X thread;
GitHub issue templates;
DM templates;
target builder profiles;
follow-up schedule;
result tracking plan.

21.3 Output

The user receives a complete campaign package.

21.4 Pattern Update

After execution, the system records:

which article worked;
which thread worked;
which target profiles responded;
which channels worked;
which messages failed;
how much time it took;
how many builders responded;
what should change next time.

21.5 The Test

The next project using the same pattern should need less time, less cost, and less manual thinking.

If that happens, OM World's self-growth thesis is validated.

22. Three-Phase Development Path

Phase 1 — Centralized Prototype

Goal:

Validate the self-growth loop.

Build:

intent input;
pattern recommendation;
output generation;
trace capture;
pattern update;
simple dashboard.

Do not begin with full decentralization.

First prove that pattern accumulation reduces friction.

Phase 2 — Open Tool and Pattern Registry

Goal:

Open the supply side.

Build:

tool declaration format;
pattern submission;
pattern reuse tracking;
creator attribution;
simple settlement;
developer onboarding.

This allows external builders to contribute capabilities.

Phase 3 — Distributed Execution Network

Goal:

Let users and devices become part of OM World.

Build:

contributor client;
local node execution;
compute contribution;
optional proof mechanisms;
settlement network;
reusable decentralized patterns.

Only after the self-growth loop is proven should execution become more decentralized.

If yes, it may belong in OM World.

If no, it should be removed, delayed, or kept outside the core.

This applies to:

protocol design;
economics;
user interface;
developer tools;
settlement;
proof;
pattern storage;
node design;
community building.

OM World should not become complex for the sake of completeness.

It should become capable for the sake of realization.

25. Final Statement

OM World is not built to govern intention.

It is built to make intention easier to realize.

Its core engine is not a single token, a single model, a single marketplace, or a single governance system.

Its core engine is the compounding memory of realized intentions.

Every intent creates a path.

Every path creates a trace.

Every trace can become a pattern.

Every pattern makes future realization easier.

This is the self-growth engine.

One Mind, One World.

The world grows when intention becomes easier to realize.