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

Record the schema probe for DECISION-WP-0002.

Browse source 
Add six illustrative decisions and the pressure note, and open DECISION-WP-0003 for the kernel proposal.

Assistant: grok
Assistant-Session: 01a1082a-858c-7fe2-9b5a-0b5332107eb3
This commit is contained in:
tegwick 2026-10-04 20:50:42 +02:00
parent 1c0058a2c8
commit f7f440dfff
13 changed files with 510 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

2
AGENTS.md
View file

@ -263,7 +263,7 @@ Read in this order before editing a concept: `INTENT.md`, `SCOPE.md`, `DecisionC
Verification is editorial. After a change, re-read the edited document against `SCOPE.md` and the non-goals in `INTENT.md`. A simple decision must still be writable without the heavy fields. Policy and constitutional decisions stay decisions whose effects shape later decisions.
Do not add a normative schema, a runtime, or an example set inside an unrelated edit. Schema pressure from examples is `DECISION-WP-0002`. Identifiers such as `DEC-...` inside canon prose are concept ids, not State Hub work-record ids.
Do not add a normative schema, a runtime, or further examples inside an unrelated edit. Schema pressure from the six examples is `reviews/schema-pressure.md`. A kernel proposal is `DECISION-WP-0003`. Identifiers such as `DEC-EX-NNN` are example identity ids, not State Hub work-record ids.
Workplan files are the source of task state. From this checkout, after changing them:

2
README.md
View file

@ -37,6 +37,8 @@ decision-canon/
├── DecisionObjectSchemaDraft.md
├── ResearchProgram.md
├── Glossary.md
├── examples/
├── reviews/
├── history/
│ └── 2026-10-04-initial-exploration.md
└── workplans/

2
SCOPE.md
View file

@ -25,7 +25,7 @@ A research canon for one decision object that can stay light for an informal cho
## Current state
Milestone M0, the concept seed, is in the repository: intent, canon, decision object, schema draft, glossary, and the 2026-10-04 exploration history. There is no `examples/` directory, no `schemas/` directory, and no validation command. The next work is [DECISION-WP-0002](workplans/DECISION-WP-0002-schema-probe.md): six diverse examples and a note on where the draft schema is awkward.
Milestone M0, the concept seed, is in the repository. [DECISION-WP-0002](workplans/DECISION-WP-0002-schema-probe.md) added six illustrative examples under `examples/` and the pressure note `reviews/schema-pressure.md`. The schema draft is still unfrozen, and there is still no validation command and no normative schema. The next work is [DECISION-WP-0003](workplans/DECISION-WP-0003-kernel-proposal.md): propose the kernel boundary from that note.
## Getting oriented

12
examples/DEC-EX-001-database-choice.md Normal file
View file

@ -0,0 +1,12 @@
# DEC-EX-001 — Database for the new service
Situation: trivial engineering choice.
Formality D1 from `DecisionCanon.md`: the question, the choice, and the reason. This is the lightweight shape in `UnifiedDecisionObject.md`. It is not filled out to the schema draft.
```yaml
decision:
question: Which database should we use for the new service?
choice: PostgreSQL
reason: It is sufficient and already operationally familiar.
```

72
examples/DEC-EX-002-schema-ownership.md Normal file
View file

@ -0,0 +1,72 @@
# DEC-EX-002 — Who owns the service schema
Situation: architecture decision.
Two services already share one database. A third service is about to need tables. The example keeps the sections that were needed to record the commitment and the disagreement. It leaves optionality, evidence, uncertainty, execution, and outcome absent.
```yaml
decision:
identity:
id: DEC-EX-002
title: Who owns the service schema
namespace: decision-canon/examples
question:
text: Should each service own its database schema, or should services share one schema?
decision_class: architecture
trigger: A second service needs tables, and the shared schema already blocks releases.
kind:
primary: choice
state:
lifecycle: committed
since: "2026-04-02"
frame:
situation: Two services write the same database. Releases wait on each other's migrations.
scope: New services on this platform. Existing shared tables stay until a later move.
horizon: The next two years of service splits.
assumptions:
- Each service has one team that can review its own migrations.
exclusions:
- The database product is out of scope. See DEC-EX-001.
alternatives:
- id: A
label: Service-owned schema
action: Give each service its own schema and its own migration stream.
reversibility:
level: costly
cost: A data move and a dual-write period.
delay: One or two release cycles.
- id: B
label: Keep the shared schema
action: Do nothing structural. Coordinate migrations in one queue.
reversibility:
level: easy
delay: none
values:
objectives:
- Services can release without waiting on another team's migration.
constraints:
- A migration is reversible, or it is rehearsed before production.
vetoes:
- Two services write one table and mean different things by a column.
world_model:
causal_model: Separate schemas remove migration coupling. They do not remove cross-service calls.
analysis:
analyses:
- id: a1
method: expert judgment
result: Service-owned schemas match how the teams already want to release.
confidence: high
- id: a2
method: expert judgment
result: One shared schema stays simpler until a third service, and the coupling is still tolerable.
confidence: medium
recommendation: Service-owned schema
commitment:
selected: A
by: platform owner
at: "2026-04-02"
mode: decided
confidence: high
governance:
owner: platform owner
```

78
examples/DEC-EX-003-incident-rollback.md Normal file
View file

@ -0,0 +1,78 @@
# DEC-EX-003 — Roll back the checkout API
Situation: incident-response decision.
Checkout started failing after a deploy. The rollback was ordered before the cause was known. The next day's observation contradicted the decision-time assumption. Both moments are on this object. Fields that were not known at either moment are absent.
```yaml
decision:
identity:
id: DEC-EX-003
title: Roll back the checkout API
namespace: decision-canon/examples
question:
text: The checkout API is failing after the 14:10 deploy. Roll back, forward-fix, or wait?
trigger: The error rate stayed above the paging threshold for ten minutes.
kind:
primary: choice
state:
lifecycle: observed
since: "2026-05-11T15:05:00Z"
frame:
situation: New checkout sessions fail. Payments that were already taken are completing.
horizon: The next hour.
assumptions:
- The 14:10 deploy is the only material change.
alternatives:
- id: A
label: Roll back
action: Restore the previous release.
reversibility:
level: easy
delay: About ten minutes.
- id: B
label: Forward-fix
action: Patch the suspected null check and deploy that patch.
- id: C
label: Wait
action: Watch for fifteen more minutes before changing production.
uncertainty:
known_unknowns:
- Whether the errors come from the deploy or from a downstream timeout.
reducible:
- A log comparison could show whether the new build is on the error path.
irreducible:
- Sessions that already failed cannot be reconstructed by this decision.
commitment:
selected: A
by: incident lead
at: "2026-05-11T14:28:00Z"
mode: ordered
confidence: low
reservations:
- The cause was not confirmed. Rollback was chosen because it was reversible.
execution:
intended_actions:
- Restore the previous release.
responsible:
- incident lead
status: completed
completed_at: "2026-05-11T14:41:00Z"
outcome:
observations:
- The error rate returned to baseline after the rollback.
unintended_effects:
- The price test in the new release stopped with it.
occurred_at: "2026-05-11T14:45:00Z"
learning:
expected: Checkout recovers if the deploy is the cause.
observed: Checkout recovered. The next day the same error returned without that deploy, from the downstream timeout.
deviations:
- The assumption that the deploy was the only material change was false.
lessons:
- The reversible rollback was still the commitment to make under that uncertainty.
- The later observation does not replace the decision-time assumption.
temporal:
decision_time: "2026-05-11T14:28:00Z"
observed_at: "2026-05-12T09:00:00Z"
```

57
examples/DEC-EX-004-scanning-exception.md Normal file
View file

@ -0,0 +1,57 @@
# DEC-EX-004 — Time-bounded scanning exception
Situation: security exception.
A migration needs a few days without malware scanning on one batch job. The exception is a decision, an authorization effect, and a relationship to the deploy policy in `DEC-EX-005`. Expiry is recorded in every place the draft offers a time bound.
```yaml
decision:
identity:
id: DEC-EX-004
title: Time-bounded exception for the partner upload
namespace: decision-canon/examples
question:
text: May the partner-upload job skip malware scanning until Friday so this migration can finish?
decision_class: security-exception
kind:
primary: exception
secondary:
- authorization
state:
lifecycle: effective
since: "2026-06-01"
governance:
owner: security owner
authority:
source: DEC-EX-005
scope: The partner-upload batch job, for this migration only.
may: Grant a scanning exception of at most five days.
must: Name an expiry and a residual control.
approvers:
- security owner
affected_parties:
- the team that receives the uploaded files
commitment:
selected: Skip malware scanning until 2026-06-05, and write only to the quarantine bucket.
by: security owner
at: "2026-06-01"
mode: approved
conditions:
- The exception ends at 2026-06-05T00:00:00Z even if the migration is unfinished.
effects:
- id: e1
type: authorization
target: partner-upload batch job
value: Skip malware scanning. Write objects only to the quarantine bucket.
effective_when: "2026-06-01T00:00:00Z"
expires_when: "2026-06-05T00:00:00Z"
relationships:
- type: exception-to
target: DEC-EX-005
temporal:
decision_time: "2026-06-01"
effective_from: "2026-06-01"
effective_until: "2026-06-05"
metadata:
formality_level: D4
```

45
examples/DEC-EX-005-deploy-policy.md Normal file
View file

@ -0,0 +1,45 @@
# DEC-EX-005 — Production deploy rule
Situation: deployment policy.
This is the decision that adopts a reusable rule for later production deploys. `DEC-EX-004` is an exception to it. The rule text sits in one effect. There is no separate executable form.
```yaml
decision:
identity:
id: DEC-EX-005
title: Production deploy rule
namespace: decision-canon/examples
version: "1"
question:
text: What rule governs a production deploy from now on?
decision_class: policy
kind:
primary: policy
state:
lifecycle: effective
since: "2026-03-01"
commitment:
selected: Adopt the production deploy rule.
by: platform owner
at: "2026-03-01"
mode: decided
effects:
- id: e1
type: policy
target: production deploys
value: >
A production deploy names its rollback, comes from a reviewed change,
and runs only artifacts that passed malware scanning.
A deploy that cannot meet a clause needs an exception decision.
effective_when: on adoption
governance:
owner: platform owner
authority:
source: platform operating charter
scope: Production deploys of services this platform runs.
may: Set deploy rules for this platform.
metadata:
formality_level: D6
schema_version: "0.1"
```

55
examples/DEC-EX-006-binding-policy-rule.md Normal file
View file

@ -0,0 +1,55 @@
# DEC-EX-006 — Who may create a binding policy
Situation: constitutional governance rule.
The decision changes the rule by which later policy decisions may be adopted, and it says how this rule itself may be changed. Nothing is superseded yet, so there is no `relationships` entry. `DEC-EX-005` is the kind of later policy this rule would constrain.
```yaml
decision:
identity:
id: DEC-EX-006
title: Who may create a binding policy
namespace: decision-canon/examples
version: "1"
question:
text: Who may create a policy that binds other teams, and how may that rule itself be changed?
kind:
primary: constitutional
state:
lifecycle: effective
since: "2026-02-01"
frame:
situation: Teams have published deploy and access rules that bind other teams without a recorded authority.
scope: Policies whose effects constrain decisions outside the author's own service.
governance:
owner: founder
authority:
source: the decision to constitute this platform's decision rights
scope: How binding policies are created and changed.
can: The founder can edit the policy repository.
may: Only a decision of kind constitutional may change who is allowed to adopt a binding policy.
must: The role that executes a policy is not the only role that adopts it.
approvers:
- founder
commitment:
selected: A binding policy records its authority source, and the executing role is not its only adopter.
by: founder
at: "2026-02-01"
mode: decided
effects:
- id: e1
type: requirement
target: future policy decisions
value: >
A policy whose effects bind another team records governance.authority.source.
When commitment.by is also the actor who executes the policy,
governance.approvers names at least one other actor.
- id: e2
type: constraint
target: future constitutional decisions
value: >
Changing this rule is a new constitutional decision that supersedes DEC-EX-006.
The change does not edit this object in place.
metadata:
formality_level: D7
```

24
examples/README.md Normal file
View file

@ -0,0 +1,24 @@
# Examples
Illustrative fixtures for probing `DecisionObjectSchemaDraft.md`. They are not records of operational decisions.
## File shape
One Markdown file per decision. The decision is a single YAML block. Populate only the sections the situation needs. Leave unknown fields absent. Do not add a JSON Schema.
The decision's identity id has the form `DEC-EX-NNN`. That id is an example identity. It is not a State Hub work-record id.
`DEC-EX-001` uses the D1 shape from `UnifiedDecisionObject.md`: `question`, `choice`, and `reason`. It does not repeat the id inside the YAML, because that shape has no identity section. The other five examples use schema-draft sections only, and they carry `identity.id`.
## Situations in DECISION-WP-0002
| Id | Situation | File |
| --- | --- | --- |
| `DEC-EX-001` | Trivial engineering choice | [DEC-EX-001-database-choice.md](DEC-EX-001-database-choice.md) |
| `DEC-EX-002` | Architecture decision | [DEC-EX-002-schema-ownership.md](DEC-EX-002-schema-ownership.md) |
| `DEC-EX-003` | Incident-response decision | [DEC-EX-003-incident-rollback.md](DEC-EX-003-incident-rollback.md) |
| `DEC-EX-004` | Security exception | [DEC-EX-004-scanning-exception.md](DEC-EX-004-scanning-exception.md) |
| `DEC-EX-005` | Deployment policy | [DEC-EX-005-deploy-policy.md](DEC-EX-005-deploy-policy.md) |
| `DEC-EX-006` | Constitutional governance rule | [DEC-EX-006-binding-policy-rule.md](DEC-EX-006-binding-policy-rule.md) |
Hiring, procurement, investment, budget allocation, and public-style policy are not in this set. They stay deferred in `DECISION-WP-0003` until a kernel proposal says whether more situations would show something these six did not.

106
reviews/schema-pressure.md Normal file
View file

@ -0,0 +1,106 @@
# Schema pressure from the six examples
Probe for `DECISION-WP-0002`. The schema draft was not changed. No example was blocked on a missing clarification. The awkwardness below is the result.
Question numbers are `ResearchProgram.md` section 7.
The examples are illustrative fixtures. They are not operational decisions.
## DEC-EX-001 — trivial engineering choice
Necessary: `question`, `choice`, and `reason`. Those three keys are the D1 shape in `UnifiedDecisionObject.md` and `DecisionCanon.md`. They are not sections of `DecisionObjectSchemaDraft.md`.
Awkward:
- The draft's `question` is an object with `text`, `decision_class`, and `trigger`. The D1 shape needs a string.
- The draft has no `choice` field. The nearest commitment field is `commitment.selected`.
- The draft has no `reason` or `rationale` field. `UnifiedDecisionObject.md` puts `rationale` in the conceptual kernel. The draft does not.
- Recording this choice with only draft sections would add `identity`, `kind`, `state`, and `commitment`, which the situation does not need.
Questions: 1, 2. The irreducible kernel is smaller than the draft's top-level shape, and this decision is recognizable without a `commitment` section.
## DEC-EX-002 — architecture decision
Necessary: `identity`, `question`, `kind`, `state`, `frame`, `alternatives` (including an explicit do-nothing alternative), `values` split into objectives, constraints, and vetoes, `analysis` with two results, `commitment`, and `governance.owner`.
Awkward:
- `world_model` is singular and has one `causal_model`. The losing analysis (`a2`) had a different causal story and had nowhere to live except as a second `analysis` entry. Two analyses fit. Two world models do not.
- `commitment.selected` is the alternative id `A`. The draft does not say that `selected` points at `alternatives[].id`.
- `question.trigger` holds what `UnifiedDecisionObject.md` puts on `frame.trigger`. The same fact has two homes, and this example used the draft's home.
- `alternatives[].reversibility` overlaps the unused top-level `optionality` section. The example did not need both, and the draft does not say which one wins.
- `confidence: high` and `confidence: medium` are words. The field does not say whether a number is required.
Questions: 1, 4, 8.
## DEC-EX-003 — incident-response decision
Necessary: `alternatives` (rollback, forward-fix, and wait), `uncertainty`, `commitment` with a reservation, `execution`, `outcome`, `learning`, and `temporal` so decision time and observation time stay distinct.
Awkward:
- `state.lifecycle` has one value. After the outcome it is `observed`, so the fact that it was `committed` survives only in `commitment.at` and `temporal.decision_time`. The lifecycle is not a history.
- The false assumption still sits in `frame.assumptions`. Nothing marks that list as sealed at `commitment.at`. A later edit can delete it and make the decision look as if the downstream timeout had been known.
- `learning` can carry the correction, which is what this example does. The draft does not say that `learning` is the only place a later fact may appear.
- `commitment.confidence: low` is a word again, next to an untyped `uncertainty` list. The example did not need a probability to be specific.
Questions: 2, 8, 9. Commitment was the boundary that made this a decision rather than a note. Versioning has to preserve the decision-time assumption, not only `identity.version`.
## DEC-EX-004 — security exception
Necessary: `kind.primary: exception` with `secondary: authorization`, `governance.authority`, `commitment`, an `effects` entry of type `authorization`, `relationships` of type `exception-to` pointing at `DEC-EX-005`, and a time bound.
Awkward:
- The same expiry is in `commitment.conditions`, `effects[].expires_when`, and `temporal.effective_until`. The draft does not say which one is normative.
- `authority.may` and `authority.must` are sentences. `UnifiedDecisionObject.md` shows `can` and `may` as booleans. Neither document says which.
- `authority.source` is the string `DEC-EX-005`. There is no structured provenance from that policy's own authority to this exception.
- The exception is at once a decision kind, a secondary kind `authorization`, and an effect type `authorization`. All three were useful, and the draft does not say they are one fact or three.
Questions: 3, 5, 9.
## DEC-EX-005 — deployment policy
Necessary: `kind.primary: policy`, a `commitment` that adopts the rule, one `effects` entry of type `policy` holding the rule text, and `governance.authority` for who may set the rule.
Awkward:
- The policy is both the decision and an effect of type `policy` on that same decision. Question 3 is visible in one object: both representations were needed, and they repeat each other.
- Later deploys would be `governed-by` this id. The relationship list has `governed-by` and no inverse. This object cannot point at the class of decisions it governs except through `effects[].target: production deploys`, which is a phrase, not an id.
- The rule is prose in `effects[].value`. There is no field for a structured condition, a DMN table, or an OPA-style expression. `commitment` has `conditions` in the draft, and this example left them unused because they would have been a third copy of the prose.
- `UnifiedDecisionObject.md` puts `effective_when` on `commitment`. The draft puts `effective_when` on an effect and `conditions` on the commitment.
Questions: 3, 7, 10. An executable form is not a small step from this object. Reusing a rule language would need a place to put it.
## DEC-EX-006 — constitutional governance rule
Necessary: `kind.primary: constitutional`, `frame`, `governance` with `can` / `may` / `must`, a `commitment`, and two effects. One effect constrains later policy decisions. The other says a change to this rule is a new decision that supersedes `DEC-EX-006` rather than an edit of this object.
Awkward:
- Effect types include `policy` and `constraint`. They do not include `constitutional`. The constitutional character exists only on `kind`.
- `effects[].target` is the class `future policy decisions`, not an id. The draft's `target` is used elsewhere for a job name (`DEC-EX-004`) and for a class (`DEC-EX-005`). The field does not distinguish them.
- The nesting rule is prose inside effect `e2`. Nothing records depth, or that this decision is a rule about rules. A later constitutional decision can supersede this id, but the relationship type `supersedes` belongs on that later object. This object can only narrate the requirement.
- `authority.source` is a sentence about constituting decision rights. The provenance does not point at another decision id, because there is no prior object. Question 5 stays open for the root of authority.
- `can`, `may`, and `must` are sentences again. Here they are the content of the decision, so a boolean would have been too small. The draft uses one shape for both a boolean capability and a rule.
Questions: 3, 5, 6.
## What the six show together
| Question | Where it showed up |
| --- | --- |
| 1. Irreducible kernel | `DEC-EX-001` is a decision with three keys the draft does not name. `DEC-EX-002` needed many sections the trivial choice did not. |
| 2. Is commitment required? | `DEC-EX-001` has no commitment section. `DEC-EX-003` became a decision at `commitment.at`, before the outcome. |
| 3. Policy as object, effect, or both? | Both, in `DEC-EX-005` and `DEC-EX-006`. The exception in `DEC-EX-004` is also a kind and an effect. |
| 4. Competing world models | `DEC-EX-002` could store two analyses and only one `causal_model`. |
| 5. Authority provenance | `authority.source` is a string in `DEC-EX-004`, `DEC-EX-005`, and `DEC-EX-006`. `can` / `may` / `must` are untyped. |
| 6. Recursive policy changes | `DEC-EX-006` effect `e2` is prose. There is no structural end to "a decision about how decisions change." |
| 7. Which standards to reuse | `DEC-EX-005` has nowhere to put a DMN or OPA-style rule without inventing a field. |
| 8. Uncertainty without fake precision | Confidence values that mattered were the words `high`, `medium`, and `low`. |
| 9. Versioning and supersession | `DEC-EX-003` needs a sealed decision-time assumption, not only `identity.version`. `DEC-EX-004` has three expiry fields. `DEC-EX-006` forbids in-place edit and has no snapshot mechanism. |
| 10. Minimal executable form | Not answered by a prose `effects[].value`. |
`DecisionObjectSchemaDraft.md` was sufficient to write `DEC-EX-002` through `DEC-EX-006` without a new field. It was not sufficient for the D1 shape of `DEC-EX-001`. That difference is the kernel question, and it is the input to `DECISION-WP-0003`.
Example ids of the form `DEC-EX-NNN` sit on `identity.id` inside a `yaml` block in `DEC-EX-002` through `DEC-EX-006`. The State Hub consistency check treats an `id` line of that shape as an unregistered work-record id. The ids stay, because this workplan required them. They are example identities, not work records.

20
workplans/DECISION-WP-0002-schema-probe.md
View file

@ -4,7 +4,7 @@ type: workplan
title: "Probe the schema draft with a diverse decision set"
domain: infotech
repo: decision-canon
status: ready
status: finished
flavor: planning
depends_on: []
owner: codex
@ -43,31 +43,43 @@ Verification: each example file exists and uses only the schema-draft sections t
```task
id: DECISION-WP-0002-T01
status: todo
status: done
priority: high
state_hub_task_id: "ed427f4f-ddd1-535b-9c48-b4f4636a2ba9"
```
Add `examples/README.md` stating the file shape: one Markdown decision per file, an identity id of the form `DEC-EX-NNN`, and only the schema-draft sections the situation needs. Name the six situations this workplan covers, taken from ResearchProgram M1: a trivial engineering choice, an architecture decision, an incident-response decision, a security exception, a deployment policy, and a constitutional governance rule. Do not add a JSON Schema.
Done. The convention is in `examples/README.md`. `DEC-EX-001` is the D1 shape and does not repeat its id inside the YAML. The other five carry `identity.id`.
## Write the six examples
```task
id: DECISION-WP-0002-T02
status: todo
status: done
priority: high
state_hub_task_id: "3f325298-6d04-5913-8100-a7d8dd37ca88"
```
Write one example file for each situation named in T01. Keep the trivial choice to the question, the choice, and the reason. Let the constitutional example carry governance and effects on later decisions. Leave unknown fields absent.
Done. The six files are under `examples/`. `DEC-EX-001` is question, choice, and reason. `DEC-EX-006` carries governance and two effects on later decisions.
## Record schema pressure
```task
id: DECISION-WP-0002-T03
status: todo
status: done
priority: medium
state_hub_task_id: "18808c39-4b81-57df-892b-c3b2fddbb0bb"
```
Write `reviews/schema-pressure.md`. For each example, record which schema sections were necessary, which were awkward, and which questions from ResearchProgram section 7 the example raises. Stop when that note exists. Leave the schema draft unchanged unless an example cannot be written without one named clarification, and record that clarification in the note.
Done. The note is `reviews/schema-pressure.md`. `DecisionObjectSchemaDraft.md` is unchanged. No example needed a new field in order to be written. The D1 shape of `DEC-EX-001` uses keys the draft does not name, and that is recorded rather than patched into the draft.
## Evidence and handoff
The probe is finished. The successor is [DECISION-WP-0003](DECISION-WP-0003-kernel-proposal.md), which proposes the kernel cut from the note and does not edit the schema draft. The remaining M1 situations stay named there as deferred. They are not a second workplan yet, because more examples before that cut would repeat this probe.
Definition of Done is unassessed. This repository has no automated test suite.

41
workplans/DECISION-WP-0003-kernel-proposal.md Normal file
View file

@ -0,0 +1,41 @@
---
id: DECISION-WP-0003
type: workplan
title: "Propose the Decision Object kernel from the schema probe"
domain: infotech
repo: decision-canon
status: proposed
flavor: planning
depends_on: []
owner: codex
topic_slug: canon
lane: green
created: "2026-10-04"
updated: "2026-10-04"
---
# Propose the Decision Object kernel from the schema probe
Handoff from `DECISION-WP-0002`. The probe note is `reviews/schema-pressure.md`. This workplan turns that note into a proposed kernel cut. It does not edit `DecisionObjectSchemaDraft.md`, and it does not freeze the kernel.
## Scope
In scope: one proposal note. It names the smallest set of fields a D1 decision must be able to carry, and which draft sections stay optional envelopes. It takes its evidence from the six examples already written.
Out of scope: a change to the schema draft, a JSON Schema, and the remaining ResearchProgram M1 situations (hiring, procurement, investment, budget allocation, and public-style policy). Those examples stay deferred until this proposal says whether a new situation would show something the six did not. They are not a separate workplan yet.
Dependencies: none beyond the finished probe. The note is already in the tree.
Lane: `green`. Documentation in this repository only.
Verification: `reviews/kernel-proposal.md` exists, cites the pressure note, and states a D1 minimum and an envelope list. `DecisionObjectSchemaDraft.md` is unchanged by this workplan.
## Write the kernel proposal
```task
id: DECISION-WP-0003-T01
status: todo
priority: high
```
Write `reviews/kernel-proposal.md`. State which fields a trivial decision must be able to carry so that `DEC-EX-001` is a valid decision object, and which sections from `DEC-EX-002` through `DEC-EX-006` remain optional envelopes. Where the pressure note shows two homes for one fact, name the home the proposal keeps. Do not edit `DecisionObjectSchemaDraft.md`. Recommendations that would change the draft belong in the proposal note.