Foundation/Capability Patterns

DAN-86 · Agentic Design Language

Capability Patterns

The UI language for visualizing what agents can do, to whom, and under what conditions. These patterns make agent authority legible — at a glance, in a crisis, at 3am.

Color Semantics

The capability system uses three of the four Nodus semantic colors. Red is reserved for denied/revoked — it communicates loss of authority. Blue signals active capability. Gold signals constraint.

Token	Value	Capability Use
--ds-color-temporal	#2B44D4	Granted / active capability state
--ds-color-validation	#C49A1A	Conditional grant — time-bounded, value-bounded, or approval-gated
--ds-color-agency	#D42020	Denied, revoked, or the revoke action itself
--ds-color-outcome-positive	#2E7D32	Active grant status label (human-readable)

AgentCapabilityMatrix

Scannable grid: agents on rows, capability dimensions on columns. Designed for treasury dashboards where you need to assess 10+ agents at a glance without reading text.

Live Demo

Agent	Read	Write	Approve	Transact	Escalate
TR TreasuryExec Executor
RI RiskMonitor Observer
CA CashflowAnalyst Analyst
AU AuditBot Auditor

Legend:

Granted

Conditional

Denied

No grant

Anatomy: Agent identity column (sigil + name + role) · Five capability columns (Read / Write / Approve / Transact / Escalate) · 12×12 semantic dot per cell · Focus row for drill-down · Legend bar.

Prop	Type	Default	Description
agents	AgentRow[]	—	Array of agent rows. Each row has agentId, agentName, optional agentRole, and a capabilities map.
dimensions	CapabilityDimension[]	all five	Which capability columns to render. Defaults to read/write/approve/transact/escalate.
onCellClick	(agentId, dimension, state) => void	—	Optional click handler. When provided, cells are interactive and display a focus summary row.

Anti-patterns

Never use red for "granted" — red means denied/revoked in this system. Use --ds-color-temporal.
Never show capability states without the legend. A colored dot without legend context is unreadable.
Never place this in a narrow side panel. Minimum 600px for the 5-column layout. Use dimensions prop to reduce columns if space is tight.

CapabilityGrant

A single grant record: what capability, to whom, under what conditions, granted by whom, and with a full audit trail. Handles time-bounded, value-bounded, and approval-gated conditions.

Live Demo · Conditional Grant

TRANSACTontreasury/accounts/*→TreasuryExec

Conditional

$Value-bounded— Up to $50,000

⏱Time-bounded— Expires Jun 30, 2026

✓Approval-gated— Requires CFO

Granted by Sarah Chen (CFO)On Mar 20, 2026, 09:03 AMID: grant-c9

Live Demo · Active Grant (no conditions)

READontreasury/**→RiskMonitor

Active

Granted by System policyOn Jan 1, 2026, 12:00 AMID: grant-a1

Prop	Type	Default	Description
grantId	string	—	Unique grant identifier. First 8 chars shown in UI.
agentName	string	—	Display name of the agent receiving the grant.
capability	string	—	Capability name (e.g. TRANSACT, READ). Rendered uppercase monospace.
scope	string	—	Resource scope string (e.g. treasury/accounts/*). Rendered as a temporal-color badge.
conditions	GrantCondition[]	[]	Array of conditions. Each has a type (time-bounded \| value-bounded \| approval-gated) and type-specific fields.
status	'active' \| 'conditional' \| 'revoked' \| 'expired'	—	Grant status. Controls status chip color and whether revoke button shows.
grantedBy	string	—	Human-readable name of the granting authority.
grantedAt	string	—	ISO timestamp of grant issuance.
auditTrail	ProvenanceStep[]	[]	Audit events as ProvenanceChain steps. Toggle revealed via 'Audit Trail' button.
onRevoke	(grantId: string) => void	—	When provided, shows a Revoke button for active/conditional grants.

CapabilityRevokeFlow

Two-step revocation ceremony. Step 1 surfaces impact — tasks that will fail or degrade. Step 2 requires a written reason, creating a non-repudiable audit event.

Live Demo

Revoke Grant

TRANSACT on treasury/accounts/* → TreasuryExec

1Review Impact

2Confirm Revocation

2 tasks will fail1 task may degrade

DAN-91Execute Q1 wire batch — 14 transactions pendingIn ProgressWill fail

DAN-92FX hedge settlement — awaiting bank confirmationPendingWill fail

DAN-94Cash position report generationPendingMay degrade

Prop	Type	Default	Description
grantId	string	—	Grant to revoke.
agentName	string	—	Agent whose grant is being revoked.
capability	string	—	Capability being revoked.
scope	string	—	Scope of the grant being revoked.
impactedTasks	ImpactedTask[]	[]	Tasks that will be affected. Each has taskId, title, status, and severity (will-fail \| may-degrade \| unaffected).
onConfirm	(grantId, reason) => void	—	Called when user completes both steps with a written reason.
onCancel	() => void	—	Called when user cancels at any step.

Anti-patterns

Never allow single-click revocation. The two-step ceremony is intentional — it forces impact review and creates an audit record.
Never hide the impact list. Even "0 affected tasks" must be shown — it confirms the operator reviewed impact, not that impact was skipped.
Never allow empty reason strings. The revocation reason is the audit trail entry — enforce it at the UI layer.

Design Rules

Scannable first

The matrix must be readable at a glance. Dot size (12px), color contrast, and column alignment are all tuned for dense dashboard contexts.

Audit trail required

Every grant and revocation must expose a ProvenanceChain. Trust without provenance is opaque authority.

Conditions are first-class

Time-bounded, value-bounded, and approval-gated conditions must render as visible badges — not collapsed in a tooltip.

Revocation is a ceremony

Two steps minimum. Impact preview before confirmation. Written reason required. This is not a destructive action — it is an auditable one.