A decision-graph framework for reusable experience-based options
- Intent/How to read this
- Problem Statement
- Core Idea
- What PoX is NOT
- Conceptual Flow
- Conceptual Model
- Key Concepts(Notion)
- Open Questions & Future Exploration
- Status
This document is not a protocol proposal or a product specification.
It is an exploration of whether experience-based decision-making can be formalized as a reusable structure
without collapsing into “correct answers” or a single, authoritative solution.
Rather than treating experience as advice or conclusions, this document examines whether the act of deciding, grounded in lived experience, can be represented in a structured and shareable form while preserving contextual plurality.
In particular, this document explicitly seeks critique and feedback on the following points:
- Whether Decision Question can be considered a valid primitive (minimal unit) for representing decision-making
- Whether ASV (Attestation / Shared Validation) genuinely avoids ranking, scoring, or hierarchical dynamics
- At what points this model would break down or reach its limits in real-world operation
In today’s information environment,
while there is an abundance of “correct answers” and success stories,
there is a structural gap in how people determine which options fit their own situation and translate that judgement into action.
Most existing Q&A and knowledge-sharing systems primarily focus on:
- outcomes (answers / best practices)
- generalized knowledge
- ranking or prioritization through voting and evaluation
However, they rarely preserve the structure of decision-making itself, including:
- the context in which a judgement became valid
- the assumptions and constraints under which a choice was made
- why alternative options were not selected
- what new context emerged as a result of that judgement
As a result, even when information exists,
it often cannot be referenced in a way that makes
“what should I do next?” judgable within one’s own context.
While InfoFi primarily addresses:
the valuation, prediction, and marketization of information,
PoX focuses on an earlier and more fundamental stage:
the state in which judgement itself cannot yet be formed.
Accordingly, this document does not address InfoFi-style mechanisms such as correctness evaluation, pricing, or value computation.
Instead, it focuses on the structural question of:
how judgability is generated, and how it can be shared,
prior to evaluation, prediction, or market dynamics.
PoX treats experience-based decision-making
not as the presentation of a single “correct answer” or prescriptive advice,
but as a structured way to surface and share options.
Specifically, PoX is a framework designed to:
for a given Decision Question (a question oriented toward taking action),
construct and share a context-validated set of options,
thereby making the uncertainty inherent in that question explicit and visible.
The basic flow is as follows:
Decision Question → Option → Attestation → Fork
① Decision Question
A question that arises from a state in which action cannot be chosen
due to context-dependent indeterminacy.
② Option
An experience-based option, presented in relation to a specific Decision Question,
with its relevant context explicitly attached.
③ Attestation
A context-aware statement of validity regarding an Option,
expressing how and under what conditions it holds.
④ Fork (a new Will emerging from context)
A divergence or reinterpretation generated by differences in context,
resulting in a new direction or Decision Question.
- ❌ A system for determining “correct” answers
- ❌ A voting-, ranking-, or evaluation-based hierarchy
- ❌ A market for predicting or betting on the future
- ❌ A mechanism for overturning or invalidating past decisions
PoX does not aim to produce a single correct answer,
nor to evaluate or rank people or decisions based on outcomes.
PoX is a decision-making infrastructure that preserves
contextualized decision paths,
allowing others to compare them against their own situations,
reuse them where applicable,
or branch (fork) into new paths based on contextual differences.
— A Decision Graph Centered on Decision Questions —
In PoX, this section illustrates—in temporal order—
how experience-based decisions are generated, validated, fixed, reused, and branched,
making explicit both user actions and state transitions within the system.
-
Initiator
The person who raises a Decision Question (DQ)
-
Proposer
The person who presents an Option in response to a DQ
-
Attestor
The person who observes an Option and its Context and issues an attestation (a contextual stance)
-
Forker
The person who creates a Fork by branching from an existing Option under a new context
-
Observer
The person who only views, compares, or references Options
(does not participate in ASV)
Action
- The Initiator explicitly states a question oriented toward taking action
Input
- Personal uncertainty / intent / situation
Output
- Decision Question (DQ)
- DQ hash / metadata
State
- DQ:
Open
Action
- A Proposer submits an Option in response to a DQ
- Each Option is accompanied by a minimal Context (assumptions / constraints)
Input
- DQ
- Experience-based option proposal
Output
- Option v0
- Context v0
- Content-addressed hash
State
- Option:
Draft → Proposed
ASV is NOT:
- a vote to determine correctness
- a ranking weighted by reputation or influence
- a mechanism to converge opinions into one conclusion
The sole role of ASV is to make an Optionjudgable under the stated context.
Action
-
Attestors submit signed attestations
(not approval/disapproval, but validity under this context)
Attestation Criteria
- Consistency with the stated context
- Reusability (whether comparative judgement is possible)
- Sufficiency of information / absence of malicious intent
Output
-
Attestation records
(
endorse/needs-clarification/challenge)
Action
- If information is insufficient or ambiguous, clarification is requested
- The Proposer revises or supplements and submits a new version
Output
- Option v1, v2, …
- Context v1, v2, …
- ASV history (append-only / irreversible)
State Transition
- Option:
Proposed → Refined
Conditions
-
A defined proportion of ASV participants (e.g., 70%)
agree that the Option is “best for now”
-
Outstanding challenges have been resolved
Action
- The Option is fixed as a working premise
Output
- Locked Option (Best-for-now)
- Fixed hash / version
State
- Option:
Attested (Judgable)
This is not a “correct answer,”
but the most thoroughly observed premise at the current point in time.
Action
- Observers, Initiators, or Forkers may compare and select Options
- Selection or reference may also trigger a new DQ or Fork
Input
- Locked Option
- One’s own Context
Output
- Selection event
- Reference log
State
- Option:
Reused
Action
- If the Option does not fit, a new DQ or Fork is created
Input
- Locked Option
- New context / assumptions
Output
- Forked Decision Question
- New Option graph
State
- Option:
Forked
Measurement Points (Downstream Impact)
- Whether an Option was:
- referenced
- selected
- used as a fork origin
- influential on statements or actions
Output
- Impact records
- Base data for reward distribution
Draft
→ Proposed
→ Refined
→ Attested (Judgable / Best-for-now)
→ Reused
→ Forked
-
Insufficient information
→ ASV request → revision loop
-
Context mismatch
→ Fork
-
Contradictions / unexplored areas
→ handled in a new DQ or Fork
(past decisions are not overturned)
Triggers
- Low-substance Options
- Unnatural ASV chains
- Reward-driven malicious behavior
Flow
Flag
→ Case creation
→ Review (ASV-based examination)
→ Enforce (penalty / invalidation / reward revocation)
- Decision Questions are the sole starting point
- ASV is a process for generating judgability
- Fixation confirms premises, not correctness
- Refutation moves forward via Fork, not reversal
- PoX is a structure in which meaning continuously updates while the past remains intact
Decision-Graph–Based Experience Infrastructure
PoX:
- does not determine correct answers
- does not create hierarchies through voting or evaluation
- preserves experience not as conclusions, but as premise structures that generate judgability
Accordingly, PoX is:
- neither a timeline (chronological log), nor
- a tree (correct-branch structure),
but is designed as a Decision Graph.
This graph contains both:
- Flow (events over time), and
- State (structural conditions).
[ Decision Question ]
|
v
(Options)
/ |
v v v
[Option][Option][Option]
| |
v v
[ASV] [ASV]
| |
+---+---+
|
(Judgable)
|
Reuse / Select
|
Context gap
|
Fork
|
[New Decision Question]
- Vertical axis: temporal Flow
- Horizontal axis: parallel Options
- Recursion: subsequent Decision Questions generated via Fork
Position in the Flow
→ Origin point of Phase 0 / Phase 8
Role
- A question that articulates the uncertainty preventing action
- The starting point for generating and validating Options
Properties
- context-dependent
- unresolved
- does not demand a correct answer
A Decision Question is:
not a question to obtain an answer, but
a question to generate judgable options.
Position in the Flow
→ Phase 0 → Phase 6
Definition
-
A context-attached, experience-based option
proposed in response to a Decision Question
Key Point
- An Option does not stand alone
- It must always be paired with Context
Option =
“Under this Context, this choice was viable.”
Position in the Flow
→ Attached at Option submission and refined through ASV
Role
- The set of premises under which judgement became possible
- The boundary of an Option’s validity
Includes
- constraints (time, capital, position)
- situational conditions (phase, environment)
- the decision-maker’s assumptions and intent
Context =
the mechanism that prevents an Option from becoming a general claim.
Position in the Flow
→ Phase 2 to Phase 6
Definition
- A signed, context-aware stance regarding an Option and its Context
What ASV does:
- does not determine correctness
- does not vote
- only expresses conditional validity
ASV =
“Under this Context, I judge this Option to be valid.”
Position in the Flow
→ Phase 6
Meaning
- The premises have been sufficiently observed via ASV
- The best-considered reference point at the current time
Important
- not an eternal truth
- not overturned
- counterarguments move forward via Fork
→ an act of fixing premises, not answers
Position in the Flow
→ Phase 7
What Happens
- Third parties reference and compare Options
- Options may be adopted relative to one’s own context
※ Selection is not evaluation
※ This is the starting point of action
Position in the Flow
→ Phase 8
Definition
- A new Decision Question generated by contextual mismatch or divergence
A Fork:
- does not negate the past
- carries “this didn’t fit” forward into the future
→ not refutation, but branching
| State | Meaning in the Flow |
|---|---|
| Draft | Before proposal |
| Proposed | Option + Context submitted |
| Refined | Revised via ASV requests |
| Attested | Judgable / Best-for-now |
| Reused | Applied to action |
| Forked | Generates a new DQ |
Important
- Attested ≠ correct answer ❌
- Attested = judgable premise ⭕️
What is fixed
- the premises under which judgement held
- the history of attestations regarding them
What is not fixed
- universal truths
- forced conclusions for others
→
The past is preserved; the future can branch.
| Flow | Model |
|---|---|
| DQ creation | Decision Question |
| Option submission | Option + Context |
| ASV | Attestation |
| Fixation | Judgable / Best-for-now |
| Selection | Reuse |
| Mismatch | Fork |
| Continuation | Decision Graph |
PoX is a Decision Graph infrastructure in which,
starting from a Decision Question,
contextualized Options are fixed as judgable premises through Attestation,
and continuously updated through reuse and forking.
We explicitly welcome criticism, alternative framings, and observations from real-world operational perspectives on the following points.
-
Can a Decision Question reasonably be considered a valid primitive (minimal unit) for experience-based decision-making?
-
Although a Decision Question is context-dependent and unresolved,
can it still form a structure that withstands reuse and comparison?
-
What level of abstraction or concreteness is appropriate for a Decision Question?
-
Does ASV, as designed,
truly avoid the dynamics of evaluation, ranking, and hierarchy?
-
Does the use of signed attestations risk introducing implicit authority or concentration of influence?
-
How minimal can the ASV schema (required fields) realistically be reduced?
-
Does the cost of describing and updating Context
become excessive in real-world operation?
-
To what extent should Context be structured,
and where should it be left to free-form human description?
-
Can insufficient Context truly be compensated for through ASV?
-
Does Fork function as a healthy form of branching,
or can it devolve into avoidance or fragmentation?
-
If Forks continue to accumulate,
can the Decision Graph maintain readability and navigability?
-
Under what conditions does the assumption
that “meaning is not destroyed by Forks” break down?
-
Do Reuse, Fork, and impact records
accurately reflect the consequences of actions?
-
Can impact metrics coexist with PoX’s non-ranking philosophy?
-
Could incentive design distort ASV behavior or Fork dynamics?
-
Under what use cases, scales, or participant compositions does this model fail?
-
Which domains of decision-making is PoX fundamentally unsuited for?
-
In what cases should PoX explicitly not be used?
-
While PoX is currently conceived as an all-in platform,
would coexistence with other sharing layers be preferable?
- Minimal viable schema for ASV
- Quantification methods for downstream impact
- Incentive design (reward sources and distribution)
- Anti-gaming mechanisms and enforcement depth
- On-chain / off-chain boundaries
PoX is currently in a conceptual exploration phase.
This document presents a working hypothesis on how
experience-based decision-making might be structured and shared
without collapsing into “correct answers” or a single authoritative solution.
While the conceptual flow, core entities, and non-goals are intentionally specified,
details regarding protocol design, implementation strategies,
and incentive mechanisms are deliberately left undecided.
At this stage, the primary objective is not implementation, but to:
- examine the assumptions underlying this model,
- identify where it may break down, and
- clarify the boundary between where it is applicable and where it is not.
Accordingly, critical feedback, alternative interpretations, and practical counterexamples
are strongly encouraged.