Site search

Find architecture, research, and terms

Start typing to search the editorial index.

Implementation checklistTechnical

Implementation Checklist

A launch checklist for architecture, authority, tools, memory, recovery, evidence, testing, privacy, and operations.

This checklist is a design and release aid, not a certification. Apply it proportionally to task risk and system authority.

Scope and architecture

  • The system boundary and threat model are documented.
  • Model serving, agent orchestration, workflow, gateway, and MIR responsibilities are separated.
  • Control-plane and runtime-plane ownership is explicit.
  • Every durable state has an owner, retention rule, and deletion path.

Identity and authority

  • Requester, runtime, tool, tenant, and approver identities are attributable.
  • Tools are default-deny and categorized by side effect.
  • Credentials are short-lived, scoped, and excluded from prompts and memory.
  • High-impact actions require independent approval.
  • Outbound network access is minimized and monitored.

Execution and recovery

  • Inputs and tool outputs are schema-validated.
  • Budgets and stopping rules are finite.
  • Idempotency, timeout, retry, circuit breaker, and compensation behavior is defined.
  • Checkpoints exist before consequential side effects.
  • Pause, cancel, terminate, and incident-isolate paths are tested.

Evidence and operations

  • Policy decisions, approvals, tools, artifacts, and uncertainty emit typed events.
  • Evidence privacy, access, retention, export, and deletion are documented.
  • Run-level traces correlate model, tool, workflow, and infrastructure telemetry.
  • Operators can identify stuck, looping, degraded, or over-budget runs.

Release gates

  • Contract, adversarial, fault-injection, recovery, and repeated stochastic tests pass.
  • Accessibility and human approval interfaces are tested.
  • No unresolved citation, secret, placeholder, or unsupported metric remains.
  • Privacy, incident response, rollback, and owner contacts are production-ready.
  • A simpler system was considered and rejected for documented reasons.

Research-aware controls

  • Research and production claims are labeled separately.
  • Teleodynamic features are disabled unless explicitly selected.
  • Goal changes are typed, bounded, and evidenced.
  • Viability metrics cannot override immutable policy.
  • Structural adaptation has cost, rollback, and approval rules.
  • No-op and termination are valid outcomes.
  • Operator stop is tested.

Developer implementation controls

  • Lifecycle transitions are explicit and model errors are normalized.
  • Tool actions have idempotency and compensation.
  • Context packages carry provenance and evidence events use UTC.
  • Fault injection covers partial effects.
  • Public schemas are versioned and old evidence remains readable.
  • Runtime contracts do not depend on a provider SDK.

Source record

References

Suggest a correction
  1. National Institute of Standards and Technology. NIST. Published 2023-01-26; last reviewed 2026-06-20 UTC. Government framework.

  2. OWASP Agentic Security Initiative. OWASP. Published Current guidance; last reviewed 2026-06-20 UTC. Security guidance.

  3. Model Context Protocol project. Model Context Protocol. Published 2025-11-25; last reviewed 2026-06-24 UTC. Protocol specification.

  4. OpenTelemetry project. Cloud Native Computing Foundation. Published Current specification repository; last reviewed 2026-06-24 UTC. Official specification.