# DPF Conformance Assessment for TAK and GAID

## Purpose

This document assesses the current `DPF` implementation against the proposed `TAK` and `GAID` standards.

Status values:

- `Implemented`
- `Partially Implemented`
- `Not Implemented`
- `Not Yet Assessable`

This is a first-pass conformance view. It is intended to show where `DPF` already demonstrates relevant controls and where additional work would be required to claim higher-assurance conformance.

For the purposes of this document, `DPF` is treated as the initial implementation prototype for the standards family, not as a claim of full present-day conformance.

The companion verification rubrics intended to make future conformance claims repeatable are:

- `docs/architecture/tak-conformance-tests.md`
- `docs/architecture/gaid-conformance-tests.md`

## TAK Conformance

| Control Area | Status | Evidence Path | Notes | Recommended Next Step |
|--------------|--------|---------------|-------|-----------------------|
| Runtime authority mediation | Implemented | `apps/web/lib/mcp-tools.ts`, `apps/web/lib/tak/agent-grants.ts` | Tools declare `requiredCapability`; `getAvailableTools()` filters by user authority, mode, and external access posture; agent grant mapping adds a second control layer. | Make the effective permission intersection explicit in one auditable runtime object for every tool exposure decision. |
| Tool execution gating | Implemented | `apps/web/lib/mcp-tools.ts`, `apps/web/lib/tak/agentic-loop.ts` | Tools declare `executionMode`, `sideEffect`, and annotations; proposal-mode tools break the loop and return approval payloads rather than executing immediately. | Expand the execution-mode vocabulary beyond `immediate` and `proposal` to align more closely with the normative `TAK` oversight tiers. |
| HITL enforcement | Partially Implemented | `apps/web/lib/tak/agentic-loop.ts`, `packages/db/data/agent_registry.json` | `proposal` mode is enforced at runtime and the registry carries `hitl_tier_default`, but `HITL` tier does not yet appear to drive a uniform runtime policy engine across all actions. | Bind `hitl_tier_default` and route context into a single runtime policy decision that consistently governs all consequential actions. |
| Immutable directive handling | Partially Implemented | `apps/web/lib/tak/prompt-assembler.ts`, `apps/web/lib/tak/agent-routing.ts` | Prompt assembly separates identity, mode, authority, sensitivity, and route context into structured blocks, which is a strong foundation. However, there is not yet a full directive inventory with versioning, ownership, and audit metadata. | Add directive cataloging, version control, and governance metadata for hidden and immutable instruction classes. |
| Delegation narrowing | Partially Implemented | `apps/web/lib/tak/agent-routing.ts`, `packages/db/data/agent_registry.json` | `DPF` distinguishes route specialists and records supervisor and delegation metadata in the registry, but it does not yet provide a full receipt-backed delegated-authority chain at runtime. | Recompute and record narrowed authority at each delegation boundary, with parent-child evidence links. |
| Audit and evidence logging | Implemented | `apps/web/lib/tak/agentic-loop.ts` | Every tool execution is written to `ToolExecution` with `agentId`, `userId`, `toolName`, parameters, results, success, route context, duration, and audit class. | Add first-class links from tool execution rows to approval decisions and delegated child actions. |
| Memory and context controls | Partially Implemented | `apps/web/lib/tak/agentic-loop.ts`, `packages/db/data/agent_registry.json` | The runtime limits retained history and truncates tool and text context; the registry also carries memory metadata. This is useful but not yet a full governed memory policy model. | Add explicit retention classes, retrieval policy, freshness rules, and revalidation requirements for consequential memory use. |
| Runtime transparency | Partially Implemented | `apps/web/lib/tak/agent-routing.ts`, `apps/web/lib/tak/prompt-assembler.ts`, `apps/web/lib/tak/agentic-loop.ts`, `apps/web/lib/tak/agent-card-service.ts`, `apps/web/components/platform/AgentCardSupervisorPanel.tsx`, `apps/web/app/(shell)/platform/audit/authority/page.tsx` | The platform exposes route-specific agents, skills, sensitivity context, tool execution records, and an internal Agent Card projection with a supervisor-ready authority snapshot in the Authority & Audit workspace. The supervisor card now includes active grant and oversight metadata, pending proposal counts, latest pending proposal state, approval workflow references, recent receipt counts, receipt status, and journal links. That is a meaningful transparency posture, but not yet a complete supervisor-facing control plane for all runtime states. | Add directive versions, normalize the card state into one runtime policy object, and expose parent-child delegation and receipt chains. |
| Injection defenses | Partially Implemented | `apps/web/lib/tak/prompt-assembler.ts`, `apps/web/lib/tak/agentic-loop.ts`, `apps/web/lib/mcp-tools.ts` | The runtime includes fabrication detection, tool-use nudging, parameter sanitization, and sensitivity-aware prompting. These are real controls, but not yet a complete injection-defense architecture across prompts, tools, skills, and connectors. | Add explicit prompt-injection and connector-compromise handling with policy outcomes and test coverage. |
| Evaluation and red teaming | Partially Implemented | `docs/superpowers/specs/2026-03-25-tool-evaluation-pipeline-design.md`, runtime heuristics in `apps/web/lib/tak/agentic-loop.ts` | `DPF` has strong design intent and governance work, but the runtime evidence reviewed here does not yet show a fully integrated `TAK` conformance evaluation suite. | Define a repeatable `TAK` verification harness and red-team pack, then store the resulting evidence as part of conformance claims. |

## GAID Conformance

| Control Area | Status | Evidence Path | Notes | Recommended Next Step |
|--------------|--------|---------------|-------|-----------------------|
| Stable agent identity | Partially Implemented | `packages/db/data/agent_registry.json`, `apps/web/lib/tak/agent-routing.ts` | `DPF` already carries stable agent identifiers, model bindings, supervisors, delegates, tool grants, and memory declarations. However, these identities are still platform-local and are not yet expressed as canonical `GAID` identifiers. | Introduce canonical `GAID` identifiers and bind route-facing identities to them consistently. |
| Public/private identity scoping | Not Implemented | Current implementation review | The reviewed implementation does not yet distinguish internal private identifiers from externally accredited public identifiers. | Add explicit `priv` and `pub` identity scopes, plus governed boundary mapping rules. |
| Agent identity document | Partially Implemented | `packages/db/data/agent_registry.json` | The registry approximates an internal `AIDoc` because it already captures model, supervisor, grants, `HITL`, delegation, and memory metadata. It is not yet a signed, resolvable, standardized identity document. | Define and publish a formal `AIDoc` schema, resolution mechanism, and signing model. |
| Badge and assurance declarations | Not Implemented | Current implementation review | `DPF` contains useful metadata, but it does not yet publish structured badges for capability, governance, sensitivity, or fit-for-purpose, nor does it distinguish assurance levels. | Add badge schemas and evidence-backed assurance levels, starting with self-asserted and organization-attested claims. |
| Authorization classes | Partially Implemented | `apps/web/lib/tak/agent-grants.ts`, `apps/web/lib/mcp-tools.ts` | The platform has a strong local authorization model based on capabilities, tool grants, execution mode, and side-effect posture. That is adjacent to `GAID` authorization classes, but not yet portable or standardized. | Add a portable authorization-class vocabulary that maps to the existing local control model. |
| Signed receipt model | Not Implemented | `apps/web/lib/tak/agentic-loop.ts` | `DPF` records tool executions, which is valuable, but the resulting records are not signed receipts with external verification semantics. | Introduce cryptographically verifiable action receipts for consequential actions. |
| Chain-of-custody traceability | Partially Implemented | `apps/web/lib/tak/agentic-loop.ts`, `packages/db/data/agent_registry.json` | The platform records acting agent, user, route, and tool execution details. This gives a useful internal audit trail, but it is not yet a full end-to-end custody chain across delegation and external boundaries. | Add parent-child receipt links, delegation references, and distributed trace identifiers. |
| External validation and certificates | Not Implemented | Current implementation review | The reviewed implementation does not yet bind agent identity to public certificates, external issuer validation, or public status endpoints. | Add certificate-backed external validation for publicly exposed agents and issuer-operated status services. |
| Transparency logging | Partially Implemented | Internal execution logging in `apps/web/lib/tak/agentic-loop.ts` | Internal audit logging exists, but there is no public or federated transparency log for issuance, revocation, or public identity state changes. | Add a transparency log for agent issuance, status, and revocation events. |
| Protocol interoperability profile | Partially Implemented | `apps/web/lib/mcp-tools.ts`, `apps/web/lib/identity/aidoc-resolver.ts`, `apps/web/lib/tak/agent-card-service.ts` | `DPF` models tool metadata and open-world access in a way that can align with `MCP`-style interoperability, and it now has an internal Agent Card projection that carries `TAK` and `GAID` metadata for future A2A/MCP publication. It does not yet publish public A2A Agent Cards, public verifier metadata, or external receipt status endpoints. | Publish identity and receipt metadata through protocol profiles, starting with private A2A-compatible cards and MCP server metadata before public endpoints. |

## Recommended Roadmap

### Short-Term

- Formalize a canonical internal `AIDoc` representation from the existing agent registry fields.
- Bind `hitl_tier_default`, execution mode, and proposal handling into one explicit runtime policy model.
- Add `TAK` directive governance metadata for prompt blocks and immutable instruction classes.
- Add portable authorization classes that map to current capability and tool-grant logic.

### Medium-Term

- Introduce signed action receipts for consequential tool executions.
- Add parent-child traceability for delegation and multi-agent workflows.
- Publish first-generation badges for capability, governance, data sensitivity, and fit-for-purpose.
- Add `GAID` public/private namespace handling and status management.

### Prototype Outcomes

The most important prototype outcomes implied by the current standards refresh are:

- canonical private `GAID` issuance for every materially distinct agent subject
- an internal `AIDoc` service derived from the current registry and runtime state
- owner, sponsor, responsible-team, directory-binding, entitlement-scope, and blast-radius identity fields
- an internal badge registry with applicability scope, evidence references, and assurance levels
- signed or tamper-evident receipts for consequential actions
- protocol and directory projection profiles for `LDAP`, `SCIM`, `MCP`, and `A2A`
- a phased path from private enterprise `GAID` toward federated and public verification profiles

### Submission-Ready Future Work

- Stand up an accredited-issuer-ready public identity model with revocation and transparency logging.
- Expose `GAID` claims through `MCP`, `A2A`, and HTTP transport profiles.
- Build a repeatable `TAK` and `GAID` conformance test suite and preserve the resulting evidence.
- Extend `DPF` from platform-local identity into a demonstrable cross-boundary trust implementation suitable for standards-body review.
