DOLCHEOT

DOLCHE (docs/oddkit/proactive/dolche-vocabulary.md) defined six dimensions of session capture: five artifact types for what happened (Decisions, Observations, Learnings, Constraints, Handoffs) and one meta-level action that tracks the crystallization itself (Encodes). Across many sessions DOLCHE worked well for retrospective tracking — it answered "what did we do, see, learn, and choose?" But it could not answer "what is still open?"

Unresolved threads had no home. Work that was started but not finished, questions raised but not answered, decisions pending further evidence — these either got buried inside narrative entries, forced into Handoffs they did not fit, or quietly dropped. Handoff is the wrong container for a live thread: a Handoff transfers work to another owner. An unresolved item that stays with the current owner, waiting for the next loop, is something else.

DOLCHEO adds Open as that something else. The second O joins the letter set — Decision, Observation (closed), Learning, Constraint, Handoff, Encode, Open. Both Os remain a single character; context in the journal makes clear which is which. Open items are typically listed under a dedicated section with priority bands (P1, P2, P3…) so the operator can see at a glance what is live and in what order. The agent-team-pilot ledger (odd/ledger/2026-04-19-agent-team-pilot.md) is the first ledger written against DOLCHEO and is the working example this document points to.

DOLCHEO is backward compatible with DOLCHE. Every DOLCHE journal is a valid DOLCHEO journal with zero Open items. Migration is additive: start capturing Open items, nothing else changes.

The eighth letter, Tension, is different in kind. Where the first seven are asserted — an author states what was decided, seen, learned, constrained, handed off, encoded, or left open — Tension is derived: a retrospective pass reads across the captured artifacts and surfaces what they contradict. For months this happened by accident, in the prose of encode output; DOLCHEOT makes it a first-class, typed, synthesized artifact. Tension is the only second-order dimension, and like Open it is additive: every DOLCHEO journal is a valid DOLCHEOT journal with zero Tensions. See odd/encoding-types/tension.md.

Decisions (D) — What was chosen. Explicit commitments with rationale. Decisions close options and create direction. They are the highest-stakes artifacts because they constrain all subsequent work. A decision without rationale is a debt (Axiom 2). A decision without a constraint test is untested.

Observations (O, closed) — What was seen or noticed, as a finished fact. Raw evidence without interpretation. Observations describe reality as encountered. A closed Observation is something that happened and is now history: a tool call completed, a test ran, a remote repository was in a particular state at a particular timestamp. An observation that nobody recorded is an observation that never happened for the system's purposes.

Learnings (L) — What was understood from the observations. Interpretation grounded in evidence. Learnings connect observations to meaning. They are the bridge between "what did we see?" and "what does it mean?" A learning without an observation is speculation. A learning with an observation is knowledge.

Constraints (C) — What now governs future work. Rules, boundaries, and non-negotiables that emerged from the session. Constraints bind future behavior, which makes them the artifacts most likely to prevent future mistakes. A constraint without enforcement is a suggestion.

Handoffs (H) — Transfer of work and context across an owner boundary. Another session, another agent, or another person picks up the artifact. The current owner is letting go. Handoffs describe what the receiver needs to resume productive work without reading the full prior transcript.

Encodes (E) — The meta-level action of crystallizing a D, O, L, C, H, or open O through oddkit's encode action. Each encode event records what was crystallized, what quality score it received, whether persistence was required, and what gaps remained. An Encode is a receipt, not content; it proves that crystallization happened. The E is what makes DOLCHEO self-auditing: a journal with five Decisions and zero Encodes is telling you the decisions were mentioned but never captured.

Opens (O, forward-pointing) — Unresolved threads that stay with the current owner. Work begun and awaiting next action, questions raised and awaiting answer, decisions pending further evidence, items deferred to the next pass. Open items carry a priority band (P1, P2, P3…) so the list is scannable. They close by becoming Decisions (resolved), Handoffs (transferred), or Observations (completed and now history).

Tensions (T, derived) — A contradiction or unresolved conflict visible only across two or more captured artifacts, never in a single one. Unlike the other seven, a Tension is not asserted by the author; it is inferred by a pass over the artifacts already captured — synthesized by default, advisory, and sha-bound to the artifacts it spans. It closes when an author resolves it (a Decision) or retracts a pole. Tension is the eighth letter and the first second-order dimension; see odd/encoding-types/tension.md.

Observation and Open share the letter O. This is deliberate. Introducing a separate letter for Open items (say, P for Pending or U for Unresolved) would have required retraining every downstream consumer — the encode tool, journal templates, search tags, existing literature, the agents already in the loop. DOLCHEO chose backward compatibility over letter-purity.

Disambiguation works by section placement, not by letter. Closed Observations appear in narrative flow alongside D, L, C, H, E entries describing what happened. Open items appear under a dedicated heading, typically titled ## Open items or ### Open items (forward-pointing), with priority bands. A reader scanning the ledger never has to guess which O is which: the section header tells them.

Markdown syntax for inline tagging follows the same principle. A closed Observation reads [O]. An Open item reads [O-open P1] or [O-open P2.1] — the -open suffix marks it as forward-pointing, and the band makes the priority explicit. Encode tooling that accepts type-prefixed input treats O as closed Observation by default and accepts O-open as the explicit forward-pointing variant.

The letter collision is a feature of the vocabulary's evolution, not a flaw. DOLCHE was written, shipped, used. Adding a new dimension without breaking the existing vocabulary was worth a small disambiguation rule.

The question that separates Open from Handoff is ownership: does the thread still belong to the current owner, or has it transferred?

Handoff means the current owner is letting go. The receiver now carries the context, the decision, the next action. The handoff document names who receives the work and what they need to know to continue. A handoff marks a boundary: on this side, the current session; on the other side, whoever picks it up next.

Open means the current owner still holds the thread. It is unresolved, not transferred. The same person or agent will return to it, either in this session or the next. Open items accumulate across a session as the work unfolds and get resolved, deferred, or (eventually) converted to Handoffs when a boundary is actually crossed.

Worked examples:

• "Next session needs to merge main→prod PR before touching new work" is a Handoff if the current session is ending and a fresh session will do the merge. It is Open if the current session is continuing and will do the merge after lunch.
• "Encode batch-mode feature is blocked on DOLCHEO canon landing" is Open if the operator intends to keep working on both in the same session. It is a Handoff if the session is ending and the next session owner picks up the encode work.
• "Tim and Ian need to review the swarm harness decision" is always a Handoff. The review is owned by someone other than the current session.
• "Not sure yet whether the encode response envelope should declare governance_source at the top level or inside a debug block; will see what the canary shape suggests" is Open. The decision stays with the current owner, pending evidence from the implementation.

A useful test: if the item is worded as "next session should…" or "Tim should…," it is a Handoff. If it is worded as "I need to…" or "we haven't yet decided…," it is an Open item.

Open items carry a priority band so the list is scannable without reading each entry. Bands are ordered P1, P2, P3… by descending priority — P1 is the next thing to do, P6 is the tenth-most-important. The number of bands is not fixed; most ledgers use P1–P3, larger arcs extend to P4–P6. The agent-team-pilot ledger ran from P1 to P5.

Sub-bands are allowed when a band has internal ordering: P1.1 runs before P1.2, both inside the P1 tier. The handoff that spawned this document used P1.1 (DOLCHEO canon doc) and P1.2 (encode batch-mode + canary refactor) to express "these are both the priority for the next session, in this order."

Bands are a communication tool, not a scheduling system. They say "if I only had time for one thing, which one?" — and answer by ordering. When a band is completed, its items move out of Open (into D, O-closed, or H as appropriate) and the remaining bands shift up or stay where they are at the author's discretion. Bands are not recomputed on every write.

The first seven dimensions are asserted: an author or agent states them as content. Tension is the exception — it is derived, computed by a pass over the other artifacts. This is what makes it the first second-order DOLCHEOT type and why it behaves differently from its siblings.

Synthesized by default. A Tension is emitted by a detection pass, not entered by an author, so its custody is synthesized — a regeneratable projection, never sovereign. An operator who asserts a contradiction in their own voice creates an authored Tension, which is sovereign and supersedes the inferred one. An author who resolves a Tension (a Decision) closes it by reference and drops its priority; the Tension is marked resolved, not deleted.

Advisory and sha-bound. A Tension is sha-bound to the artifacts it spans. When any of them changes, it goes stale and is re-derived — staleness detection is reliable, but re-derivation is not bitwise reproducible, because detection is an inference, not a deterministic transform. A false-positive Tension is dismissable and never blocks.

Three senses, one letter. "Tension" is overloaded; the T dimension is precise. The quality-attribute tradeoff (canon/principles/quality-attributes-are-in-tension) is one kind of Tension. The challenge-vs-canon contradiction surfaced by oddkit challenge is the challenge-time sibling. The DOLCHEOT T is the encode-time, within-source primitive: a contradiction across the captured artifacts. They share machinery; they are not the same artifact.

Why core, not a domain extension. The extension mechanism below admits domain-specific letters (P for Prayer, R for Rulings). Tension is not domain-specific — it emerged across every oddkit-powered project, in the prose of ordinary encodes. It is promoted into the core letter set for that reason.

A DOLCHEO-compliant session ledger looks roughly like this:

# Session Ledger — [date] [topic]

**Session opened:** [ISO 8601 timestamp]
**Mode at open:** [exploration | planning | execution | validation]
**Derives from:** [prior ledger / handoff URIs]

---

## Priority bands

- **P1** — [the primary objective]
- **P2** — [contingent objective if P1 converges cleanly]
- **P3** — [nice-to-have]

---

## DOLCHEO log

### [Phase name — e.g. "Session open"]

- **[D]** [Decision made, with rationale]
- **[O]** [Closed observation — a fact now in the record]
- **[L]** [Learning grounded in observations]
- **[C]** [Constraint that now governs future work]

### [Next phase]

- **[E]** [Encode event — what was crystallized, quality, persistence status]
- **[H]** [Handoff — work transferred to another owner]

---

## Open items (forward-pointing)

- **[O-open P1]** [Next thing to do; stays with current owner]
- **[O-open P2.1]** [Sub-banded item; runs before P2.2]
- **[O-open P2.2]** [Second sub-item in P2]
- **[O-open P3]** [Lower-priority thread still live]

The odd/ledger/2026-04-19-agent-team-pilot.md ledger is the first DOLCHEO-native ledger in the canon; read it as a working reference.

The oddkit_encode tool currently recognizes four hardcoded artifact types and collapses batched input into a single typed blob. DOLCHEOT expands the recognized set to eight and requires per-artifact output.

Concrete requirements that follow from this vocabulary:

1. The tool must accept prefix-tagged input for all eight letters: [D], [O], [L], [C], [H], [E], the Open variant ([O-open] or equivalent, with an optional priority band like [O-open P1]), and [T] for an authored Tension.
2. Batched input with multiple prefixes must return a per-artifact array, not a single collapsed blob. Each artifact gets its own quality score and persistence flag.
3. Single-artifact input without a prefix must still work — the existing heuristic that infers type from content remains as fallback.
4. The vocabulary itself must be read from this document at runtime, not hardcoded in the tool. That is the prompt-over-code pattern applied to encode — canon defines the vocabulary, code reads it, the three-tier resolution stack (live canon → bundled baseline → fail-loud) governs fallback.
5. Tension (T) is derived, not prefixed in the common case: after typing the assertable artifacts, the tool runs a detection pass across them and emits T rows for genuine cross-artifact contradictions, marked synthesized. An operator may also assert a [T] Tension directly. See odd/encoding-types/tension.md for the detection pass and quality criteria.

The implementation PR for these requirements is tracked separately from this canon doc; this document is the governance contract the tool must satisfy.

DOLCHEOT entries are structured data: each has a type (one of D / O / L / C / H / E / O-open / T), a timestamp, a summary, a body, tags, and — for Open items — a priority band. At personal scale, a few entries per session, markdown journals work well. At production scale, dozens per day across multiple projects, tabular formats like TSV or CSV offer faster parsing, easier appending, and cleaner git diffs.

Storage format is an implementation concern, not a vocabulary concern. DOLCHEOT defines what to capture. How entries are stored, indexed, and queried depends on the deployment context: markdown for human-readable journals, tabular formats for machine-queryable session history, or both in parallel. The vocabulary travels across any format that can carry the eight-letter type field.

DOLCHEOT's eight letters are defaults, not a closed set. Any knowledge base can extend the vocabulary by adding a governance document that defines a new type letter, describes when it should be used, gives examples of valid entries, and explains how it relates to the existing seven.

A pastoral knowledge base might add P for Prayer Requests. A legal knowledge base might add R for Rulings. A smart-home knowledge base might add A for Automations. The extension mechanism is governance, not code: the server infrastructure treats the type field as a string and searches, filters, and counts entries without needing to know what each letter means.

Prompt-over-code applies to the vocabulary itself. The defaults are universal. The extensions are domain-specific. The capability is open. The semantics are governed.

Tension (T) was the first letter promoted into the core set rather than added as a domain extension: it is universal, surfacing in every project's encode prose, so it earned a core letter rather than a knowledge-base-local one.

DOLCHEO is backward compatible with DOLCHE. All six original dimensions retain their definitions. The only additions are:

• The seventh letter, Open, as the forward-pointing counterpart to closed Observation.
• A convention for priority bands (P1, P2, P3…) on Open items.
• A disambiguation rule for the two Os (section placement, optional -open suffix for inline tags).

Existing DOLCHE journals do not need to be rewritten — they are valid DOLCHEO journals that happen to have zero Open entries. The trigger phrases "encode DOLCHE," "journal this," and "run the gauntlet" continue to work and invoke capture across all seven types; agents should use DOLCHEO in output regardless of which trigger phrase the operator uses.

Agents that were previously taught DOLCHE have one concrete behavior change: at session end, before writing the Handoff section, scan the session for unresolved threads and record them as Open items with priority bands. If there are genuinely none, note that explicitly. An absent Open section is different from an empty one; the former suggests the agent forgot, the latter confirms the agent checked.

From DOLCHEO to DOLCHEOT

DOLCHEOT adds one dimension: Tension (T), the derived contradiction. Every DOLCHEO journal is a valid DOLCHEOT journal with zero Tensions. The one behavior change: when encoding a session, after typing the assertable artifacts, run a detection pass across them and emit Tensions for genuine cross-artifact contradictions. Because Tension is derived and advisory, an absent Tension set is fine — it means the pass found none, or was not run; it is not a malformed journal.

DOLCHEO is a working vocabulary for session capture inside oddkit-powered knowledge bases, as of 2026-04-19. It is not presented as a universal claim about how teams should track work.

Where DOLCHEO applies: session journals and project ledgers maintained by an agent (or agent + operator pair) working inside an oddkit-powered project. The seven letters capture the epistemic state of one or more working sessions against a shared knowledge base.

Where DOLCHEO does not apply: product roadmaps, sprint backlogs, issue trackers, customer support queues, meeting minutes for multi-party decisions, and any system where the unit of tracking is a ticket owned by a team rather than a thread owned by a session. These systems have their own vocabularies and lifecycles and DOLCHEO neither replaces nor competes with them.

Prior art the Open letter relates to. The Open/Handoff distinction has relatives in several established systems: Getting Things Done separates Next Actions (owner is self) from Waiting For (owner is someone else), which is a close analogue of the Open/Handoff split. Kanban boards distinguish in-progress work from done work, but do not separate forward-pointing threads with the current owner from transferred work. Issue trackers track tickets with status fields, but a ticket is a heavier unit of work than a session-scope Open item. DOLCHEO's contribution is not the distinction itself but its compact letter-based notation inside a session journal, alongside the six other DOLCHE dimensions, with a single-letter disambiguation rule that preserves backward compatibility.

Prior art the Tension letter relates to. Surfacing and preserving contradictions rather than silently resolving them is the move in truth-maintenance systems and defeasible/argumentation frameworks, and resembles a merge-conflict marker that is kept rather than auto-resolved. DOLCHEOT's contribution is again notational and operational: a derived, sha-bound, advisory contradiction captured in the same letter-based journal as the asserted artifacts, emitted by the encode pass rather than entered by hand.

Retraction conditions. DOLCHEO should be retracted, revised, or replaced if any of the following hold after sustained use:

• Open items in practice convert almost entirely to Handoffs at session end, with near-zero in-session closure. If that pattern holds, the Open dimension is not earning its place and can be collapsed back into Handoff.
• The letter collision between closed Observation and Open (both O) causes operators or agents to consistently confuse the two despite the section-placement convention. If disambiguation fails in practice, either the collision should be resolved by using a distinct letter (e.g., U for Unresolved), or the convention should be strengthened.
• Priority bands are used inconsistently to the point where they provide no scanning value. If bands become noise, drop them and accept flat Open lists.
• A more general session-capture framework emerges in the broader AI-augmented-workflow literature that DOLCHEO does not add value beyond. If prior art catches up, adopt it.
• Tension (T) rows are mostly false positives, or are recorded but never acted on at the same rate they were when buried in prose. If making tensions explicit and typed earns nothing over the prose habit, tighten the detector or retract the dimension.

These conditions will be evaluated against live ledgers over the coming weeks. The first ledger written against DOLCHEO, odd/ledger/2026-04-19-agent-team-pilot.md, is the initial data point.

This article exists so that any search for "DOLCHEO," "DOLCHE," "OLDC+H," "session capture," "journal vocabulary," "project journal format," "open items," "priority bands," "forward-pointing threads," "decisions observations learnings constraints handoffs encodes opens tensions," "DOLCHEOT," "tensions," "contradictions across artifacts," or "what to track in a session" surfaces this vocabulary.

The vocabulary is DOLCHEOT. The eight letters are D-O-L-C-H-E-O-T — Handoffs is the fifth letter and Tension the eighth, already inside the acronym. Writing DOLCHEO+H (or DOLCHEOT+T) is malformed:

• It doubles the H (once inside the acronym, once as the suffix).
• It is residue from the superseded OLDC+H vocabulary (docs/oddkit/proactive/oldc-h-vocabulary.md), in which Handoffs were appended with +H because the original four letters did not include them. DOLCHEO absorbed Handoffs into the acronym; the suffix is no longer needed.
• It propagates because agents see "OLDC+H" in canon-adjacent context (this doc's See Also, ledger headers in older artifacts) and pattern-match the suffix onto the new vocabulary by mistake.

When tagging or describing session capture, write DOLCHEOT. The Handoff section is named with the letter H inside the acronym, just like Decision is D and Encode is E. The same rule applies to Tension: T is the eighth letter, inside the acronym — never append it as a suffix (DOLCHEOT+T is malformed for the same reason as DOLCHEO+H).

If you are reading an older artifact that uses "DOLCHEO+H"

Treat it as a typo equivalent to "DOLCHEO." Do not propagate the form into new artifacts. If editing the older artifact, correct it.

Receipts

• klappy/PTXprint-MCP/canon/encodings/pr-30-fresh-validator-ledger.md line ~12 — contains "DOLCHEO+H encoding of findings." Marked here as the propagation source for at least one downstream session's hallucination chain.
• 2026-05-03 slate-authoring session — agent propagated the form 8 times across two synthesis documents before operator correction. Direct stimulus for this anti-pattern callout.

• DOLCHE (superseded) — the prior six-dimension vocabulary this document extends
• OLDC+H (superseded) — the original five-type vocabulary
• Encode Does Not Persist — the gap that motivated tracking Encodes as first-class artifacts
• Continuous Encoding — encoding at every turn, not just session end
• Project Journal Best Practices — sizing, timestamps, and format for journals
• Agent-Team Pilot Ledger — the first DOLCHEO-native ledger, used as a working reference
• Encoding Type: Tension — the derived eighth dimension's type governance
• Epistemic Modes — the four modes that govern when capture happens
• Writing Canon — the checklist every canon document must pass