Specification

The Delegated Judgment Context Schema

Version 1.0 | Published March 2026 | DelegateZero, Inc.

Contents

  1. Abstract
  2. Introduction
    1. Purpose
    2. Scope
    3. Conventions
  3. Context Object Model
    1. Base Fields
    2. Context Types
  4. Context Type Definitions
    1. Policy
    2. Precedent
    3. Memory
    4. Entity
    5. Playbook
    6. Template
    7. Source
  5. Weighting and Priority Hierarchy
  6. Freshness and Staleness
  7. Escalation Triggers
  8. Decision Resolution
  9. Conformance
  10. Changelog

Abstract

This document defines the Delegated Judgment Context Schema (DJCS) - a formal specification for how structured context is stored, typed, weighted, and evaluated in systems that act as proxies for human judgment. It defines seven context types, their semantic contracts, their priority ordering, the rules governing staleness, and the conditions under which a system must escalate rather than act. This specification is intended to be implementable by any system that delegates decision authority on behalf of a human principal.

1. Introduction

1.1 Purpose

Delegated judgment systems - software that acts on behalf of a human principal within defined constraints - require a structured way to represent the knowledge, rules, preferences, and history that constitute that principal's judgment. Without a common schema, each implementation invents its own vocabulary, with incompatible semantics and no shared basis for reasoning about correctness.

This specification establishes that vocabulary. It defines what each context type is, what it is not, how it interacts with other types, and how it should influence a system's decision output. The goal is not to constrain implementations but to establish a shared semantic layer that enables interoperability, auditability, and trust.

1.2 Scope

This specification covers:

  • The data model for context objects in a delegated judgment system
  • The semantic definitions of seven context types: Policy, Precedent, Memory, Entity, Playbook, Template, and Source
  • The priority ordering and weighting rules that govern how context types interact
  • Freshness thresholds and staleness handling per context type
  • Conditions that trigger mandatory escalation regardless of confidence
  • The resolution algorithm by which a system produces an outcome from a set of context inputs

This specification does not cover the internal reasoning mechanism of any particular AI system, specific API formats, user interface requirements, or data storage formats.

1.3 Conventions

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as follows:

  • MUST - an absolute requirement. Deviation constitutes non-conformance.
  • MUST NOT - an absolute prohibition.
  • SHOULD - strongly recommended. Deviation is permitted with documented justification.
  • MAY - optional. Implementations are free to include or omit.

The term principal refers to the human whose judgment is being delegated. The term system refers to the software acting on the principal's behalf. The term request refers to the input for which the system must produce a judgment outcome.

2. Context Object Model

2.1 Base Fields

Every context object, regardless of type, MUST contain the following fields:

Field Type Description
id string Unique identifier for this context object within the principal's store.
type enum One of: policy, precedent, memory, entity, playbook, template, source.
content string The full text of the context entry. Free-form prose or structured text.
created_at timestamp When this entry was first created.
last_updated timestamp When this entry was last modified. Used for freshness evaluation.

Implementations MAY add additional fields. Fields not defined in this specification MUST NOT override the behavior defined here.

2.2 Context Types

The type field determines how a context object is interpreted and weighted. The seven defined types form a complete vocabulary for representing a principal's judgment. Each type has a distinct semantic contract defined in Section 3.

A conforming implementation MUST support all seven types. A system MAY support additional proprietary types but MUST NOT assign them the semantics of any defined type.

3. Context Type Definitions

3.1 Policy

Definition: A Policy is an explicit rule, limit, or boundary that the system MUST respect when acting on the principal's behalf.

What it is: A Policy encodes non-negotiable constraints - things the system must always do, must never do, or must escalate rather than act upon. Policies represent the principal's hard lines.

What it is not: A Policy is not a preference, a guideline, or a suggestion. It is not a description of typical behavior. It is not a description of an entity, relationship, or past outcome. If a constraint can be overridden by sufficiently strong countervailing signals, it is not a Policy.

Authorship: Policies MUST be authored by the principal. A system MUST NOT auto-generate or modify Policy entries.

Interaction with other types: When a Policy applies to a request, it MUST override all other context signals except explicit principal override at execution time. A system MUST NOT produce an execute outcome if doing so would violate an applicable Policy.

Examples:

  • Never approve expenses over $500 without a secondary review.
  • Do not commit to timelines on behalf of the engineering team.
  • If confidence is below 0.75, escalate rather than act.

3.2 Precedent

Definition: A Precedent is a documented example of a past decision, outcome, or handling pattern that informs how similar future situations should be approached.

What it is: A Precedent encodes "here is how I handled this before." It is user-curated signal about the principal's revealed preferences. When a new request closely resembles a past situation covered by a Precedent, that Precedent should significantly weight the outcome toward the prior handling.

What it is not: A Precedent is not a hard rule. It does not override Policies. It is not a description of future intent - it is a record of past behavior. It is not a Memory entry, which is machine-generated; Precedents are explicitly authored by the principal.

Authorship: Precedents MUST be authored by the principal. A system MUST NOT auto-generate or modify Precedent entries.

Interaction with other types: Precedents are the second-highest priority signal after Policies. When multiple Precedents apply and they conflict, the most recent SHOULD take precedence unless recency alone is insufficient to resolve the conflict.

Examples:

  • Approved a partial refund after 45 days because of an outage we caused.
  • Declined this vendor's rate increase and renegotiated to a flat renewal.
  • When a candidate is borderline qualified but clearly excellent in interviews, I proceed.

3.3 Memory

Definition: Memory is a machine-generated, append-only record of decisions made by the system on behalf of the principal, including outcomes, corrections applied, and behavioral patterns observed over time.

What it is: Memory is the system's behavioral history - the accumulated record of what was decided, with what confidence, and whether the principal agreed. It answers the question: "given everything that has happened, what has this system learned about how the principal operates?" Memory is written automatically on every decision. It is never authored by the principal directly.

What it is not: Memory is not a Precedent (which is intentionally authored). It is not a Policy (which is an explicit rule). It is not an Entity profile (which describes a relationship, not a decision log). Memory entries are not individual facts to be retrieved - they are a behavioral signal that accumulates statistical weight over time. A single Memory entry is weak signal; many consistent Memory entries on the same domain are strong.

Authorship: Memory MUST be written only by the system, automatically, after each decision. The principal MAY annotate or delete Memory entries. The principal MUST NOT be able to add Memory entries manually. A system MUST write a Memory entry after every decision without exception.

Staleness: Memory entries do not expire. They are weighted by recency naturally - older entries represent older behavior and carry correspondingly less weight when evaluating current situations. Implementations SHOULD apply a recency decay function when aggregating Memory signal.

Interaction with other types: Memory operates as soft signal. It informs the direction and confidence of a decision but cannot override Policies or Precedents. Sufficient consistent Memory signal across many past decisions may raise the confidence of a current decision that lacks Policy or Precedent coverage.

3.4 Entity

Definition: An Entity is a context object representing a specific person, organization, system, or account that has ongoing relevance to the principal's decisions, including associated preferences, constraints, relationship history, and handling rules.

What it is: An Entity entry is a living narrative about a specific subject. Unlike Policies (which are rules) or Precedents (which are examples), an Entity entry describes who someone is and how the relationship with them should shape decision-making. Entity entries are updated automatically when decisions involving that entity reveal new signal - a changed preference, a new contact, a shift in relationship dynamic.

What it is not: An Entity is not a static profile or a CRM record. It is not a Policy. It is not a precedent about a person - it is the accumulated understanding of that person or organization as a decision context. An Entity entry should not contain rules that belong in a Policy.

Authorship: Entity entries MAY be created by the principal or auto-created by the system when an unknown entity is encountered. Entity entries MUST be automatically updated by the system when a decision involving that entity reveals net-new signal. The system MUST archive the previous version of any Entity entry it rewrites, with a reference to the triggering decision.

Versioning: Every rewrite of an Entity entry MUST preserve the previous version with a timestamp and the ID of the decision that triggered the update. This creates a versioned relationship arc. Implementations MUST expose the version history for any Entity entry.

Staleness: Entity entries do not have a fixed staleness threshold. Because they are automatically updated on new signal, they are presumed current. A system MAY flag an Entity entry as potentially stale if it has not been referenced in a decision in more than 180 days.

Interaction with other types: Entity context is applied when the request involves a named or identifiable entity. Entity-level handling rules MUST be respected unless overridden by a Policy. Entity entries have higher priority than Playbooks, Templates, and Sources, but lower priority than Policies and Precedents.

3.5 Playbook

Definition: A Playbook is a documented description of how the principal approaches a category of complex or ambiguous situation - the reasoning process, not the rule.

What it is: A Playbook captures the principal's thinking methodology for a type of situation. Where a Policy says "never do X" and a Precedent says "here is what I did before," a Playbook says "here is how I think through situations like this." Playbooks are most valuable in ambiguous cases where rule lookup is insufficient and pattern-matching alone would miss important nuance.

What it is not: A Playbook is not a Policy. It does not define hard constraints. It is not a decision template or a response format - those are Templates. A Playbook is not a step-by-step automation script - it is a description of judgment, not a procedure.

Authorship: Playbooks MUST be authored by the principal. A system MUST NOT auto-generate or modify Playbook entries.

Interaction with other types: Playbooks are consulted when no Policy or Precedent directly covers the request, or when the system needs to reason through an ambiguous situation. Playbooks inform the how of a decision - the reasoning path - rather than the what.

Examples:

  • When someone asks for an exception, I first check whether the contract terms allow it, then whether there is prior precedent, then whether the relationship value justifies bending the rule.
  • How I approach declining requests without damaging the relationship.
  • My framework for evaluating underqualified-but-compelling candidates.

3.6 Template

Definition: A Template is a reusable response structure - a format, opening, closing, or complete draft - that the system MAY use or adapt when formulating a response.

What it is: A Template governs the shape and tone of a response. It answers the question: "given that I know what to decide, how should the output be formatted or worded?" Templates are not reasoning inputs - they are output constraints.

What it is not: A Template is not a Policy and does not override decision logic. It is not a Playbook - it does not describe how to reason, only how to format the result. A Template should not contain decision criteria.

Authorship: Templates MUST be authored by the principal. A system MUST NOT auto-generate or modify Template entries.

Interaction with other types: Templates are the lowest-priority reasoning input. They are applied after the decision outcome is determined. A Template MUST NOT influence whether the outcome is execute, draft, or escalate.

Examples:

  • Standard refusal: "Thanks for the note. I've reviewed this and I'm not going to be able to move forward - happy to discuss if helpful."
  • Standard approval: "Looks good - go ahead."
  • Escalation handoff: "I'm looping Tyler in on this one. He'll follow up directly."

3.7 Source

Definition: A Source is a raw reference object - text, documents, URLs, files, or data - that provides factual grounding for decisions but does not constitute a rule, preference, or pattern.

What it is: A Source is background material. It informs reasoning by providing facts, reference content, or live data that the system can consult when evaluating a request. Sources are not instructions - they are inputs. A Source might be a contract, a pricing sheet, a documentation page, a communication thread, or an integration payload.

What it is not: A Source is not a Policy, Precedent, or Playbook. It does not prescribe behavior. It is not an Entity profile. A Source is the raw material that other context types are derived from - it represents "here is the information," not "here is what to do with it."

Authorship: Sources MAY be authored by the principal, auto-ingested from connected integrations, or auto-created by the system during enrichment. System-generated Sources MUST be labeled as such.

Freshness: Sources have a staleness threshold of 180 days. Source content that references time-sensitive information (pricing, availability, personnel) is particularly susceptible to stale signal and SHOULD be flagged more aggressively.

Interaction with other types: Sources are the lowest-priority context type in the reasoning hierarchy. They provide factual grounding but cannot override behavioral context. A Source that contradicts a Policy does not supersede it - the Policy MUST hold.

4. Weighting and Priority Hierarchy

When multiple context objects apply to a request, the system MUST evaluate them in the following priority order. Higher-priority types override lower-priority types when they conflict:

Priority Type Role
1 (highest) Policy Hard constraints. Override all other signals.
2 Precedent Prior decisions. High-confidence behavioral signal.
3 Memory Accumulated behavioral pattern. Soft, recency-weighted signal.
4 Entity Relationship context for named subjects. Overrides generic signals.
5 Playbook Reasoning guidance for ambiguous situations.
6 Template Output format and tone. Does not affect outcome determination.
7 (lowest) Source Factual grounding. Informs but does not direct.

Conflict resolution rules:

  • A conflict between a Policy and any other type MUST be resolved in favor of the Policy.
  • A conflict between a Precedent and a Memory entry MUST be resolved in favor of the Precedent, unless the Memory entries collectively represent a substantial and consistent behavioral shift since the Precedent was authored.
  • A conflict between an Entity-level rule and a Playbook MUST be resolved in favor of the Entity rule.
  • When context types of equal applicable relevance conflict without a Policy override, the system SHOULD escalate rather than arbitrate.

The hierarchy governs conflict resolution, not retrieval. A system SHOULD retrieve context from all applicable types before evaluating. Retrieval MUST NOT be filtered by priority - filtering applies only at evaluation time.

5. Freshness and Staleness

Context entries represent beliefs about the world at the time they were written. The world changes. Staleness rules codify how systems should treat the age of a context entry relative to its type.

Type Staleness threshold Behavior on threshold breach
Policy 365 days Flag as potentially stale. Reduce confidence when Policy is primary input.
Precedent 180 days Flag as potentially stale. Reduce confidence. Prefer more recent Memory signal if available.
Memory None - recency-weighted Older Memory entries carry less weight by recency decay. No hard threshold.
Entity None - auto-updated Flag if not referenced in a decision in over 180 days. Treat as stale if manually edited over 365 days ago.
Playbook 365 days Flag as potentially stale. Reasoning guidance may be outdated.
Template 365 days Flag as potentially stale. Tone or format guidance may not reflect current voice.
Source 180 days Flag as potentially stale. Factual content - especially pricing, personnel, availability - may be outdated.

Staleness MUST be surfaced in the decision audit record whenever a stale entry was a primary input to the outcome. It MUST NOT be silently suppressed.

Stale entries MUST NOT be automatically deleted or hidden. A stale entry may still be the best available signal. The flag informs the system and the principal to treat specific claims with appropriate skepticism.

A context entry's staleness clock MUST reset when the entry is edited and saved by the principal or (for Entity entries only) when the system performs an automatic update.

6. Escalation Triggers

An escalation trigger is a condition under which the system MUST produce an escalate outcome regardless of confidence score or context coverage. Escalation triggers represent the outer boundary of delegated authority.

The following are mandatory escalation conditions. A conforming system MUST escalate when any of these conditions is present:

6.1 Policy-mandated escalation

Any applicable Policy entry that explicitly requires escalation for the given request type, entity, or condition. Policy-mandated escalation MUST NOT be overridden by confidence score.

6.2 Confidence floor breach

The system's computed confidence score falls below the principal's configured minimum threshold. The default threshold is 0.70. The principal MAY configure a higher or lower threshold. A system MUST NOT execute below the principal's configured floor regardless of context coverage.

6.3 Conflicting primary signals

Two or more Policy or Precedent entries of equal weight directly contradict each other with respect to the request, and no higher-priority signal resolves the conflict. The system MUST escalate rather than arbitrate between conflicting primary signals.

6.4 Missing required context

The request explicitly involves a named entity, compliance domain, or condition class that the system has no context for, and the risk level of the request is above a low threshold. The system SHOULD escalate when operating without context in a domain where errors carry material consequences.

6.5 Stale primary input

The only applicable Policy or Precedent entries are flagged as stale, and no current Memory signal adequately covers the domain. The system MAY escalate in this condition and SHOULD reduce confidence to reflect it.

6.6 Novel pattern

The request does not substantially match any prior request pattern in Memory, no Precedents apply, and no Policies govern it. Novel requests in sensitive domains (financial commitments, external communications, personnel decisions) SHOULD trigger escalation unless the principal has configured explicit authority grants for those domains.

Escalation MUST include a reason code identifying which trigger condition was met. This reason code MUST be included in the audit record and SHOULD be included in any notification to the principal.

7. Decision Resolution

A conforming system resolves a request to exactly one of three outcomes:

  • execute - The system takes the action or sends the response on the principal's behalf.
  • draft - The system produces a proposed action or response for principal review before sending.
  • escalate - The system routes the request to the principal without acting.

Resolution algorithm:

  1. Retrieve all context objects whose content is relevant to the request.
  2. Evaluate escalation triggers (Section 6). If any trigger fires, produce escalate. Stop.
  3. Apply context in priority order (Section 4). Identify conflicts and resolve per conflict resolution rules.
  4. Evaluate freshness of all primary inputs (Section 5). Adjust confidence accordingly.
  5. Compute a confidence score in the range [0.0, 1.0].
  6. If confidence is below the principal's configured floor, produce escalate. Stop.
  7. If all applicable Policies permit action and confidence is above threshold, determine outcome direction from context:
    • If Policies or Precedents indicate the request should be held for review, produce draft.
    • Otherwise, produce execute.
  8. Apply Template context to format the response payload.
  9. Write a Memory entry recording the request, outcome, confidence, context inputs used, and whether any stale entries were present.
  10. Return the outcome, confidence score, response payload, and audit record.

The Memory write in step 9 is unconditional. It MUST occur for every decision, regardless of outcome, and MUST NOT be skipped even on error recovery paths. It is the primary input to the system's long-term calibration loop.

8. Conformance

A system is conformant with this specification if it satisfies all MUST requirements in Sections 2 through 7.

Partial conformance is permitted and SHOULD be documented. A system that implements a subset of context types MUST clearly declare which types are supported and which are not. An unsupported context type MUST be treated as absent - its absence MUST NOT cause the system to misclassify requests or produce incorrect priority ordering among supported types.

Conformance does not require any specific implementation technology, storage format, or API design. The specification governs semantics and behavior, not architecture.

Implementations that conform to this specification are encouraged to reference it by name and version when describing their context model.

Changelog

Version Date Notes
1.0 March 2026 Initial publication. Defines seven context types, priority hierarchy, freshness rules, escalation triggers, and resolution algorithm.