CR-039: Add AMD submission materials

docs/change/change_log.md

@@ -7,6 +7,7 @@ This file provides a chronological, human-readable record of applied codebase an
 *Note: For operational task and run history, consult `.triagecore/ledger.jsonl`.*
 
 ## [Unreleased]
+- Implemented CR-039 (AMD Cloud Agent Routing Demo): Add an AMD-specific submission overview, governed cloud demo walkthrough, route-manifest and TaskPacket examples, route-audit example evidence, and a judge-facing note that references CR-040 executable routing-policy evidence without changing runtime behavior.
 - Implemented CR-038 (Submission Demo Refresh After Manifest Warning CLI): Update reviewer and submission docs so `tc model check` and `tc model warn` appear as optional deeper verification steps with explicit non-blocking claim boundaries.
 - Implemented CR-037 (Model Manifest Warning CLI Surface): Add `tc model warn --manifest <path> --route <path>` as a warning-only CLI demo path for manifest/route comparison without backend probing, routing enforcement, or ledger mutation.
 - Implemented CR-036 (Model Manifest Runtime Warning Gate): Add a pure metadata-only route-to-manifest comparison report that warns on backend/model/route, alias-only identity, and incomplete integrity mismatches without blocking runtime execution.

docs/change/requests/CR-039-amd-cloud-agent-routing-demo.md

@@ -0,0 +1,24 @@
+# CR-039: AMD Cloud Agent Routing Demo
+
+## Status
+Implemented
+
+## Scope
+- Add an AMD-specific submission overview that reframes TriageCore around governed cloud GPU agent execution.
+- Add an AMD-specific demo walkthrough that shows local preflight, cloud escalation, validation, and human approval.
+- Add example artifacts for AMD cloud route manifest, TaskPacket escalation, and ledger evidence.
+- Keep the existing Qwen submission path intact instead of overwriting it.
+
+## Implementation Authority
+Documentation-first repo slice.
+
+## Description
+This change creates a second hackathon framing for TriageCore that is centered on AMD cloud GPU routing rather than Qwen-specific backend branding. The AMD version presents TriageCore as a governed control plane for AI agents running across local and AMD cloud infrastructure. The focus is on when cloud escalation is allowed, how it is bounded, and what evidence is preserved before and after heavier inference runs.
+
+## Acceptance Criteria
+- [x] `docs/submission/amd_cloud_submission_overview.md` exists and includes project story, technical architecture, AMD fit, and claim boundaries.
+- [x] `docs/workflows/amd_cloud_demo.md` exists and shows a bounded end-to-end AMD escalation path.
+- [x] `docs/examples/model_route_manifest_amd_cloud.json` exists and represents AMD cloud as an explicit escalation target.
+- [x] `docs/examples/taskpacket_amd_cloud_escalation.json` exists and can justify the AMD route.
+- [x] `docs/examples/ledger_event_amd_cloud_route_audit.json` exists and records route, backend, validation, and approval metadata.
+- [x] Submission docs preserve the existing Qwen bundle instead of silently replacing it.

docs/examples/ledger_event_amd_cloud_route_audit.json

@@ -0,0 +1,14 @@
+{
+  "event_type": "route_audit",
+  "task_id": "amd-demo-001",
+  "privacy_class": "external_safe",
+  "risk_level": "moderate",
+  "route_decision": "allow_cloud_escalation",
+  "selected_backend": "amd_developer_cloud",
+  "selected_model": "amd-cloud/llama-70b-instruct",
+  "validation_status": "passed",
+  "approval_required": true,
+  "approval_status": "approved",
+  "approved_by": "operator",
+  "notes": "Example metadata-only audit record for AMD cloud GPU escalation."
+}

docs/submission/README.md

@@ -33,3 +33,19 @@ The operator-facing walkthrough is here:
 
 That document is the live demo script. This `docs/submission/` bundle is the judge packet.
 
+## Alternate Framing Draft
+
+- [amd_cloud_submission_overview.md](amd_cloud_submission_overview.md)
+
+This is a separate AMD-oriented framing draft. It does not replace the existing Qwen-centered judge path.
+
+### AMD routing policy evidence
+
+TriageCore's AMD cloud path is not only documented. CR-040 adds executable
+routing-policy evidence showing when tasks remain local, use deterministic
+tools, require approval for AMD cloud escalation, or are blocked from cloud
+egress due to privacy policy.
+
+This keeps AMD cloud acceleration inside an inspectable governance layer: task
+metadata and route manifests drive the decision, while approval gates and audit
+expectations prevent cloud escalation from becoming an unbounded default.

docs/submission/amd_cloud_submission_overview.md

@@ -0,0 +1,104 @@
+# AMD Cloud Submission Overview
+
+## Project Title
+
+TriageCore: Governed AI Agents on AMD Cloud
+
+## Short Description
+
+TriageCore is a privacy-first control plane for AI agents that routes tasks across local and AMD cloud GPU infrastructure with risk checks, approval gates, revocable permissions, and auditable task ledgers.
+
+## Project Story
+
+Many agent demos focus on how powerful a model becomes once it already has compute, tools, and context. TriageCore focuses on the control problem before that point.
+
+A user starts with a messy task. TriageCore converts that request into a structured `TaskPacket`, performs local privacy and risk checks, and then decides whether the task should stay local, use a deterministic tool, or escalate to an AMD cloud GPU path for heavier inference.
+
+That means AMD cloud compute is not just a deployment detail. It becomes a governed capability inside the system. TriageCore keeps smaller, sensitive, or deterministic work local whenever possible, while using AMD-backed cloud inference when a workload needs more model capacity, broader context handling, or faster high-compute execution.
+
+## Technical Architecture
+
+```text
+User Task
+    |
+    v
+TaskPacket Builder
+    |
+    v
+Privacy + Risk Preflight
+    |
+    +--> Local model route
+    |
+    +--> Deterministic tool route
+    |
+    +--> AMD cloud GPU escalation route
+              |
+              v
+      Heavy inference on approved AMD backend
+              |
+              v
+      Output validation + policy checks
+              |
+              v
+      Human approval / rejection
+              |
+              v
+      Append-only audit ledger
+```
+
+## Demo Control Flow
+
+1. User submits a messy task.
+2. TriageCore converts it into a structured `TaskPacket`.
+3. Local preflight classifies privacy, sensitivity, and execution risk.
+4. Router selects local execution, deterministic tooling, or AMD cloud GPU escalation.
+5. The AMD route performs the heavier inference workload.
+6. TriageCore validates the returned output before it can be accepted.
+7. Human review approves or rejects the result.
+8. The ledger records route, backend, validation outcome, and approval metadata.
+
+## Why This Fits AMD
+
+The AMD hackathon emphasizes AI agents and high-performance AI applications built on AMD cloud infrastructure. TriageCore fits that framing best when AMD compute is part of the actual control logic instead of an afterthought.
+
+The AMD version of TriageCore highlights:
+
+- cloud GPU routing as a first-class route decision
+- performance-aware escalation for harder workloads
+- revocable permissions before external execution
+- post-inference validation before acceptance
+- auditable evidence for route, backend, and approval state
+
+## Practical Business Value
+
+Teams want stronger AI capabilities without losing control over data movement, review boundaries, or accountability. TriageCore addresses that operational gap. It helps organizations decide when a task can use high-performance cloud inference and when it must stay local, then records what happened in a reviewable ledger.
+
+That makes the system relevant for regulated engineering workflows, privacy-conscious development teams, and any setting where powerful agent execution needs governance instead of blind trust.
+
+## AMD Routing Policy Evidence
+
+The AMD cloud path is not only documented. CR-040 adds executable
+routing-policy evidence showing when tasks remain local, use deterministic
+tools, require approval for AMD cloud escalation, or are blocked from cloud
+egress due to privacy policy.
+
+That matters for judges because it turns the AMD story from a slide-level
+architecture claim into test-backed governance behavior. Task metadata and
+route manifests drive the decision, while approval gates and audit expectations
+keep cloud escalation from becoming an unbounded default.
+
+## Claim Boundaries
+
+This AMD framing should be presented as a governed demo path, not as proof that every production cloud-safety concern is fully solved.
+
+Safe claims:
+
+- TriageCore can represent AMD cloud as an explicit escalation target.
+- TriageCore can preserve preflight, validation, and approval boundaries around a cloud route.
+- The demo shows governance and auditability around high-performance agent execution.
+
+Avoid these claims:
+
+- that all cloud routes are production hardened
+- that every AMD path is live during the walkthrough
+- that cloud escalation bypasses privacy review or human approval

docs/workflows/amd_cloud_demo.md

@@ -0,0 +1,47 @@
+# AMD Cloud Demo Workflow
+
+This workflow is the AMD-specific operator path for presenting TriageCore as a governed cloud-agent control plane.
+
+## Purpose
+
+Use this walkthrough to show that TriageCore does not treat cloud GPU inference as the default answer to every task.
+
+Instead, it:
+
+- structures the incoming task
+- performs local privacy and risk classification first
+- escalates only when the workload justifies cloud execution
+- validates the returned output
+- preserves a human approval gate
+- records route and approval evidence in the ledger
+
+## Demo Path
+
+1. Show the input task from `docs/examples/taskpacket_amd_cloud_escalation.json`.
+2. Explain why the task is a bad fit for a small local route.
+3. Show the allowed AMD escalation target in `docs/examples/model_route_manifest_amd_cloud.json`.
+4. Walk through the route decision: local preflight passes, AMD escalation is allowed, and heavier inference is selected.
+5. Show the post-inference validation and approval boundary using `docs/examples/ledger_event_amd_cloud_route_audit.json`.
+6. Close by explaining that the ledger preserves a reviewable record of the cloud decision.
+
+## Talk Track
+
+A concise talk track:
+
+- TriageCore starts with governance, not with raw model power.
+- Sensitive or small tasks can stay local.
+- Heavier tasks can escalate onto AMD cloud GPUs when policy allows it.
+- Cloud output is still validated before acceptance.
+- Human review remains the decision boundary.
+- The ledger records who approved the route and what backend was used.
+
+## What To Point Out
+
+- AMD cloud is an explicit route target, not just hosting.
+- The escalation decision happens after local checks.
+- Validation and approval happen after cloud inference, not before.
+- The evidence trail is part of the system, not an after-demo explanation.
+
+## Claim Boundaries
+
+Do not imply that this walkthrough requires a live AMD credential or a production-complete cloud deployment. The point of the demo is to show governed escalation logic and auditable workflow structure.