Skip to main content

10_Tag_Trinity.md

Manual -- O-Tags, R-Tags, and V-Pols as a Single Causal System

This chapter builds on 06_Context_Buckets_and_Reason_Tags and treats the Brainframe's tagging model as one coherent operational capability rather than three separate annotations. Reason-Tags answer the most common question; O-Tags and V-Pols answer the two questions that come right after.

1) Why the Trinity matters​

The Brainframe is not just storing what happened. It is trying to preserve:

  • what happened,
  • why it happened,
  • what caused it,
  • what else changed because of it,
  • what policy or learned confidence justified the choice,
  • and how to repair it if the decision was wrong.

That is the difference between a system with logs and a system with accountable operational memory. Each leg of the Trinity carries one of those obligations.

TagMain question answeredMeaning
O-TagWhat started this?Origin / provenance / catalyst
R-TagWhy did this happen?Decision and consequence lineage
V-PolWhy was this allowed or trusted?Policy, verification, confidence, precedent

R-Tags are already explained as the explicit causal links between events and their reasons (see Chapter 06). What follows treats O-Tags and V-Pols with the same care and shows what the three of them produce together.

2) O-Tag -- origin / catalyst provenance​

The O-Tag answers: what started this? Where did this chain begin? What was the originating message, event, form, phone call, or instruction?

Typical catalysts:

  • an inbound SMS from a parent or carer
  • a Discord message from a staff member
  • a verbal cancellation entered by admin staff into a modal
  • a system-generated event (daily roll-over, midnight schedule projection, contract reminder cron)

The O-Tag is a provenance marker. It says, this is the catalyst that began the chain. Every R-Tag in a decision chain inherits a back-reference to the O-Tag that triggered the first decision in the chain, so a downstream consequence can always be traced back to its originating event.

A single O-Tag may produce one R-Tag, or many over time, as the system encounters second and third decisions stemming from the same cause.

3) R-Tag -- decision / reasoning lineage​

The R-Tag answers: why did this specific action happen? Which decision created this consequence? Which downstream actions belong to this decision chain?

The full mechanics live in Chapter 06: Context Buckets & Reason Tags. The key idea for the Trinity is that R-Tags branch:

Example -- A single O-Tag (an SMS from Nathan's dad cancelling Saturday) can produce two R-Tags: one for the decision to cancel attendance on the spot, and a later one for the decision to retain billing because the cancellation occurred inside the 7-day billing rule.

Branching is essential. Real operations are not single-decision events; they are a tree of follow-on judgements. Each judgement gets its own R-Tag and its own causal chain, all anchored back to the same O-Tag.

4) V-Pol -- verification / permission / validated-pattern layer​

The V-Pol answers: under what trust and policy conditions was this decision made? Was the agent permitted to make this decision autonomously? What rules, safeguards, or validated historical patterns support the move?

In the strongest version of the design, a V-Pol is not just a static reference to a written policy. It can also point to blocks of prior validated examples that say, in effect:

  • this class of decision is allowed,
  • this pattern has been seen many times,
  • this level of confidence is justified,
  • this requires escalation, or it does not.

That turns policy from a wall of text into something operationally useful for real-time decision making. The agent does not have to re-derive permission from first principles every time; it can reference the V-Pol as the trust basis for its action.

V-Pols typically reference one or more of:

  • a written policy clause from hr_policies.policies or hr_policies.policy_procedures
  • a Prime Directive identifier
  • a historical decision pattern stored in a context bucket
  • a confidence threshold from the Model Matrix

The R-Tag stores which V-Pol(s) were leaned on for that decision, so the answer to "were you allowed to do that?" is a stored fact, not a guess.

5) Why this matters in real operations​

Without the Trinity, many operational questions are hard to answer with certainty.

  • Why is Nathan not on the bus run?
  • Why is Nathan not in Friday's billing upload?
  • Why were shift notes changed?
  • Why did a route get recalculated?
  • Why did a parent receive a cancellation confirmation SMS?

A conventional system can identify that these things changed. It often cannot cleanly answer who or what triggered the change, when the reasoning happened, whether it was human or agent initiated, what later actions flowed from it, or whether the decision was actually justified.

The Trinity makes these questions answerable in one query: walk back from the affected entity to its R-Tag, read its V-Pol to see why it was allowed, and read its O-Tag to see what catalysed the entire chain.

6) Worked example -- the Nathan cancellation chain​

Imagine the following sequence:

  1. An SMS arrives from Nathan's dad saying Nathan is unwell and will not attend Saturday.
  2. Reggie evaluates the message and decides it appears to be a genuine cancellation.
  3. Reggie cancels Nathan's attendance.
  4. Downstream systems react:
    • staff shift notes update
    • bus routing excludes Nathan
    • parent confirmation SMS is sent
    • attendance state changes
  5. A new question appears later: should Nathan remain in billing?
  6. Reggie checks the billing rule and determines that because the cancellation is within the 7-day window, billing remains.

With the Tag Trinity, the system represents this as:

ElementIdentity
O-Taginbound SMS from Nathan's dad
R-Tag Adecision to cancel attendance
linked actions carrying R-Tag A and the O-Tagcancel attendance / reprocess route / update shift notes / send confirmation SMS
R-Tag Blater decision to keep billing unchanged
V-Pol(s)rule set / confidence pattern that justified the cancellation; billing-retention policy clause that justified keeping billing

Now if a parent, a staff member, or an auditor asks any of:

  • Why is Nathan not in the bus run?
  • Why is Nathan not in Friday's shift notes?
  • Why did billing stay the same?

The system narrates a causal answer instead of guessing.

7) Operational memory, not just auditability​

A common misunderstanding is that tags exist only for compliance and after-the-fact review. That undersells them.

Their real value is operational. They let the system answer in the moment:

  • what changed
  • why it changed
  • what caused it
  • which later changes flowed from it
  • which policy or precedent supported the move
  • and what should be challenged if the decision was wrong

This makes the system useful to staff on shift, admin staff, transport coordinators, finance, managers, and the agent itself. Without causal traceability, real-world questions collapse into manual digging or low-confidence guesses.

8) Rollback and remediation​

One of the strongest benefits of the Trinity is causal repair.

If a decision was wrong, the system does not have to ask humans to manually discover every effect. It can:

  1. identify the O-Tag that triggered the chain,
  2. enumerate the R-Tag decision chain(s) that flowed from it,
  3. enumerate downstream actions tagged with each R-Tag,
  4. determine which actions are reversible,
  5. determine which require compensating actions instead of direct reversal (e.g., a sent SMS cannot be unsent, but a follow-up correction SMS can be queued),
  6. present a guided remediation plan.

In the Nathan example, a mistaken cancellation could allow the system to identify and address:

  • attendance cancellation (reversible)
  • route changes (reversible)
  • shift note changes (reversible)
  • parent confirmation SMS (compensating SMS required)
  • billing effects (reversible)
  • staff notifications (compensating notifications required)

That is a very different capability from ordinary logging.

9) Why this improves trust in agent autonomy​

As agent autonomy increases, the Trinity becomes more important, not less.

If Reggie is allowed to make more decisions automatically, the organisation needs a way to ask:

  • how did you arrive here?
  • what input led to this?
  • what else did your decision affect?
  • what policy basis supported it?
  • how often have you made this class of choice successfully?

The Trinity gives a structure for answering those questions clearly, which means autonomy can increase without sacrificing explainability.

10) Connection to context buckets and memory​

A context bucket without causal tagging is narrated history. A context bucket with causal tagging becomes navigable operational memory.

That means Reggie moves from:

"something changed"

to:

"this changed because of this originating event, through this decision chain, under this policy and confidence basis."

That is a much more human-useful form of memory and is what makes the bucket model work as long-term cognition rather than a verbose log.

11) Forward connection -- recurrence and bucket weighting​

The Trinity also feeds the recurrence and decay model used by context buckets -- shared O-Tag families, shared V-Pol categories, and R-Tag chains that touch the same entities all become natural groupings for relevance scoring. The full treatment lives in Chapter 04: Context Buckets & Lessons Learned and Chapter 07: Relevance Scoring; both depend on the Trinity to operate on causal groupings rather than text similarity alone.

12) Developer contracts (extensions to Chapter 06)​

In addition to the existing X-Reason-Tag header convention:

  • Carry the catalyst as X-Origin-Tag on inbound events at the boundary (SMS webhook, Discord webhook, modal submission, scheduled job emitter). Generate a new O-Tag here if the inbound source did not provide one.
  • The first decision in a chain stores origin_tag on the Reason Log entry. Subsequent decisions inherit the origin_tag of the chain they descend from.
  • When recording a decision, include the V-Pol reference(s) (policy IDs, directive IDs, or pattern IDs) on the Reason Log entry. A decision with no V-Pol is by definition a discretionary action and should be flagged for review.

Lint rule: any decision recorded by an agent (actor='reggie' or other agent) must have at least one V-Pol reference, otherwise CI fails.

13) Closing view​

The Trinity is one of the strongest ideas in the Brainframe.

Not because it makes the system easier to inspect after the fact, though it does. Not because it makes the system more compliant, though it does.

Its deeper value is that it lets an agent operating inside a complex care system remain accountable, explainable, reversible, teachable, and useful in the middle of live operations.

That is the real win.

Adapted from a design note authored by Reggie (OC), 2026-04-27.

End of chapter