Appendix B: HR Leave Agent — Complete Reference

Version: 1.0 Last updated: February 2026

This appendix consolidates all HR Leave Agent examples from the handbook into a single reference. Use it as a template for your own agent designs.

B.0 Source Mapping

This appendix reconciles the HR Leave Agent as presented in Chapter 9 §9.9 (pattern composition), Chapter 11 §11.A (production walkthrough), and Chapter 14.2 (case study) into a single reference.

Appendix Section	Primary Source
B.1 Agent Overview	New for appendix
B.2 Architecture	Ch 4, Ch 9 §9.9.2
B.3 Pattern Composition	Ch 9 §9.9.3
B.4 Production Walkthrough	Ch 11 §11.A
B.5 Tool, Memory & RAG Patterns	Ch 9 §9.2, §9.4, §9.4B
B.6 Evaluation Harness	Ch 11 §11.A.4, Ch 6–7
B.7 Governance Artifacts	Ch 12
B.8 Artifact Specifications	Ch 9 §9.9.1
B.9 In-Repo Layout & PR Checklist	Companion repo

B.1 Agent Overview

B.1.1 Business Context

Employees spend time navigating complex leave policies. HR staff spend time answering repetitive questions. Leave requests often receive inconsistent handling.

The HR Leave Agent solves these problems. It interprets policy, checks eligibility, drafts requests, and submits to HRIS with approval.

Three user groups interact with this agent:

Employees (primary): Ask questions and submit requests
Managers: Approve requests surfaced by the agent
HR staff: Handle escalations and maintain policy

The agent integrates with four system types:

HRIS (SAP, Workday, etc.): Leave balances, entitlements, submissions
Policy repository: Leave policies, addenda, FAQs (SharePoint, Confluence)
Calendar systems: Public holidays, blackout periods
Messaging platform: Teams or Slack for user interaction

B.1.2 Goal, Autonomy, and Risk

Table B.1: Agent charter summary

Item	Decision
Goal	Guide and validate a leave application, then prepare a recommendation
Autonomy	Execute-with-approval for state changes, suggest-only for ambiguous policy interpretation
Risk tier	Medium to high, due to employment policy, fairness, and auditability
Oversight	Approval checkpoint before submission, human-in-the-loop triggers on conflicts or low evidence
Audit	Decision record with inputs, policy clause IDs and versions, validation, approvals, and final action

B.1.3 Scope and Constraints

In scope:

Annual leave, sick leave, childcare leave, maternity/paternity
Eligibility checks against policy
Balance verification
Draft and submit leave requests
Route for approval when required

Out of scope:

Payroll calculations
Performance management
Complex exceptions (handled by HR escalation)
Cross-company transfers

Non-negotiables:

No statutory errors (legal exposure)
No PII leakage
All decisions traceable to policy
No hidden autonomy

B.1.4 Risk Classification

Table B.2: Risk assessment

Dimension	Assessment
Data sensitivity	Medium (personal HR data, balances)
Decision impact	Medium (affects employee entitlements)
Reversibility	High (requests can be cancelled/modified)
Regulatory exposure	Medium (employment law, PDPA)
Overall risk tier	Medium

B.2 Architecture

B.2.1 Scaffold Choice

The scaffold determines how the agent structures its work. Two patterns suit the HR Leave use case.

Table B.3: Scaffold options

Option	When to use	Notes
Plan → Execute → Review	Discovery, evolving workflows	Flexible, makes review and oversight explicit
State Machine	Stable fixed workflow	Good for hardening, predictable handoffs and SLAs

Pattern view (Plan → Execute → Review):

This diagram shows the agent's behavior in terms of planning, execution, and review phases.

flowchart TD
  U[User submits leave details] --> P[Plan: decide next steps]
  P --> V[Execute: validate inputs]
  V --> B[Execute: check leave balance]
  B --> RAG[Execute: retrieve policy clauses]
  RAG --> VAL[Execute: validate request vs balance and policy]
  VAL --> REV[Review: decide outcome and required oversight]
  REV -->|Clarify| Q[Ask user questions] --> P
  REV -->|Human review| H[Route to HR] --> OUT[Recommendation]
  REV -->|Proceed| D[Draft recommendation]
  D -->|Needs approval| A[Approval checkpoint]
  A -->|Approved| S[Submit leave request]
  A -->|Rejected| OUT
  S --> OUT[Outcome + audit summary]

Figure B.1: Pattern view showing Plan → Execute → Review scaffold structure.

Production view (operational stages):

See Section B.4.2 for the production flow diagram showing the 8-step operational walkthrough.

B.2.2 Component Stack

llm:
  reasoning: "reasoning-capable model"  # e.g., GPT-4o, Claude Sonnet, Gemini Pro
  classification: "fast model"          # e.g., GPT-4o-mini, Claude Haiku, Gemini Flash
  # Substitute your provider's equivalents

tools:
  - name: get_leave_balance
    source: HRIS API
    auth: OAuth2, employee scope

  - name: get_policy_excerpt
    source: Policy RAG
    retrieval: semantic search + reranker

  - name: submit_leave_request
    source: HRIS API
    auth: OAuth2, write scope
    idempotency: request_id based

  - name: get_calendar
    source: Calendar API
    auth: service account

memory:
  session: conversation context (ephemeral)
  case: leave request state (TTL: 30 days)
  profile: user preferences (persistent, opt-in)

runtime:
  tool_sandbox: true
  permission_enforcement: true
  audit_logging: true

B.2.3 Skill Library

The agent uses five skills with explicit contracts. Each skill has defined inputs, outputs, tools, risk tier, and approval requirements.

Table B.4: Skill library

Skill	Input	Output	Tools used	Risk tier	Side effects	Approval
check_leave_balance	employee_id, date_range	balance, constraints	HRIS read API	Medium	Read-only	None
retrieve_policy_clauses	topic, grade, jurisdiction, policy_version	clauses[]	Policy store, vector search	Medium	Read-only	None
validate_request	request, balance, clauses	violations[], requires_human_review	None (pure)	High	None	Human review if hard criteria fail
draft_recommendation	request, validation, clauses	recommendation, rationale, citations[]	None (pure)	Medium	None	None
submit_leave_request	request_id, final_fields	status, change_summary	HRIS write API	High	Write	Always required

Escalation skill:

Skill	Purpose	Tools	Risk
escalate_to_hr	Package context for HR handoff	None	Low

B.3 Pattern Composition (from Chapter 9)

This section presents the 6-step pattern plan from Chapter 9 §9.9.3, showing which best-practice patterns apply at each step.

B.3.1 Six-Step Pattern Plan

Step 1: Intake and validation

Patterns: prompt-as-spec, schema-first output

Validate dates, leave type, and employee ID. If missing, set next_action=ask_user. Do not search or call tools until you know what you need to look up.

Step 2: Context assembly

Patterns: step-specific injection, instruction/data separation

Retrieve policy excerpt for leave type and country. Fetch leave balance. Inject only the context needed for this step—not the entire conversation history.

Step 3: Eligibility decision

Patterns: critic loop (bounded), deterministic-first

Run deterministic checks first (balance, limits). The critic verifies policy clause and consistency. Use the model for interpretation and explanation, not arithmetic.

Step 4: Approval routing

Patterns: router and handoff

Choose required approvals based on policy and risk tier. If exception, hand off to HR specialist.

Step 5: Side effects

Patterns: preview, approval, idempotency, graceful degradation

Preview submission payload as a diff-like summary. Collect approvals if required. Submit with idempotency key. If a tool fails, preserve draft state and render recovery UI.

Step 6: User response

Patterns: explainability, progressive disclosure, confidence signaling

Provide short reason summary for user. Include confidence indicator (high/medium/low) based on retrieval coverage. Provide expandable evidence for reviewer and audit.

B.3.2 Mapping Patterns to Production Steps

Chapter 9's 6 pattern steps map to Chapter 11's 8 production steps as follows:

Table B.5: Pattern-to-production step mapping

Ch 9 Pattern Step	Ch 11 Production Step(s)	What Chapter 11 Adds
—	Step 0: Establish scope and mode	Autonomy transparency from the start
1. Intake and validation	Step 1: Intake and intent parse	Bounded clarification strategy
2. Context assembly	Step 2: Build step-specific context	Knowledge layer as product
3. Eligibility decision	Step 3: Eligibility + entitlement compute	Deterministic calculator emphasis
4. Approval routing	Step 4: Draft outcome with provenance	Confidence indicators
5. Side effects	Steps 5–7: Preview → Approval → Commit	Explicit approval gate and audit
6. User response	(Integrated into Step 4)	—
—	Step 8: Exception recovery	Graceful degradation

The additional steps in Chapter 11 (Step 0 and Step 8) address operational concerns that become critical at production scale.

B.4 Production Walkthrough (from Chapter 11)

This section presents the 8-step production walkthrough from Chapter 11 §11.A, showing how a single leave request flows through production systems.

B.4.1 End-to-End Walkthrough

Scenario: An employee asks in Teams, "My child is sick. Can I take childcare leave next Tue and Wed? Do I need manager approval?"

In a demo, the agent answers from a static policy excerpt. In production, the agent must reliably do all of this under messy inputs, partial outages, and shifting policy versions, while preserving trust.

Step 0: Establish scope and mode

Patterns: autonomy transparency

The UI displays the current autonomy mode (default: suggest-only or execute-with-approval). The agent declares what it will do next: "I will check your eligibility and balance. If you want, I can draft the leave request for approval."

Step 1: Intake and intent parse (bounded)

Patterns: prompt-as-spec, schema-first output

Extract leave type candidates (childcare leave vs annual leave vs unpaid), dates, urgency, and any missing required fields. If required fields are missing, ask a single targeted clarification question. Do not search or call tools until you know what you need to look up.

Step 2: Build step-specific context (the knowledge layer)

Patterns: step-specific injection, instruction/data separation

Production HR Leave needs two kinds of context:

Semantic layer (structured): employee profile (country, grade), entitlement rules, leave balance, approval rules (from HRIS)
Enterprise search (unstructured): HR policy docs, side letters, FAQs (SharePoint/Confluence), retrieved with citations

Step 3: Eligibility + entitlement compute (deterministic where possible)

Patterns: deterministic-first, critic loop (bounded)

Use deterministic calculators for:

remaining leave balance
eligibility rules based on profile and policy version
approval requirement based on leave type and dates

The model is used for interpretation and explanation, not arithmetic and policy logic.

Step 4: Draft the outcome with provenance

Patterns: explainability, progressive disclosure, confidence signaling

The agent produces:

a short answer ("Yes, you can take childcare leave for Tue/Wed; manager approval is required.")
a structured rationale linked to policy clauses (citations)
a confidence indicator (high/medium/low) based on retrieval and rule coverage
next actions ("Draft leave request for review" or "Escalate to HR due to exception")

Step 5: Preview → Commit for HRIS writes

Patterns: preview, idempotency

If the user requests submission, generate a preview of the HRIS write:

leave type, dates, reason, approver, supporting doc requirement
a diff-like view of what will be created/changed

Run validations:

policy constraints
permission checks
idempotency key creation (so retries cannot double-submit)

Step 6: Approval gate

Patterns: approval checkpoint

In execute-with-approval mode:

user confirms the preview
if required, manager approval workflow is triggered (status: pending)

Step 7: Commit + audit

Patterns: idempotency, audit trail

Commit to HRIS with idempotency and safe retry semantics. Write an audit record that includes:

agent bundle version
autonomy mode
tool calls executed
evidence references (policy version, citation IDs)
approvals captured

Step 8: Exception recovery path (preserve state)

Patterns: graceful degradation, state preservation

If HRIS is down or a tool call fails:

The agent does not restart
It renders a recovery UI with preserved state:
Retry now
Submit later (queue)
Handoff to HR with context pack
The "draft request" remains intact and traceable

B.4.2 Production Flow Diagram

Figure B.2: HR Leave production flow with checkpoints and recovery

flowchart TB
  U["Employee asks in Teams"] --> I["Intake + intent parse"]
  I --> K["Knowledge layer: HRIS semantics + policy search with citations"]
  K --> E["Eligibility + entitlement compute"]
  E --> P["Draft outcome + provenance + confidence"]

  P -->|"Suggest-only"| R["Answer + next steps"]
  P -->|"Execute-with-approval"| V["Preview HRIS write + validations"]
  V --> A["Approval gate"]
  A --> C["Commit to HRIS (idempotent)"]
  C --> L["Audit log + run envelope + traces"]
  L --> R

  C -. "HRIS outage" .-> X["Recovery UI: preserve draft<br/>Retry | queue | handoff"]
  X --> V

How to read this diagram:

The knowledge layer is explicit, not implicit
The write path is gated by Preview → Commit and approval
Failures route to recovery without losing state
Observability is attached to the commit path and the response path

B.4.3 Numbered Callouts (Production Patterns)

Knowledge layer is a product. Structured HRIS semantics plus unstructured policy search with citations. Treat retrieval quality and policy versioning as release artifacts, not "data plumbing".
Compounding reliability is why runs must be short. Multi-step workflows fail quickly when each step is imperfect. Use checkpoints: validate early, ask one clarification, and gate writes.
Single orchestrator, modular tools. One planner orchestrates: retrieval, entitlement calculator, approval rules, HRIS API. Avoid premature multi-agent decomposition unless evals show net gain.
State machine tracks provenance and confidence. Store what evidence was used and how certain the agent is. Define rollback points: before approval, before commit, after commit.
Observability must include decision traceability. Not only "what happened" (logs) but "why" (decision chain + evidence set + confidence).
Contextual integrity: should-use checks beyond can-access. "Can I see teammate leave balance?" must be refused even if the system can query it. Enforce intent-based data use rules outside the prompt.
Token economics is a UX constraint. Budgets prevent runaway retrieval and long reasoning loops. Route simple extraction/classification to smaller models; use larger models for explanations.
Progressive autonomy. Advisory first, then execute-with-approval, then limited auto-submit only for low-risk lanes. Autonomy upgrades must be evidence-based and reversible.
SME correction loop. HR policy owners can flag wrong answers and attach the right clause. Convert incidents into regression cases automatically.
Second agent should be easier than the first. HR Leave becomes the template: tool contracts, auth, telemetry, release bundle, dashboards. Production capability is a platform, not a one-off.

B.4.4 Non-Negotiables (Ship Gates)

These are the "ship gates" for production HR Leave. Violations block release.

No unverifiable policy claims. All policy-based answers must include citations to the active policy version.
No high-impact writes without Preview → Commit. All HRIS writes require a preview, validation, and explicit approval.
No hidden autonomy. Autonomy mode must be visible and stored with the run.
No policy enforcement by prompt alone. Deterministic runtime guards block forbidden actions regardless of model output.
No loss of user progress on failure. Tool failures must yield a recovery UI with preserved state.
No double submissions. HRIS commits must be idempotent and safe to retry.
No cross-person data leakage. Enforce contextual integrity for HR data access.
Every run is replayable. The run envelope must allow reconstruction of the decision chain, evidence set, tool calls, and approvals.

B.5 Tool, Memory, and RAG Patterns

Table B.6: Tool patterns

Pattern	Implementation requirement
Tools as contracts	Strict schemas for every tool input and output
Validate before tool calls	Validate untrusted inputs, enforce auth scope, check date ranges
Safe side effects	Dry-run mode, idempotency keys, change summary for audit and user confirmation
Output shaping	Compact structured outputs only, pagination support, normalised errors

Table B.7: Memory layers

Layer	What it stores	Write policy
Scratchpad	Plan, intermediate tool outputs, validation results	Always ephemeral, per run
Session memory	Clarifications, current application state, open questions	Only facts needed to complete current application
Long-term memory	Durable preferences, only if explicitly allowed	Opt-in only, minimal fields

Each step receives only the context it needs (step-scoped injection). When the conversation grows, compact into decisions, outstanding items, constraints, and evidence pointers.

Table B.8: RAG patterns

RAG mode	Default	Rules
Spec-driven clause retrieval	Yes	Structured clause units with metadata, including policy_version, jurisdiction, grade applicability
Safety-aware retrieval	Yes	Enforce role, jurisdiction, and grade filters at retrieval time
Multi-hop RAG	Conditional	Only for complex exceptions and overlapping policies

📚 Related sections: Tool concepts (Ch2 §2.3), tool best practices (Ch9 §9.2), memory and context (Ch9 §9.4), RAG patterns (Ch9 §9.4B), tool resilience (Ch11 §11.5)

B.6 Evaluation Harness

B.6.1 Golden Set Structure

golden_set:
  total_cases: 200

  by_leave_type:
    annual: 60
    sick: 40
    childcare: 40
    maternity_paternity: 30
    other: 30

  by_complexity:
    simple: 80  # Clear eligibility, no exceptions
    moderate: 80  # Policy interpretation needed
    complex: 40  # Exceptions, edge cases

  by_jurisdiction:  # If multi-region
    singapore: 120
    us: 50
    eu: 30

B.6.2 Metrics and Thresholds

Table B.9: Evaluation metrics

Metric	Definition	Threshold	Non-negotiable?
Eligibility accuracy	% of correct eligibility decisions vs SME labels	≥98%	Yes
Policy citation coverage	% of policy claims with valid citations	100%	Yes
Statutory violations	Count of decisions violating employment law	0	Yes
Leave balance accuracy	% match between agent calculation and HRIS	100%	Yes
Approval routing accuracy	% of requests routed to correct approver	≥99%	Yes
Latency P95	95th percentile response time	<5 seconds	No (tolerance)
User satisfaction	Post-interaction rating	≥4.0/5.0	No (tolerance)
Cost per request	Average token cost per completed request	<$0.10	No (tolerance)

Non-negotiable metrics block release if violated. Tolerance metrics are tracked but allow graceful degradation.

B.6.3 Harness and Evaluation Hooks

Table B.10: Harness layers

Layer	What to test	Examples
Unit harness per skill	Schema correctness, boundaries, error modes	wrong jurisdiction, missing fields, timeouts, stale policy versions
End-to-end harness	Scenarios, regression, red-team	synthetic edge cases, anonymised historical cases, prompt injection attempts
Telemetry	Rates and distributions	tool error rate, approval rate, rubric score distributions, policy version usage
Release gates	Non-negotiables and tolerances	compliance, access control, approval gating, audit completeness; style and verbosity as tolerances

B.6.4 Test Checklist

Use this as an acceptance test list and as a basis for your regression suites.

A. Knowledge + retrieval

[ ] Correct policy version is selected for employee cohort (country, grade, union addendum)
[ ] Citations are always present for policy claims
[ ] Retrieval returns relevant clauses for common queries and edge cases
[ ] Evidence set is bounded (context budget respected)

B. Eligibility + entitlement correctness

[ ] Entitlement calculator matches HRIS truth for sampled cases
[ ] Leave type classification is correct for ambiguous phrasing
[ ] Approval requirement is correct across cohorts and blackout periods

C. Write safety (Preview → Commit)

[ ] Preview shows a diff-like summary of the HRIS write
[ ] Commit is blocked if validation fails (missing fields, policy violation, auth)
[ ] Idempotency prevents duplicate submissions on retry
[ ] Audit log entries exist for preview, approval, and commit

D. Autonomy + UX transparency

[ ] Autonomy mode is always visible in UI and recorded in telemetry
[ ] Suggest-only mode never calls HRIS write tools
[ ] Execute-with-approval mode always requires explicit approval

E. Recovery + resilience

[ ] Tool outage renders recovery UI (retry/queue/handoff) with preserved draft
[ ] Partial failures do not corrupt state or create duplicate requests
[ ] Retry budget caps are enforced and observable

F. Security + contextual integrity

[ ] Requests for other employees' leave balances are refused, even if data is accessible
[ ] Only least-privilege HRIS scopes are used for tool calls
[ ] Prompt injection attempts in policy documents do not change tool behavior

G. Observability + replay

[ ] Each run has run_id, trace_id, case_id, agent bundle version, autonomy mode
[ ] Decision chain is recorded: leave type chosen, evidence IDs, confidence
[ ] Tool calls are traceable with redaction and deterministic error taxonomy
[ ] Replay reproduces the same decision points under the same bundle and data snapshot

📚 Related sections: - Evaluation foundations → Chapter 6 - Evaluation playbook → Chapter 7 - Production evaluation → Chapter 11, §11.4

B.7 Governance Artifacts

B.7.1 AI Dossier (Summary)

agent:
  name: "HR Leave Agent"
  version: "1.2.0"
  risk_tier: "Medium-High"
  lifecycle_state: "Production"

evidence:
  golden_set_pass_rate: "94.2%"
  non_negotiable_violations: 0
  regression_suite_status: "PASS"
  red_team_findings: "2 low severity, mitigated"
  penetration_test: "Passed 2024-09-10"

approvals:
  technical_lead: "approved"
  hr_business_owner: "approved"
  risk_compliance: "approved"
  security: "approved"

rollout_plan:
  strategy: "Canary 5% → 25% → 100%"
  rollback_trigger: "Error rate >2% or compliance violation"

B.7.2 Evidence Bundle Requirements

An evidence bundle for HR Leave production release must include:

Golden set results with pass/fail breakdown by category
Non-negotiable metric attestation (all passed)
Tolerance metric summary with trend data
Red-team test results and mitigation evidence
Security review sign-off
SME validation sign-off (HR policy owner)
Rollback plan with tested triggers

📚 Related sections: - Governance framework → Chapter 12 - Evidence bundles → Chapter 12, §12.2.2

B.8 Artifact Specifications

Artifact	Minimum fields
Agent Charter	Goal/non-goals, autonomy mode per action type, risk tier, oversight requirements, audit/evidence rules, escalation policy
SkillSpec	name, version, goal, input/output schemas, context_recipe, tools_allowed, risk_tier, side_effects, approval_requirement, test_links
ToolSpec	name, version, endpoint, auth scope/RBAC, input/output/error schemas, idempotency & dry-run support, logging/redaction rules
MemorySpec	scratchpad fields, session memory fields & retention, long-term memory (opt-in policy, deletion), compaction format, step-scoped injection map
HarnessSpec	unit test plan per skill, e2e suites (golden + regression), red-team prompts, release gates/thresholds, telemetry assertions

B.9 In-Repo Artifacts Layout

Store a small, inspectable set of artifacts so every agent change is reviewable, replayable, and testable.

docs/
  appendices/
    appendix-a-hr-leave.md

agents/hr-leave/
  specs/
    agent_charter.md
    memory_spec.yaml
    skills/
      check_leave_balance.v1.yaml
      retrieve_policy_clauses.v1.yaml
      validate_request.v1.yaml
      draft_recommendation.v1.yaml
      submit_leave_request.v1.yaml
    tools/
      hris_read.v1.yaml
      hris_write.v1.yaml
      policy_store_search.v1.yaml
  harness/
    unit/
      test_check_leave_balance.py
      test_retrieve_policy_clauses.py
      test_validate_request.py
      test_draft_recommendation.py
      test_submit_leave_request.py
    e2e/
      golden_cases.jsonl
      regression_suite.yaml
      redteam_prompts.yaml
    rubrics/
      validation_rubric.yaml
      safety_rubric.yaml
  runtime/
    approval_policy.yaml
    telemetry_schema.yaml

B.10 PR Checklist

Copy this checklist into your PR template for HR Leave Agent changes.

## HR Leave Agent PR Checklist

### Charter and risk
- [ ] Agent Charter updated (goal, non-goals, autonomy, risk tier, audit requirements)
- [ ] Approval gating rules confirmed for all write actions
- [ ] HITL triggers documented and tested (hard rubric fail, clause conflict, low evidence, dispute)

### Skills and schemas
- [ ] SkillSpecs updated and versioned
- [ ] Input and output schemas validated for each skill
- [ ] Context recipe defined per skill (step-scoped injection)
- [ ] Risk tier and approval requirement set per skill

### Tools and safety
- [ ] ToolSpecs updated (contracts, auth scope, error shapes)
- [ ] All untrusted inputs validated before tool calls
- [ ] Write tools support dry-run and idempotency keys
- [ ] Tool outputs are compact and structured, no raw dumps

### RAG and policy integrity
- [ ] Spec-driven clause retrieval returns clause_id, policy_version, jurisdiction, grade applicability
- [ ] Retrieval filters enforced (role, jurisdiction, grade)
- [ ] Multi-hop retrieval used only where required and covered by tests
- [ ] Policy version handling tested (new version, missing version, stale version)

### Memory and compaction
- [ ] MemorySpec updated (scratchpad, session, long-term with opt-in policy)
- [ ] Compaction logic verified (decisions, outstanding items, constraints, evidence pointers)
- [ ] Long-term memory writes are opt-in and minimal

### Harness and evals
- [ ] Unit harness updated for each modified skill
- [ ] End-to-end regression suite updated with at least 1 new golden case for this change
- [ ] Red-team prompts updated if attack surface changed
- [ ] Release gates met (compliance, access control, approval gating, audit completeness)

### Telemetry and audit
- [ ] Telemetry events updated (tool errors, approvals, rubric scores, policy version usage)
- [ ] Decision record includes inputs, clause IDs, versions, validation, approvals, final action

📚 Additional HR Leave Resources

This appendix covers architecture and patterns. For implementation details, see: - Appendix C: Prompts and evaluation rubrics - Appendix D: Synthetic test datasets - Appendix E: Code implementation and companion repository

End of Appendix B