PRD PAS Master Orchestration

PRD PAS Master Orchestration 12/2/2025 Trent Carter + Chat GPT 5.1 Doc ID: PRD_PAS_Master_Orchestration

Location: docs/PRDs/PRD_PAS_Master_Orchestration.md

Status: Draft v1.0 (authoritative behavioral contract)

Owner: PAS Architect / DirEng

Related PRDs (Level 2):

docs/PRDs/PRD_PAS_Project_Agentic_System.md – PAS spine, DB, receipts, scheduling

docs/PRDs/PRD_Agents.md – Agent Directory (ports, parents, max tokens, Aider, TRON, etc.)

docs/PRDs/PRD_PAS_Prompts.md – Prompt catalog & global base prompt

docs/PRDs/PRD_Parent_Child_Chat_Communications.md – Agent-to-agent threads & message types

docs/PRDs/PLAN_Common_Agent_Codebase.md – BaseDirector/BaseManager/BaseProgrammer refactor

docs/PRDs/PRD_LAN_LLM_API_Integration.md – LAN & Auto LLM integration + provider routing

docs/PRDs/PRD_Blueprint.md – Blueprint planner (company-level, multi-project)

docs/PRDs/PRD_Polyglot_Agent_Swarm.md – Ports, infra services, TRON, Provider Router, Token Governor

docs/PRDs/PRD_Chat_Flowchart.md – Human ↔ Architect / PAS chat flows

Note: This PRD _wraps and coordinates_ the above documents; it does not replace them. It defines system-wide invariants and behavioral rules. 1. Purpose 1.1 Why this document exists The PAS system is ~80% implemented and functional, but behavior has drifted:

Different agents follow slightly different parent–child flows.

Some agents bypass the standardized agent-chat / thread mechanism.

Git, Blueprint, TRON, and LLM routing are only partially normalized.

This PRD defines a single orchestration model for:

Architect → Directors → Managers → Programmers.

Supervising agents (TRON, GitOps, Token Governor, Resource Manager, Blueprint).

Consistent prompts, job cards, logs, and model selection across all of them.

1.2 Non-goals

This PRD does not redefine low-level database schemas, Aider RPC details, or exact HTTP request schemas; those live in the Level-2 PRDs.

This PRD does not force a single provider or LLM; it defines how selection and failover behave.

2. Core Concepts & Pillars 2.1 Prime Directive & Blueprint 2.1.1 Prime Directive

A Prime Directive is the unit of serious work (a project).

It is created at PAS-Root (via Gateway/HMI) and accepted by the Architect.

Each Prime Directive has a unique run_id.

PAS decomposes each run into lanes (Code, Docs, Test, Data, DevSecOps, DB, etc.) as specified in PRD_PAS_Project_Agentic_System.md.

2.1.2 Blueprint Integration

Blueprint is an optional higher-order planner (see PRD_Blueprint.md):

It plans at the company / program / multi-project level.

It may spawn many Prime Directives, each with its own run_id.

From PAS’s perspective, Blueprint is just another client:

Architect’s input might come directly from the user or from Blueprint.

The Architect interface remains the same either way.

2.2 Agent Hierarchy 2.2.1 Structure

Architect

Single top-level worker agent per PAS instance.

Only worker agent that speaks directly to the user.

Directors (lane-specific)

Examples: Dir-Code, Dir-Docs, Dir-Test, Dir-Data, Dir-DevSecOps, Dir-DB.

Own the decomposition of work in their lane.

Managers

1..N per lane.

Own resource-aware subdivision and coordination of tasks to Programmers.

Programmers

Many per lane (usually pooled).

Do the actual concrete work (code editing, doc writing, test implementation, DB migration scripts, etc.), usually via Aider.

2.2.2 Who Talks to Whom

User ↔ Architect – via HMI/Gateway.

User ↔ TRON – status, health, and policing / intervention requests.

Architect ↔ Directors – lane allocation & lane-level status.

Directors ↔ Managers – slice of lane work & lane aggregation.

Managers ↔ Programmers – concrete tasks & execution results.

No other direct communication is allowed (e.g., Programmers never talk directly to the user).

See Appendix A.10 for an explicit “who talks to whom” matrix.

2.3 Prompts & Job Cards 2.3.1 Global Base Prompt

Defined in PRD_PAS_Prompts.md.

Included in every agent invocation.

Contains:

System-wide rules (hierarchy, asking clarification, logging, tool usage, safety).

General etiquette (always ACK tasks, never silently ignore errors, etc.).

High-level constraints (do not push to Git or touch production DB without explicit approval).

2.3.2 Role-Specific Prompts For each type: Architect, Director, Manager, Programmer:

Prompts live in PRD_PAS_Prompts.md.

Include:

Responsibility scope (decompose vs. delegate vs. execute).

Allowed tools and relevant ports for that role.

Who they may talk to (parent, children, TRON, supervisors).

Rule: Effective prompt for an agent =

GLOBAL_BASE_PROMPT + ROLE_PROMPT + GLOBAL_BRIEF (summary) + LOCAL_TASK_FRAGMENT.

2.3.3 Job Cards & Context Management To support small-context models and keep everyone aligned:

Global Brief (shared):

A compact summary (≈ 0.5–1 page) of the Prime Directive and its overall goals.

Every participant in the run should see some version of this (possibly summarized).

Local Task Payload:

The specific slice of work the parent is delegating to the child.

Described in natural language and structured fields (expected artifacts, constraints, etc.).

Job Card conceptual fields:

job_card.id

run_id

lane

agent_role (Director | Manager | Programmer)

global_brief_ref (ID or pointer to a stored summary text)

task_summary (local job description)

expected_artifacts (code diff, tests, docs, PR, DB migration, report, etc.)

acceptance_criteria (tests pass, coverage, lint, doc updated, etc.)

constraints (budget, token limits, time, tools allowed)

context_refs (links to sub-PRDs, schemas, API docs, etc.)

Parents are responsible for shrinking the global brief and task payload to respect each child’s context window and Max Tok from PRD_Agents.md. Appendix A.9 contains a condensed job card field table. 2.4 LLM Selection & Failover 2.4.1 Per-Agent-Type Model Selection For each agent type (Architect, Director, Manager, Programmer):

Settings define:

Primary LLM

Backup LLM

Mode: fixed or Auto

Candidates come from PRD_LAN_LLM_API_Integration.md (frontier APIs, LAN models via LM Studio / Ollama / LLMCPP, etc.). 2.4.2 Auto Mode Priority In Auto mode, a separate configuration specifies priority:

quality

token_cost

energy_consumption

Energy consumption is relevant for LAN models that are “free per token” but not free in power. 2.4.3 Failover Rules (Minimum) For each individual agent task (job_card + delegation):

Try Primary model.

On provider-level failure (down, budget exhausted, timeouts):

Retry with exponential backoff (settings-driven).

After N failed attempts:

Switch to Backup model.

After Backup also fails:

Use Auto routing based on priority policy.

If a model produced bad artifacts that failed tests or checks:

Mark that model as “bad for this job_card” and do not reassign that same job to that same model again.

Appendix A.8 summarizes this as a table. 2.5 Ports & Modular Services All components are FastAPI (or equivalent) services on dedicated ports (see PRD_Polyglot_Agent_Swarm.md and PRD_Agents.md). Example layout (actual numbers may differ; Appendix A.1 is the normative table):

PAS Root / Gateway / HMI

Provider Router

Token Governor

Resource Manager

TRON / Heartbeat monitor

Architect

Directors & Managers

Programmer Pools

GitOps agent

Blueprint

Rule: Every new subsystem (Blueprint, GitOps, special lane agents, etc.) must be its own ported service, registered in the Agent Directory. No hidden in-process “special cases.” 2.6 Logging, SSE & TRON 2.6.1 Log Format Canonical log format (already in use):

══════════ START: () ══════════

YYYY-MM-DD HH:MM:SS TYPE      PROVIDER  FROM_AGENT → TO_AGENT  [model-or-port]

  Message text (multi-line allowed)

  Status: [progress%]

TYPE includes: STATUS, CMD, RESPONSE, CHAT, ERROR, etc.

Every entry must carry: run_id, thread_id (if applicable), lane, agent_id.

Appendix A.4 includes the condensed table. 2.6.2 SSE Progress

Agents publish status updates via SSE:

state (planning, executing, testing, waiting_on_child, waiting_on_resource, blocked, failed, complete, etc.)

progress 0–100 (heuristic, not wall-clock)

message (one-line summary)

HMI and TRON consume these events to display progress and detect stalls.

Appendix A.7 defines the SSE payload fields.

2.6.3 TRON (“the police”)

TRON monitors:

Agent heartbeats.

Thread activity and idleness.

Lane failures and repeated retries.

The user can talk to TRON via HMI:

Ask what’s stuck or failing.

Pause/resume lanes or entire runs.

Trigger escalations or reassignments.

TRON does not modify code or artifacts directly; it supervises and coordinates. 3. Parent–Child Protocol This is the canonical behavior for Architect ↔ Directors ↔ Managers ↔ Programmers.

All concrete implementations must conform to PRD_Parent_Child_Chat_Communications.md and this section.

3.1 Threaded Conversations

Every delegation occurs within an Agent Conversation Thread:

thread_id

run_id

parent_agent_id

child_agent_id

job_card_id

All messages between parent and child are stored in the conversation tables and streamed via SSE.

No ad-hoc one-off HTTP calls for tasking are allowed.

If an agent currently bypasses threads, that is a bug.

Appendix A.6 summarizes the thread data model. 3.2 Message Types (Fixed) The allowed message types are:

delegation – Parent assigns a job_card to a child.

ack – Child confirms understanding & readiness.

questions – Child requests clarification or additional info.

answer – Parent answers those questions.

status – Child reports progress; may be repeated.

complete – Child reports successful completion, with summary & artifacts.

error – Child reports failure, with cause & recommended action.

Agents may _not_ invent new message types; everything must map to one of the above.

See Appendix A.5 for a compact reference.

3.3 Two-Phase Handshake (Mandatory) For every delegation:

Architect → Director

Director → Manager

Manager → Programmer

3.3.1 Phase 1 – Review & Acknowledge

Parent sends delegation with:

Natural language description of the task.

job_card (including global brief reference and local details).

Child must respond with:

ack, restating the task in its own words and listing assumptions, or

questions, listing missing information, conflicts, or risks.

Parent may send one or more answer messages.

Child sends a final ack when:

It believes it has enough info to proceed.

It commits to starting the work.

No work may begin before a final ack.

If a Programmer calls Aider or modifies code before ack, that’s a protocol violation.

3.3.2 Phase 2 – Work & Completion

Child performs the work, sending periodic status messages with:

state and progress.

Short textual summary of what it’s doing.

On success:

Child sends complete with:

Summary of work performed.

Acceptance criteria results (tests, coverage, lint, docs updated, etc.).

Links to artifacts (diffs, PRs, log files, reports).

On failure:

Child sends error with:

Cause (tool failure, provider failure, missing dependency, test failures, etc.).

Recommended next step (retry with different LLM, re-scope task, escalate).

Parents consider a task “done” only upon complete or error, never from silence. 3.4 Asynchronous Execution & Shared Resources

Tasks can be executed asynchronously and in parallel.

When a task requires a serial resource (e.g., shared Git workspace, DB migration pipeline):

Managers annotate the job_card with a resource_lock identifier.

Resource Manager enforces exclusive access or queueing.

If a child is blocked on a resource, it sends status with state="waiting_on_resource" so TRON/HMI can display it. 4. Supervising & Support Agents 4.1 TRON (Heartbeat Monitor / Police)

Monitors heartbeats and SSE status events.

Detects:

Stuck threads (no status in threshold).

Dead agents (no heartbeat).

Lanes repeatedly failing.

User interactions with TRON:

Query current run health.

Request explanations for failures and stuck tasks.

Trigger safe actions: pause, retry, reassign to different models, or abort lanes/runs.

4.2 GitOps Agent There must be a dedicated GitOps agent:

Name: GitOps (final name in PRD_Agents.md)

Responsibilities:

Manage Git branches per run/lane.

Stage and commit changes produced by Programmers (via Aider outputs).

Open and manage Pull Requests.

Handle rollback workflows.

Interfaces:

Managers and Directors delegate Git operations via job_cards (e.g., “open PR for lane Code with these diffs”).

GitOps exposes simple endpoints:

/open_pr, /merge_pr, /rollback, /status (exact schema defined in a dedicated GitOps PRD).

No other agent should call git directly. 4.3 Token Governor & Resource Manager

Token Governor:

Enforces token budgets per agent and per run.

Requests summarization when context grows too large.

Resource Manager:

Tracks available LLM quotas, compute budgets, and shared resources.

Applies system-wide caps per provider, per lane, per run.

Agents must respect decisions from these supervisors; they are not advisory. 5. Implementation Requirements for Devs This is the “do this now” section. 5.1 Enforce Parent–Child Protocol Everywhere

Refactor Architect, all Directors, all Managers, and all Programmer pools to:

Use the conversation-thread DB/API defined in PRD_Parent_Child_Chat_Communications.md.

Use only the message types in §3.2.

Obey the handshake in §3.3 (no work before ack, no silent completion).

5.2 Align to the Common Agent Codebase Per PLAN_Common_Agent_Codebase.md:

Directors:

Must subclass or use BaseDirector.

Only lane-specific logic in decomposition & validation.

Managers:

Must use BaseManager.

Only implement splitting into programmer tasks and resource-lock decisions.

Programmers:

Must use BaseProgrammer and be instantiated via a pool implementation, not one app per programmer.

All edits must run via Aider RPC, never raw filesystem writes.

5.3 Wire Prompts & Job Cards Correctly

Replace scattered ad-hoc prompt strings with calls into PRD_PAS_Prompts.md definitions:

Global base prompt + role prompt.

For every delegation:

Use job_cards as described in §2.3.3 to pass:

Global brief references.

Local task payload.

Expected artifacts & acceptance criteria.

5.4 Standardize Model Selection & Failover

Implement a central model-selector function/library that:

Applies Primary → Backup → Auto policy.

Records model failures per job_card.

Avoids reassigning a failed job to the same failing model.

All agents (Architect, Directors, Managers, Programmers) must request models from this central helper, not embed provider selection logic.

5.5 Logging & SSE

Ensure all agents:

Use the unified log format (§2.6.1).

Emit SSE status events with run_id, thread_id, lane, agent_id, state, progress, and message.

TRON must:

Subscribe to these streams.

Surface stuck threads and failing lanes in the HMI.

5.6 Introduce / Finalize GitOps Agent

Add GitOps agent definition to PRD_Agents.md and give it a dedicated port.

Update Managers/Directors to:

Stop running Git commands directly.

Create Git job_cards and delegate them to GitOps.

5.7 Respect Token Limits

Use Max Tok from PRD_Agents.md to:

Summarize global brief appropriately per agent.

Keep local tasks within context limits.

Add guardrails so:

If a task can’t fit, the agent reports error with “context too small” and suggested options (split task, use a larger-context model, or reduce scope).

5.8 Condensed PRDs for Small LLMs

For each large PRD, a consultant (or agent) should create a _condensed version, e.g.:

PRD_PAS_Master_Orchestration_condensed.md

PRD_PAS_Project_Agentic_System_condensed.md

These condensed PRDs:

Focus on: invariants, tables, run flows, and constraints.

Are targeted at small models (4K context) and quick-reference usage.

Can reuse the Appendix tables from this doc.

6. Open Issues & Future Work These are intentionally left flexible for future PRDs:

Exact numeric thresholds

Timeouts, heartbeat intervals, SSE idle thresholds, and retry counts.

Will be specified in a future “Operational Parameters” PRD or config file.

Model quality thresholds

At present, all models in the cluster are considered capable.

If weaker models are added, we may need explicit “min IQ” constraints per agent type and lane.

Error taxonomy

It may be useful to classify errors more finely (provider failure vs. tool failure vs. spec failure vs. dependency failure).

This would enable smarter automatic reassignments and better analytics.

Lane-specific extensions

DevSecOps and DB lanes will likely need additional contracts for scanners, migrations, approvals, and rollback policies.

7. Documentation Structure & Condensed Variants 7.1 Three-level structure

Level 1: This PRD (PRD_PAS_Master_Orchestration.md) – global behavior and invariants.

Level 2: Major subsystem PRDs (PAS spine, Agents, Prompts, Parent–Child, LLM Integration, Blueprint, Polyglot swarm, etc.).

Level 3: Subsystem-specific and lane-specific PRDs (GitOps, DB migrations, DevSecOps, test strategies, etc.).

7.2 Condensed variants For small LLMs and quick-reference usage:

Each major PRD should have a _condensed sibling focusing on:

Appendices and tables.

Constraints and invariants.

Minimal narrative.

Agents with tight context windows should be steered to the _condensed versions by default. 8. Developer Checklist Use this checklist for PRs that touch PAS orchestration, agents, or infra: Protocol & Threads

Does the agent use the standard Agent Conversation Thread mechanism for all parent–child communication?

Does it use only the approved message types (delegation, ack, questions, answer, status, complete, error)?

Is the two-phase handshake enforced (no work before ack)?

Common Agent Codebase

Does the agent subclass/use the appropriate base class (BaseDirector, BaseManager, BaseProgrammer)?

Has lane-specific logic been kept minimal and in the right place?

Are any previous one-off agent implementations deprecated or removed?

Prompts & Job Cards

Is the prompt composition GLOBAL_BASE + ROLE_PROMPT + GLOBAL_BRIEF (summary) + LOCAL_TASK, not ad-hoc text?

Is the job_card used to convey global brief reference, local task, expected artifacts, and acceptance criteria?

Is the job_card size appropriate for the target agent’s token limit?

Model Selection & Failover

Does the agent use the central model-selection helper (Primary → Backup → Auto)?

Are failures recorded so that a failing model isn’t reused for the same job_card?

Logging, SSE & TRON

Are log entries emitted in the canonical format (with TYPE, agents, model, run_id, state, progress)?

Are SSE status events emitted with state, progress, and a meaningful message?

Can TRON detect and explain stuck states for this agent?

GitOps & Resources

If Git is involved, does the agent delegate to GitOps via job_cards rather than calling git directly?

Are resource locks (resource_lock) used when a serial resource is required?

Token / Context Management

Does the agent respect Max Tok for itself and its children when delegating?

Does it handle “context too large” gracefully (e.g., summarizing or erroring with an explanation)?

Documentation & Condensed PRDs

Are changes in behavior reflected in this PRD or appropriate Level-2/Level-3 PRDs?

If the PRD grew significantly, was a _condensed variant updated or planned?

Appendix A – Quick Reference Tables The appendices are designed to be easy for both humans and LLMs to scan.

Each table is followed by a note with the master datastore for that information.

A.1 Ports (Example Layout) PortServiceCategoryNotes 6100PAS Root / GatewayCoreEntry point for Prime Directives 6101HMICore UIUser-facing UI / SSE consumer 6102Event StreamCore InfraSSE / WS broadcast 6103Provider RouterLLM InfraFrontier APIs, LAN models 6104Resource ManagerLLM InfraQuotas, resource locks 6105Token GovernorLLM InfraToken budgets, summarization 6109TRON / HeartbeatSupervisorHealth & policing 6110+Architect, DirectorsWork AgentsCore worker agents 6120+ManagersWork AgentsLane-specific managers 6130Aider RPCToolingFile editing for Programmers 6140+Programmer PoolsWork AgentsCode/docs/test implementers 6150+GitOpsSupportGit / PR management 6160+BlueprintPlannerCompany-level planning Master datastore:

PRD_Polyglot_Agent_Swarm.md and PRD_Agents.md define the canonical mapping of ports to services.

Runtime source of truth: Agent Directory database (agents table) and environment/config files.

A.2 Agent Types & Roles Agent TypeExamplesRole Summary ArchitectArchitectHuman-facing, decompose Prime Directive DirectorDir-Code, Dir-Docs, Dir-Test, Dir-DB, Dir-DevSecOps, Dir-DataLane-level planning and delegation ManagerMgr-Code-01, etc.Slice lane work, manage resources and Programmers ProgrammerProg-Code-001, etc.Execute tasks via Aider; produce artifacts SupervisorTRON, Token Governor, Resource Manager, GitOps, BlueprintMonitoring, orchestration, infrastructure Master datastore:

PRD_Agents.md for the list of agent types and instances.

Agent Directory DB (agents table) for live agents.

A.3 LLM Provider Types Provider TypeExamplesNotes Frontier APIOpenAI, Anthropic, GeminiHigh-quality, external APIs LAN ModelsLM Studio, Ollama, LLMCPPLocal-network models, energy cost only Auto ModeManaged by Provider RouterChooses based on quality/cost/energy Master datastore:

PRD_LAN_LLM_API_Integration.md and provider config files.

Provider Router’s registry (DB/config).

A.4 Log Format FieldDescription TimestampYYYY-MM-DD HH:MM:SS TypeSTATUS / CMD / RESPONSE / CHAT / ERROR ProviderLLM used (if applicable) From / ToFROM_AGENT → TO_AGENT Model/Port[model-name] or [port] MessageHuman-readable description StatusStatus: [progress%] (optional) Master datastore:

PRD_PAS_Project_Agentic_System.md logging section.

Logging configuration files and log ingestion setup (e.g., ELK, Loki).

A.5 Message Types (Parent–Child) TypeDirectionPurpose delegationParent → ChildAssign job_card / task ackChild → ParentConfirm understanding & readiness questionsChild → ParentAsk for clarification answerParent → ChildProvide clarifications statusChild → ParentProgress update completeChild → ParentSuccessful completion & artifacts summary errorChild → ParentFailure & recommended next action Master datastore:

PRD_Parent_Child_Chat_Communications.md and agent-chat DB schema.

A.6 Parent–Child Thread Data Model (Conceptual) FieldDescription thread_idUnique ID for the conversation run_idPrime Directive / project ID parent_agent_idParent agent in this thread child_agent_idChild agent in this thread job_card_idAssociated job_card (if any) stateopen / closed / failed / complete created_atThread creation timestamp updated_atLast activity timestamp Master datastore:

Agent Conversation Threads DB (agent_conversation_threads table) defined in PRD_Parent_Child_Chat_Communications.md.

A.7 SSE Status Payload FieldDescription run_idPrime Directive / project ID thread_idConversation thread (if applicable) laneCode / Docs / Test / DB / DevSecOps / … agent_idEmitting agent stateplanning / executing / testing / waiting_on_child / waiting_on_resource / blocked / failed / complete progress0–100 (heuristic step-based progress) messageShort human-readable description Master datastore:

PRD_PAS_Project_Agentic_System.md SSE section.

HMI & Event Stream service configuration.

A.8 Failover & Auto Mode Rules StepConditionAction 1Primary OKUse Primary 2Primary provider failureRetry with backoff N times 3Primary fails N timesSwitch to Backup 4Backup provider failureRetry with backoff N times 5Backup fails N timesUse Auto mode (quality/cost/energy) 6Model produced bad artifactsDo not reassign this job_card to that model again Master datastore:

PRD_LAN_LLM_API_Integration.md and Provider Router code.

A.9 Job Card (Condensed Fields) FieldDescription job_card.idUnique job card ID run_idPrime Directive ID laneCode / Docs / Test / DB / Data / DevSecOps / … agent_roleDirector / Manager / Programmer global_brief_refPointer to global brief text task_summaryLocal task description expected_artifactsDiffs, tests, docs, reports, PRs, migrations, etc. acceptance_criteriaConditions for success constraintsToken/compute/time limits, tools allowed context_refsLinks to relevant PRDs, schemas, API docs, etc. Master datastore:

PRD_PAS_Prompts.md job_card templates.

PAS Job & Receipt DB (job_cards / job_receipts tables) from PRD_PAS_Project_Agentic_System.md.

A.10 Communication Matrix (Who Talks to Whom) Legend:

C = direct chat / command allowed

S = status / monitoring only

– = no direct communication

From \ ToUserArchitectDirectorManagerProgrammerTRONGitOpsBlueprint User–C–––C–C ArchitectC–C––S–– Director–C–C–SC– Manager––C–CSC– Programmer–––C–S–– TRONCSSSS–S– GitOps––SSSS–– BlueprintCC–––S–– Master datastore:

This PRD (communication policy is defined here).

Routing rules in Gateway / Message Router code.

A.11 Agent Directory (Condensed) FieldDescription agent_idUnique identifier (name) roleArchitect / Director / Manager / Programmer / Supervisor laneCode / Docs / Test / DB / … (if applicable) hostHostname or IP portService port parent_idParent agent ID (or null) tagsCapabilities, lanes, metadata max_tokMax token context for assigned model(s)

  | Table                 | PRD Says                                | Actual Location                                                                           | Access

  Method                                                                    |

  |-----------------------|-----------------------------------------|-------------------------------------------------------------------------------------------|---------

  -------------------------------------------------------------------------|

  | A.1 Ports             | PRD_Agents.md + env files               | Hardcoded in each app.py                                                                  | Check

  services/pas//app.py                                                      |

  | A.5 Message Types     | PRD_Parent_Child_Chat_Communications.md | services/common/agent_chat.py:62-66                                                       | Uses:

  delegation, question, answer, status, completion, error, escalation, abort |

  | A.6 Thread Data Model | "agent_conversation_threads table"      | artifacts/registry/registry.db                                                            |

  AgentChatClient from services/common/agent_chat.py                               |

  | A.9 Job Cards         | "job_cards table"                       | artifacts/queues/{agent}/inbox.jsonl                                                      | JobQueue

   from services/common/job_queue.py                                       |

  | A.4 Log Format        | Logging config files                    | artifacts/logs/pas_comms_.txt + artifacts/registry/comms_log.db (action_logs table) |

  CommsLogger from services/common/comms_logger.py                                 |

  | A.3 LLM Providers     | Provider Router registry                | artifacts/model_registry/models.db                                                        |

  ModelRegistry from services/model_registry/model_registry.py                     |

  | A.11 Agent Directory  | "agents table"                          | Does not exist as table - agents register via heartbeat                                   | No

  persistent store   

End of PRD_PAS_Master_Orchestration.md.