coulomb/decision-canon
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Seeded initial content

Browse source
This commit is contained in:
tegwick 2026-10-04 20:25:57 +02:00
parent 7228b7ec5b
commit 4c8890faf4
8 changed files with 2571 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

433
DecisionCanon.md Normal file
View file

@ -0,0 +1,433 @@
# Decision Canon v0.1
## 1. Purpose
The Decision Canon provides a coherent conceptual system for describing decisions, decision processes, and decision-governed ecosystems.
It intentionally separates:
1. **Decision situation** — why a decision exists.
2. **Decision modelling** — how the relevant world is represented.
3. **Decision analysis** — how alternatives are evaluated.
4. **Decision taking** — how an authorized commitment occurs.
5. **Decision execution** — what is done because of the commitment.
6. **Decision observation** — what happens afterwards.
7. **Decision learning** — what should change in beliefs, models, or rules.
8. **Decision governance** — who may decide and under which constraints.
9. **Decision evolution** — how policies and constitutional rules reshape future decisions.
## 2. Unified lifecycle
```text
Situation
↓
Decision need
↓
Frame
↓
Alternatives / interventions
↓
Evaluation
↓
Commitment
↓
Effect / execution
↓
Observation
↓
Learning
```
For policy-bearing decisions:
```text
Decision
↓
Policy / Rule / Constraint / Delegation
↓
Changes future decision spaces
↓
Future decisions
↓
Observed ecosystem evolution
↓
Policy review
↓
Revised decision
```
## 3. Decision kinds
Initial decision kinds:
- `choice`
- `bet`
- `experiment`
- `commitment`
- `delegation`
- `allocation`
- `authorization`
- `exception`
- `policy`
- `constitutional`
These may overlap.
### Choice
Select among alternatives.
### Bet
Accept unresolved uncertainty for expected benefit.
### Experiment
Act primarily to acquire information.
### Commitment
Reduce future optionality.
### Delegation
Transfer or constrain decision authority.
### Allocation
Assign scarce resources.
### Authorization
Permit or prohibit an action.
### Exception
Override an existing rule within bounded scope.
### Policy
Create reusable rules that govern classes of future decisions.
### Constitutional
Change the rules by which authority, policy, or governance may themselves change.
## 4. Decision state
Suggested lifecycle:
```text
noticed
→ framed
→ open
→ recommended
→ committed
→ effective
→ observed
→ reviewed
→ closed
```
Side states:
- `deferred`
- `delegated`
- `cancelled`
- `expired`
- `superseded`
- `revoked`
The key boundary is `committed`.
Before commitment, the system is considering possibilities.
After commitment, the system has adopted an intention.
## 5. Decision formality levels
### D0 — Ephemeral
Unrecorded or transient choice.
### D1 — Recorded
Captures question, choice, and reason.
### D2 — Structured
Adds alternatives, owner, context, and constraints.
### D3 — Analyzed
Adds evidence, values, uncertainty, and explicit analysis.
### D4 — Governed
Adds authority, approvals, delegation, escalation, and auditability.
### D5 — Executable
Adds machine-readable rules, conditions, triggers, and actions.
### D6 — Policy
Creates reusable rules that constrain future decisions.
### D7 — Constitutional
Changes authority structures, policy-creation rules, or foundational ecosystem constraints.
These are not maturity rankings in the sense that D7 is always better than D1.
They indicate the degree and kind of formalization appropriate to the decision.
## 6. Decision method families
The canon should allow multiple methods rather than prescribe one.
### Informal / human
- intuition
- expert judgment
- heuristic
- checklist
- recognition-primed decision
### Comparative
- pairwise comparison
- weighted scoring
- MCDA / MAUT
- AHP
- outranking
### Probabilistic
- expected utility
- Bayesian decision analysis
- value of information
- decision trees
- influence diagrams
### Optimization
- linear programming
- mixed-integer programming
- constraint programming
- stochastic optimization
- robust optimization
### Sequential / adaptive
- dynamic programming
- MDP
- POMDP
- optimal control
- reinforcement learning
### Causal
- structural causal models
- intervention analysis
- counterfactual analysis
### Strategic
- game theory
- bargaining
- mechanism design
- scenario analysis
### Complexity-oriented
- probing
- real options
- safe-to-fail experiments
- robust decision making
### Collective
- vote
- consent
- consensus
- deliberation
- committee decision
### Machine-assisted
- rule engine
- DMN
- optimization service
- recommendation model
- AI-assisted synthesis
- autonomous policy selection
## 7. Decision authority
Authority should be represented independently from capability.
Canonical modalities:
```text
can technically capable
may authorized
should normatively preferred
will committed
did observed
must mandatory
```
This permits distinctions such as:
```yaml
actor: autonomous-deployment-agent
can: true
may: false
```
or:
```yaml
actor: tenant-operator
may: true
scope: tenant
```
## 8. Decision criticality
The canon should support a measure of required rigor.
A conceptual function:
```text
RequiredRigor =
Stakes
× Irreversibility
× Uncertainty
× DurationOfEffect
× ScopeOfImpact
× AuthorityDepth
```
This is not yet intended as a literal equation.
Its purpose is to formalize the principle that more consequential decisions deserve more explicit modelling.
## 9. Policy effect primitives
Initial policy primitives:
- `permit`
- `prohibit`
- `require`
- `constrain`
- `default`
- `prefer`
- `incentivize`
- `delegate`
- `escalate`
- `observe`
- `review`
- `expire`
These primitives should be sufficient to express a large portion of operational governance.
## 10. Decision relationships
Canonical graph relationships:
- `derived-from`
- `implements`
- `governed-by`
- `delegated-by`
- `authorized-by`
- `triggered-by`
- `depends-on`
- `challenges`
- `reviews`
- `supersedes`
- `revokes`
- `exception-to`
- `resulted-in`
- `learned-from`
## 11. Decision lineage
Decision lineage is the ability to explain an observed action by traversing its decision and authority history:
```text
Observed action
↑
Execution
↑
Decision
↑
Delegated authority
↑
Policy
↑
Policy decision
↑
Constitutional decision
```
The inverse traversal should answer:
> What downstream decisions and actions did this policy enable, prohibit, or shape?
## 12. Decision quality
Decision quality and outcome quality must remain distinct.
### Ex ante
Was the decision reasonable given:
- frame,
- evidence,
- beliefs,
- alternatives,
- values,
- uncertainty,
- available analysis,
- and authority?
### Ex post
What actually happened?
The difference between expectation and outcome produces learning.
## 13. Canonical deep structure
A useful abstract representation is:
```text
D = (F, K, A, V, M, G, C, E, O, L)
```
where:
- `F` — Frame
- `K` — Knowledge
- `A` — Alternatives
- `V` — Values
- `M` — Method
- `G` — Governance
- `C` — Commitment
- `E` — Effect / Execution
- `O` — Observation
- `L` — Learning
A lightweight decision may instantiate only:
```text
(F, A, C)
```
while a constitutional decision may instantiate the entire structure.
## 14. Central invariant
> A Decision Object records an authorized commitment made from a particular frame, knowledge state, and value system, together with its intended effects and sufficient lineage to observe and learn from what follows.

401
DecisionObjectSchemaDraft.md Normal file
View file

@ -0,0 +1,401 @@
# Decision Object Schema Draft v0.1
This is an intentionally loose structural draft.
It is not yet a normative JSON Schema.
The purpose is to identify modules and boundaries before freezing field names or validation rules.
## 1. Top-level shape
```yaml
decision:
identity:
question:
kind:
state:
frame:
alternatives:
evidence:
world_model:
values:
analysis:
uncertainty:
information_options:
governance:
commitment:
effects:
execution:
outcome:
learning:
optionality:
relationships:
temporal:
metadata:
```
## 2. Identity
```yaml
identity:
id: DEC-...
title:
namespace:
version:
```
## 3. Question
```yaml
question:
text:
decision_class:
trigger:
```
## 4. Kind
```yaml
kind:
primary: choice
secondary:
- experiment
```
Candidate values:
```text
choice
bet
experiment
commitment
delegation
allocation
authorization
exception
policy
constitutional
```
## 5. State
```yaml
state:
lifecycle: committed
since:
```
Candidate lifecycle values:
```text
noticed
framed
open
recommended
committed
effective
observed
reviewed
closed
deferred
delegated
cancelled
expired
superseded
revoked
```
## 6. Frame
```yaml
frame:
situation:
scope:
horizon:
boundaries:
assumptions: []
exclusions: []
stakeholders: []
dependencies: []
```
## 7. Alternatives
```yaml
alternatives:
- id: A
label:
action:
description:
prerequisites: []
reversibility:
level:
cost:
delay:
```
## 8. Evidence
```yaml
evidence:
claims:
- id:
statement:
status:
confidence:
source:
valid_at:
observations: []
assumptions: []
sources: []
```
Candidate epistemic statuses:
```text
unknown
not-applicable
not-investigated
estimated
assumed
observed
derived
inferred
decided
```
## 9. World model
```yaml
world_model:
states: []
variables: []
relationships: []
causal_model:
scenarios: []
```
## 10. Values
```yaml
values:
objectives: []
constraints: []
preferences: []
thresholds: []
vetoes: []
tradeoffs: []
```
## 11. Analysis
```yaml
analysis:
analyses:
- id:
method:
model:
inputs:
result:
confidence:
sensitivity:
robustness:
recommendation:
```
## 12. Uncertainty
```yaml
uncertainty:
known_unknowns: []
model_uncertainty: []
outcome_uncertainty: []
ambiguity: []
reducible: []
irreducible: []
```
## 13. Information options
```yaml
information_options:
- question:
method:
cost:
delay:
expected_information_value:
```
## 14. Governance
```yaml
governance:
owner:
authority:
source:
scope:
can:
may:
must:
advisors: []
approvers: []
challengers: []
affected_parties: []
delegation:
escalation:
oversight:
```
## 15. Commitment
```yaml
commitment:
selected:
by:
at:
mode:
confidence:
conditions: []
reservations: []
```
## 16. Effects
```yaml
effects:
- id:
type:
target:
value:
effective_when:
expires_when:
```
Candidate effect types:
```text
action
allocation
authorization
constraint
delegation
policy
incentive
default
prohibition
requirement
```
## 17. Execution
```yaml
execution:
intended_actions: []
responsible: []
status:
started_at:
completed_at:
evidence: []
```
## 18. Outcome
```yaml
outcome:
observations: []
metrics: []
unintended_effects: []
stakeholder_effects: []
occurred_at:
```
## 19. Learning
```yaml
learning:
expected:
observed:
deviations: []
hypothesis_updates: []
calibration:
lessons: []
followup_decisions: []
```
## 20. Optionality
```yaml
optionality:
reversible:
reversal_cost:
reversal_delay:
locks_in: []
options_created: []
options_destroyed: []
```
## 21. Relationships
```yaml
relationships:
- type: governed-by
target: POLICY-SEC-001
```
Candidate relationship types:
```text
derived-from
implements
governed-by
delegated-by
authorized-by
triggered-by
depends-on
challenges
reviews
supersedes
revokes
exception-to
resulted-in
learned-from
```
## 22. Temporal
```yaml
temporal:
created_at:
decision_time:
effective_from:
effective_until:
observed_at:
reviewed_at:
```
## 23. Metadata
```yaml
metadata:
formality_level: D3
tags: []
schema_version:
```
## 24. Open design questions
- Which fields belong in the immutable kernel?
- Which fields should be versioned instead of overwritten?
- How should competing analyses be represented?
- How should probabilities and utility models be encoded?
- Should authority assertions use a separate canonical model?
- How should policy primitives map to executable rule systems such as DMN or OPA-style policy engines?
- How should nested or dependent decisions be modelled?
- Which relationship semantics should be normative?
- How should decision-time snapshots be preserved?
- What minimum structure is necessary for reliable decision lineage?

121
Glossary.md Normal file
View file

@ -0,0 +1,121 @@
# Glossary — decision-canon v0.1
## Alternative
A candidate action, intervention, non-action, delegation, investigation, or combination available within a decision frame.
## Authority
The legitimate permission to make, approve, constrain, delegate, or execute a decision within a defined scope.
## Bet
A decision that knowingly accepts unresolved uncertainty in pursuit of expected benefit.
## Capability
What an actor or system is technically able to do.
Capability does not imply authority.
## Commitment
The point at which an authorized actor or mechanism adopts an intention or selects a course of action.
## Constitutional decision
A decision that changes the rules governing authority, policy creation, governance, or the modification of foundational constraints.
## Decision
An authorized commitment made in response to a framed situation.
## Decision analysis
The structured evaluation of alternatives using evidence, models, values, uncertainty, and one or more analytical methods.
## Decision graph
A network of Decision Objects linked by typed relationships such as `governed-by`, `authorized-by`, `supersedes`, or `learned-from`.
## Decision lineage
The trace from an observed action or outcome back through the decision, authority, delegation, policy, and constitutional structures that enabled or constrained it.
## Decision modelling
Representation of the decision situation, world, uncertainty, causal relationships, alternatives, values, and constraints.
## Decision Object
A persistent semantic representation of a decision and its relevant context, reasoning, authority, commitment, effects, and learning.
## Decision quality
The quality of a decision given the frame, information, values, uncertainty, reasoning, and authority available at decision time.
It is distinct from outcome quality.
## Decision taking
The act or mechanism by which a recommendation or open choice becomes an authorized commitment.
## Delegation
The transfer or bounded assignment of decision authority from one actor or authority source to another.
## Effect
A change intended to occur because of a decision.
Effects may include actions, allocations, permissions, constraints, delegations, or policy changes.
## Epistemic state
The collection of observations, assumptions, estimates, beliefs, uncertainties, and models available at a particular time.
## Experiment
A decision or action taken primarily to acquire information or reduce uncertainty.
## Formality level
A description of how deeply a decision is structured, analyzed, governed, or made executable.
Initial levels range from D0 to D7.
## Frame
The representation of what situation is being decided, including scope, boundaries, horizon, assumptions, exclusions, and stakeholders.
## Governance
The authority, approval, delegation, escalation, oversight, and accountability structure surrounding a decision.
## Outcome
What actually happened after a decision and its execution.
## Policy
A reusable rule or rule system that constrains, permits, requires, defaults, incentivizes, delegates, or escalates classes of future actions or decisions.
## Policy decision
A decision whose important effect is the creation, modification, or removal of policy.
## Progressive formalization
The principle that a common semantic model should allow a decision to acquire additional structure only when warranted.
## Reversibility
The degree to which the effects of a decision can be undone, including reversal cost and delay.
## Uncertainty
Lack of certainty regarding states, outcomes, models, causal relationships, preferences, or future events.
## Value model
The objectives, preferences, constraints, thresholds, vetoes, and tradeoffs against which alternatives are assessed.

163
INTENT.md Normal file
View file

@ -0,0 +1,163 @@
# INTENT — decision-canon
## Mission
Establish a coherent, extensible **Decision Canon** that provides:
1. a shared language for thinking and talking about decisions,
2. a unified Decision Object capable of representing decisions across radically different levels of rigor and consequence,
3. a taxonomy of decision kinds, methods, authority modes, and effects,
4. a progressive formalization model that keeps simple decisions simple,
5. a machine-processable foundation for governed human, agentic, and hybrid decision systems,
6. a way to model policies and constitutional decisions as decisions whose effects shape future decision spaces,
7. and a closed-loop learning model connecting decisions to execution, outcomes, retrospectives, and policy evolution.
## Problem
Decision-related disciplines are fragmented.
Relevant bodies of work include:
- normative decision theory,
- Bayesian decision analysis,
- causal inference,
- multi-criteria decision analysis,
- operations research,
- robust optimization,
- game theory,
- behavioral decision theory,
- naturalistic decision making,
- complexity-oriented decision making,
- organizational decision rights,
- business rules and DMN,
- workflow systems,
- control theory,
- reinforcement learning,
- policy design,
- and governance.
Each contributes useful abstractions, but no single practical object model spans the whole lifecycle:
```text
situation
→ framing
→ evidence
→ alternatives
→ values
→ analysis
→ authority
→ commitment
→ execution
→ observation
→ learning
→ policy evolution
```
The canon shall explore that missing connective layer.
## Core hypothesis
A **Decision Object** can serve as a first-class unit of agency.
It should record an authorized commitment made from a particular frame, knowledge state, and value system, together with intended effects and sufficient lineage to observe and learn from what follows.
The object must support progressive formalization:
```text
informal choice
→ recorded decision
→ structured decision
→ analyzed decision
→ governed decision
→ executable decision
→ policy decision
→ constitutional decision
```
## Key design principles
### One semantic object, progressive formality
A trivial choice must not require heavyweight structure.
A consequential policy decision must support deep analysis, explicit authority, evidence, machine-readable effects, and retrospective learning.
### Explicit incompleteness
Unknown, estimated, assumed, inferred, observed, and decided must remain distinguishable.
### Decision quality is not outcome quality
The decision record must preserve what was knowable at decision time so that outcomes do not rewrite history.
### Capability and authority are independent
The canon must distinguish:
```text
can
may
should
will
did
```
### Policies are decision effects
A policy decision changes the rules under which future decisions are made.
### Constitutional decisions alter decision-making itself
Constitutional decisions may change authority structures, policy creation rules, fundamental constraints, or mechanisms for delegation and escalation.
### Decisions form a graph
The canon should support explicit decision lineage such as:
```text
derived-from
implements
governed-by
delegated-by
authorized-by
triggered-by
depends-on
challenges
reviews
supersedes
revokes
exception-to
resulted-in
learned-from
```
## Intended uses
The canon should eventually support:
- architecture decision records,
- product and investment decisions,
- security decisions,
- autonomous-agent delegation,
- policy modelling,
- governance systems,
- approval and escalation systems,
- incident decision reconstruction,
- decision retrospectives,
- machine-executable decision services,
- organizational decision intelligence,
- and simulation of ecosystem evolution under different policies.
## Non-goals
The canon is not intended to:
- replace every existing decision-analysis method,
- impose quantitative analysis on all decisions,
- force all decisions into one universal workflow,
- collapse values, evidence, uncertainty, and authority into one scalar score,
- or treat policy as merely another business rule.
## Long-term ambition
Create a practical and formal foundation for **adaptive socio-technical decision systems** in which humans, agents, services, and institutions can make, delegate, execute, review, and evolve decisions while preserving authority lineage and epistemic context.

59
README.md
View file

@ -1,3 +1,60 @@
# decision-canon
Othogonal vocabulary and canonical model for decision related concepts.
Othogonal vocabulary and canonical model for decision related concepts.# decision-canon
`decision-canon` is a research and design repository for a unified language, object model, and practical system architecture for representing decisions from lightweight informal choices through governed, executable, policy-shaping, and constitutional decisions.
The central idea is a **Unified Decision Object** that can be progressively formalized without forcing heavyweight structure onto simple decisions.
## Core thesis
A decision is more than a selected option.
A durable decision representation should be able to capture:
- the situation and framing,
- what was known or believed,
- available alternatives or interventions,
- objectives, values, and constraints,
- the decision method used,
- authority and governance,
- the actual commitment,
- intended and observed effects,
- and what was learned afterwards.
At higher levels, decisions may create policies that constrain later decisions, or even constitutional rules that determine how policy and authority themselves may change.
## Initial repository structure
```text
decision-canon/
├── README.md
├── INTENT.md
├── DecisionCanon.md
├── UnifiedDecisionObject.md
├── DecisionObjectSchemaDraft.md
├── ResearchProgram.md
├── Glossary.md
└── history/
└── 2026-10-04-initial-exploration.md
```
## Working principle
> One semantic object, progressive formality.
The same decision model should support both:
```yaml
question: Which database should we use?
choice: PostgreSQL
reason: It is sufficient and already operationally familiar.
```
and a platform-level constitutional decision establishing future decision rights, escalation rules, autonomous authority, and review mechanisms.
## Status
Seed / v0.1 research basis.
The concepts in this repository are provisional and intended to be challenged, formalized, implemented, and tested.

335
ResearchProgram.md Normal file
View file

@ -0,0 +1,335 @@
# Research Program — decision-canon
## 1. Research objective
Develop and validate a unified Decision Canon that connects decision theory, practical decision-making methods, governance, executable decision systems, and adaptive policy evolution.
The research should answer:
> Can a single progressively formalizable Decision Object represent the important semantics of decisions from simple human choices to constitutional rules governing autonomous ecosystems?
## 2. Research streams
### A. Decision theory foundations
Study and synthesize:
- expected utility theory,
- Bayesian decision theory,
- value of information,
- causal decision theory,
- bounded rationality,
- prospect theory,
- ecological rationality.
Goal:
Identify the smallest set of primitives needed to represent rational, bounded, uncertain, and causally informed decisions.
### B. Decision analysis and modelling
Study:
- decision trees,
- influence diagrams,
- MAUT / MCDA,
- AHP,
- ELECTRE / PROMETHEE,
- scenario analysis,
- robust decision making,
- real options.
Goal:
Map analytical methods onto modular Decision Object extensions.
### C. Optimization and sequential decisions
Study:
- linear and integer optimization,
- constraint programming,
- stochastic optimization,
- robust optimization,
- MDPs,
- POMDPs,
- control theory,
- reinforcement learning.
Goal:
Determine how generated actions and learned policies fit the same object model as discrete human choices.
### D. Strategic and multi-actor decisions
Study:
- game theory,
- bargaining,
- mechanism design,
- social choice,
- multi-agent systems.
Goal:
Represent decisions made in environments containing other adaptive decision makers.
### E. Human and naturalistic decision making
Study:
- heuristics,
- expert judgment,
- recognition-primed decisions,
- cognitive biases,
- time-pressured decisions,
- group decision making.
Goal:
Avoid over-formalizing real-world human decisions while preserving enough structure for learning.
### F. Organizational governance
Study:
- decision rights,
- delegation,
- RACI / RAPID / DACI,
- four-eyes principles,
- escalation models,
- board and committee governance,
- regulatory accountability.
Goal:
Formalize authority separately from capability and preference.
### G. Executable decision systems
Study:
- DMN,
- BPMN integration,
- rule engines,
- policy engines,
- workflow systems,
- access-control policy languages.
Goal:
Create mappings between Decision Objects and executable operational systems.
### H. Policy and constitutional modelling
Study:
- public policy design,
- legal rules,
- constitutions,
- institutional economics,
- governance theory,
- Ostrom-style rule systems,
- adaptive policy making.
Goal:
Define policy decisions as decisions that alter future decision spaces, and constitutional decisions as decisions that alter how such rules may change.
### I. Decision lineage and observability
Study analogies to:
- data lineage,
- provenance,
- event sourcing,
- audit logs,
- distributed tracing,
- causal graphs.
Goal:
Enable traversal from observed action back to the policy and authority chain that enabled it.
### J. AI and autonomous decision systems
Study:
- AI-assisted decision making,
- human-in-the-loop systems,
- decision-focused learning,
- causal reinforcement learning,
- autonomous agents,
- machine delegation,
- AI governance.
Goal:
Define safe and efficient mechanisms for dynamically allocating decision authority between humans and machines.
## 3. Initial hypotheses
### H1 — Progressive formalization works
A shared semantic object can span informal and formal decisions if optional analytical and governance envelopes are used.
### H2 — Commitment is the central boundary
The most important semantic transition is not analysis completion but authorized commitment.
### H3 — Policy is a decision effect
Policies can be modelled naturally as effects that constrain or enable future decisions.
### H4 — Constitutional recursion is representable
Decisions can modify the rules that govern creation and modification of future policies and decision rights.
### H5 — Decision lineage is operationally useful
Organizations and agentic ecosystems benefit from being able to trace actions to decisions, delegations, and governing policies.
### H6 — Decision quality must remain separate from outcome quality
Preserving decision-time epistemic state improves learning and accountability.
## 4. Prototype milestones
### M0 — Concept seed
Deliver:
- intent,
- initial canon,
- Decision Object,
- schema draft,
- glossary,
- research history.
### M1 — Comparative corpus
Represent at least 25 decisions from different domains:
- trivial engineering choice,
- architecture decision,
- hiring decision,
- procurement decision,
- incident-response decision,
- investment decision,
- security exception,
- deployment policy,
- budget allocation,
- public-style policy,
- constitutional governance rule.
Evaluate where the schema becomes awkward.
### M2 — Kernel freeze candidate
Identify the minimal mandatory kernel and normative lifecycle.
### M3 — Extension model
Separate optional modules for:
- probabilistic analysis,
- causal analysis,
- MCDA,
- optimization,
- governance,
- policy,
- execution,
- learning.
### M4 — Decision graph
Implement explicit typed relationships and decision lineage.
### M5 — Executable mapping
Prototype conversion or linkage to:
- DMN,
- workflow systems,
- policy engines,
- approval systems.
### M6 — Autonomous delegation
Model decision authority for human/agent hybrids, including escalation and bounded autonomy.
### M7 — Policy evolution simulation
Use Decision Objects to model an ecosystem where policies influence later decisions and are themselves revised based on observed outcomes.
## 5. Evaluation criteria
The canon should be judged against:
### Expressiveness
Can it model radically different decisions without distortion?
### Simplicity
Can simple decisions remain simple?
### Composability
Can decisions depend on, authorize, or revise other decisions?
### Temporal integrity
Can the system preserve what was known at decision time?
### Governance fidelity
Can authority, delegation, approval, and escalation be represented explicitly?
### Executability
Can sufficiently formal decisions drive software systems?
### Learnability
Can outcomes and retrospectives update later models without corrupting the original record?
### Explainability
Can an observed action be traced back through its decision and authority lineage?
## 6. Research artifacts
Suggested repository evolution:
```text
decision-canon/
├── INTENT.md
├── DecisionCanon.md
├── UnifiedDecisionObject.md
├── DecisionObjectSchemaDraft.md
├── Glossary.md
├── ResearchProgram.md
├── concepts/
├── catalog/
├── compendium/
├── schemas/
├── examples/
├── experiments/
├── fixtures/
├── reviews/
└── history/
```
## 7. Immediate next questions
1. What is the irreducible Decision Object kernel?
2. Is `commitment` always necessary for something to count as a decision?
3. Should policies themselves be Decision Objects, effects, or both?
4. How should competing world models be represented?
5. How should authority provenance be modelled?
6. How should recursive policy changes avoid infinite conceptual nesting?
7. Which existing standards should be reused rather than reinvented?
8. How should uncertainty and confidence be represented without fake precision?
9. How should decisions be versioned and superseded?
10. What should a minimal executable decision format look like?

430
UnifiedDecisionObject.md Normal file
View file

@ -0,0 +1,430 @@
# Unified Decision Object v0.1
## 1. Intent
A Decision Object is a persistent representation of an intentional commitment made by an actor or decision system in response to a decision situation.
It must scale from lightweight informal decisions to deeply governed policy and constitutional decisions.
## 2. Progressive formalization
The same semantic object should support:
```yaml
question: Which database should we use?
choice: PostgreSQL
reason: It is sufficient and already operationally familiar.
```
and:
```yaml
id: DEC-ROOT-SEC-001
kind: constitutional
state: effective
question: >
How shall security authority be delegated across the platform?
commitment:
selected: progressive-risk-based-delegation
effects:
- type: policy
...
```
The goal is therefore not a single huge mandatory schema.
The object should consist of:
```text
small mandatory kernel
+
optional envelopes
```
## 3. Kernel
Conceptual kernel:
```yaml
decision:
id:
question:
kind:
state:
context:
owner:
alternatives:
commitment:
rationale:
created_at:
```
Only a minimal subset needs to be populated.
## 4. Frame envelope
```yaml
frame:
situation:
trigger:
scope:
horizon:
boundaries:
assumptions:
exclusions:
stakeholders:
dependencies:
```
The frame answers:
> What problem do we believe we are deciding?
The frame must itself remain challengeable.
## 5. Alternatives / interventions
```yaml
alternatives:
- id:
action:
description:
prerequisites:
reversibility:
reversal_cost:
```
Canonical alternatives may include:
- act,
- do nothing,
- wait,
- delegate,
- investigate,
- experiment,
- combine alternatives.
## 6. Evidence / belief envelope
```yaml
evidence:
observations: []
claims: []
sources: []
assumptions: []
models: []
uncertainties: []
```
Claims may carry:
```yaml
claim:
statement:
status: observed | estimated | assumed | inferred
confidence:
source:
valid_at:
```
The system should preserve what was known at decision time.
## 7. World / causal model
```yaml
world_model:
variables:
states:
relationships:
causal_model:
scenarios:
```
The model should be capable of distinguishing prediction from intervention:
```text
P(Y | X)
```
versus:
```text
P(Y | do(X))
```
Multiple competing models may coexist.
## 8. Value envelope
```yaml
values:
objectives:
constraints:
preferences:
thresholds:
vetoes:
tradeoffs:
```
Constraints and vetoes should not be forced into weighted objectives.
Example:
```yaml
objectives:
- minimize operating cost
- maximize delivery speed
constraints:
- customer data remains in approved jurisdictions
vetoes:
- unacceptable safety risk
```
## 9. Analysis envelope
```yaml
analysis:
methods:
models:
results:
sensitivity:
robustness:
recommendation:
confidence:
```
Multiple analyses may coexist.
## 10. Uncertainty envelope
```yaml
uncertainty:
known_unknowns:
model_uncertainty:
outcome_uncertainty:
ambiguity:
reducible:
irreducible:
decision_relevance:
```
The key practical question is:
> Could resolving this uncertainty change the decision?
## 11. Information acquisition
```yaml
information_options:
- question:
method:
cost:
delay:
expected_information_value:
```
This models investigation as a first-class decision option.
## 12. Governance envelope
```yaml
governance:
authority:
decision_owner:
advisors:
approvers:
challengers:
affected_parties:
delegation:
escalation:
oversight:
```
Authority can be represented as:
```yaml
authority:
can: true
may: true
scope: tenant
source: POLICY-SEC-004
```
## 13. Commitment
```yaml
commitment:
selected:
by:
at:
mode:
confidence:
conditions:
reservations:
```
Modes may include:
- `decided`
- `approved`
- `accepted`
- `consented`
- `voted`
- `ordered`
- `delegated`
- `automatically-selected`
A recommendation is not yet a decision.
A decision exists when an authorized commitment occurs.
## 14. Conditional decisions
```yaml
commitment:
selected: scale-out
effective_when:
- cpu_utilization > 80%
- duration > 15m
```
This bridges one-time decisions and reusable policy.
## 15. Execution envelope
```yaml
execution:
intended_actions:
responsible:
status:
started_at:
completed_at:
evidence:
```
The model distinguishes:
```text
decided
executed
effective
```
## 16. Outcome envelope
```yaml
outcome:
observations:
metrics:
unintended_effects:
stakeholder_effects:
occurred_at:
```
Outcome observations should not overwrite the original decision-time model.
## 17. Learning envelope
```yaml
learning:
expected:
observed:
deviations:
hypothesis_updates:
calibration:
lessons:
followup_decisions:
```
This allows post-decision questions such as:
- Which assumptions failed?
- Was confidence calibrated?
- Did the causal model hold?
- Was the decision method appropriate?
- Should policy change?
## 18. Optionality
```yaml
optionality:
reversible:
reversal_cost:
reversal_delay:
locks_in:
options_created:
options_destroyed:
```
## 19. Temporal model
The object should distinguish:
- decision time,
- execution time,
- observation time,
- current time.
The system must not rewrite historical epistemic state with later knowledge.
## 20. Effects
Decision effects may target:
- world state,
- resources,
- permissions,
- delegations,
- policies,
- constraints,
- defaults,
- incentives,
- future decision rules.
A policy decision may therefore produce:
```yaml
effects:
- type: policy
policy:
scope: production-deployment
permit:
- autonomous deployment at low risk
require:
- human approval at high risk
prohibit:
- autonomous platform-root changes
```
## 21. Policy recursion
```text
Operational decision
↓
changes world state
Policy decision
↓
changes future decision state space
Constitutional decision
↓
changes how policy and authority may change
```
This recursion is a foundational capability of the model.
## 22. Decision graph
Decision Objects should be linkable through typed relationships.
This forms a Decision Graph capable of representing authority and causal lineage through an ecosystem.

630
history/2026-10-04-initial-exploration.md Normal file
View file

@ -0,0 +1,630 @@
# Initial Exploration Transcript
**Repository:** `decision-canon`
**Date:** 2026-10-04
**Purpose:** Preserve the initial conceptual exploration that led to the first seed of the Decision Canon.
---
## 1. User — Initial request
> Let's talk about decision theory and decision modelling and taking frameworks. Provide me an overview of the current body of work and practical systems.
---
## 2. Assistant — Field synthesis
The exploration separated decision-related work into four broad questions:
1. What should a rational actor choose?
2. How do humans actually choose?
3. How can a real decision be improved?
4. How can repeatable decisions be encoded and executed in software?
The resulting landscape included:
- normative decision theory,
- behavioral decision theory,
- Bayesian decision analysis,
- causal decision theory,
- multi-criteria decision analysis,
- operations research,
- robust decision making,
- sequential decision theory,
- game theory,
- naturalistic decision making,
- complexity-oriented approaches,
- organizational decision rights,
- DMN and executable decision systems,
- reinforcement learning,
- and human–AI decision delegation.
A central synthesis emerged:
> Decision theory asks what choice is justified; decision modelling represents the choice situation; decision taking commits an actor to an action; decision management governs and learns from repeated decisions.
Key ideas identified:
### Expected utility
```text
choose the action with the best expected value
```
### Bayesian decision analysis
Explicit uncertainty and Value of Information allow the system to ask not only:
> What should I choose?
but:
> What should I learn before choosing?
### Influence diagrams
A promising representation combining:
- chance,
- information,
- decisions,
- consequences,
- value.
### Causal decision making
The distinction between:
```text
P(Y | X)
```
and:
```text
P(Y | do(X))
```
was identified as crucial for actionable decision systems.
### Multi-objective decisions
Objectives, constraints, thresholds, and vetoes should remain distinct.
A hard safety or legal constraint should not simply become another weighted criterion.
### Optimization
A distinction was proposed:
> Decision analysis selects. Optimization synthesizes.
### Sequential decisions
For repeated decisions the relevant object becomes a policy rather than a single choice.
### Robustness
When the model or probability distribution is uncertain, robustness can matter more than expected-value optimality.
### Bounded rationality
Decision effort has a cost.
A useful conceptual extension was:
```text
Decision Value
- Decision Cost
- Delay Cost
```
### Naturalistic decision making
Experienced operators often recognize a pattern and mentally simulate one viable action rather than exhaustively compare many alternatives.
### Complexity
In complex adaptive systems the appropriate cycle may be:
```text
probe
→ observe
→ adapt
```
rather than:
```text
analyze
→ decide
→ execute
```
### Game theory
Competitive environments must be treated as adaptive systems containing other decision makers.
### Decision quality
A core distinction:
```text
DecisionQuality != OutcomeQuality
```
A good decision can have a bad outcome and vice versa.
### Organizational authority
The exploration separated:
```text
propose
advise/challenge
authorize
execute
```
and emphasized that:
```text
can != may
```
### Enterprise decision modelling
DMN was identified as an important practical standard for executable decision logic, while noting that it does not cover framing, evidence acquisition, policy evolution, or decision learning.
### AI and delegation
Human/AI arrangements were treated as a delegation problem:
```text
human decides
AI advises
AI proposes / human approves
AI decides / human supervises
AI decides / human can intervene
AI autonomously decides
```
The overall lifecycle synthesis was:
```text
Sense
↓
Frame
↓
Generate alternatives
↓
Model consequences
↓
Evaluate
↓
Choose
↓
Authorize
↓
Commit
↓
Act
↓
Observe
↓
Learn
```
The exploration concluded that a useful future architecture should treat decisions as first-class objects rather than isolated acts.
---
## 3. User — Unified Decision Object request
> design a unified decision object from these explorations i would like to come up with something that can model very simple informal decisions up to formal complicated decisions about policy that shapes the rules the ecosystem evolves from.
---
## 4. Assistant — Unified Decision Object synthesis
The design goal became:
> one semantic object, progressive formality.
A Decision Object should represent an intentional commitment made in response to a decision situation and should scale from:
```text
"Let's use PostgreSQL."
```
to:
```text
"Adopt a constitutional platform policy defining which classes of security decisions may be delegated to autonomous agents."
```
### Core lifecycle
```text
Situation
↓
Decision need
↓
Frame
↓
Options / interventions
↓
Evaluation
↓
Commitment
↓
Effect
↓
Observation
↓
Learning
```
For policy decisions:
```text
Decision
↓
Policy / Rule / Constraint / Delegation
↓
Changes future decision spaces
↓
Future decisions
↓
Observed ecosystem evolution
↓
Policy review
↓
Revised decision
```
### Design principles
#### Progressive formality
A simple choice should not require complex modelling.
A policy decision should support arbitrary depth.
#### Explicit incompleteness
The object should distinguish:
```text
unknown
not-applicable
not-investigated
estimated
assumed
observed
derived
decided
```
#### Choice and reasoning are different
The model should separate:
```text
what was decided
why it was decided
what happened because of it
```
#### Evidence and values are different
A factual claim and a preference are not the same type of object.
#### Capability and authority are independent
The model should distinguish:
```text
can
may
should
will
did
```
#### Constitutive decisions
Some decisions do not merely change world state.
They change who may decide, what alternatives exist, what evidence is required, and when escalation occurs.
These were termed **constitutive** or **constitutional** decisions.
### Decision kinds
The following initial taxonomy emerged:
```text
choice
bet
experiment
commitment
delegation
allocation
authorization
exception
policy
constitutional
```
### Decision state
Suggested lifecycle:
```text
noticed
→ framed
→ open
→ recommended
→ committed
→ effective
→ observed
→ reviewed
→ closed
```
With side transitions such as:
```text
deferred
delegated
cancelled
expired
superseded
revoked
```
The semantic importance of `committed` was emphasized.
### Optional envelopes
The Decision Object was divided into a small kernel plus optional envelopes:
- frame,
- alternatives,
- evidence,
- world / causal model,
- values,
- analysis,
- uncertainty,
- information acquisition,
- governance,
- commitment,
- execution,
- outcome,
- learning,
- optionality.
### Decision methods
The model should record rather than prescribe the method used.
Possible methods include:
```text
intuition
expert judgment
heuristic
checklist
weighted scoring
MCDA
expected utility
Bayesian decision analysis
value of information
optimization
simulation
scenario analysis
robust decision making
causal analysis
game-theoretic analysis
MDP/POMDP
deliberation
vote
consensus
AI-assisted synthesis
```
### Governance
A decision can explicitly record authority:
```yaml
authority:
can: true
may: true
scope: tenant
source: POLICY-SEC-004
```
### Decision taking
A recommendation is not a decision.
A decision exists when an authorized commitment has occurred.
### Execution
The model distinguishes:
```text
decided
executed
effective
```
### Outcome and learning
Observed outcomes must not overwrite original decision-time reasoning.
The object should preserve enough temporal structure to ask:
- Which assumption failed?
- Was confidence calibrated?
- Was the method appropriate?
- Should policy change?
### Reversibility and optionality
A decision may record:
```text
reversible
reversal cost
reversal delay
lock-in
options created
options destroyed
```
### Formality scale
An initial scale was proposed:
```text
D0 Ephemeral
D1 Recorded
D2 Structured
D3 Analyzed
D4 Governed
D5 Executable
D6 Policy
D7 Constitutional
```
The levels describe formalization, not intrinsic quality.
### Policy primitives
Initial primitives:
```text
permit
prohibit
require
constrain
default
prefer
incentivize
delegate
escalate
observe
review
expire
```
### Decision graph
Decisions should be linkable using relationships such as:
```text
derived-from
implements
governed-by
delegated-by
authorized-by
triggered-by
depends-on
challenges
reviews
supersedes
revokes
exception-to
resulted-in
learned-from
```
### Decision lineage
For an observed action, the system should eventually be able to answer:
> Why was this allowed to happen?
by tracing:
```text
Observed action
↑
Execution
↑
Decision
↑
Delegated authority
↑
Policy
↑
Policy decision
↑
Constitutional decision
```
The inverse traversal should explain what downstream behavior a policy enabled or constrained.
### Abstract definition
The Decision Object was summarized as:
```text
D = (F, K, A, V, M, G, C, E, O, L)
```
where:
- F — Frame
- K — Knowledge
- A — Alternatives
- V — Values
- M — Method
- G — Governance
- C — Commitment
- E — Effect / Execution
- O — Observation
- L — Learning
A minimal decision may instantiate only:
```text
(F, A, C)
```
while a constitutional decision may instantiate nearly the whole structure.
### Central invariant
> A Decision Object records an authorized commitment made from a particular frame, knowledge state and value system, together with its intended effects and sufficient lineage to observe and learn from what follows.
---
## 5. User — Repository seed request
> Let's build the seed for a decision-canon from what we discussed. Can you generate a zip file with relevant artefacts and include a timestamped md file in a history/ subdir with a transcript of this initial exploration.
---
## 6. Seed created
The initial repository seed contains:
```text
decision-canon/
├── README.md
├── INTENT.md
├── DecisionCanon.md
├── UnifiedDecisionObject.md
├── DecisionObjectSchemaDraft.md
├── ResearchProgram.md
├── Glossary.md
└── history/
└── 2026-10-04-initial-exploration.md
```
This transcript intentionally preserves the initial conceptual path rather than only the polished result, so later revisions can reconstruct why particular concepts entered the canon.