Talisman of Admin for Teleodynamic.com

Full report

On this page

Executive Summary

The Talisman system on UAIX is explicitly a rare, advanced governance pattern for environments that need immutable totem.uai and taboo.uai anchors, external enforcement outside the model, no-op talk-back instead of self-mutation, human review, audit evidence, and rollback. UAIX also states that it is not a runtime controller, endpoint permission system, credential validator, or general safety guarantee; those controls must be implemented locally. For Teleodynamic.com, that means “Talisman of Admin” should be designed less like a generic memory plugin and more like a policy-governed control plane sitting inside WordPress admin, with WordPress handling UI, roles, and administrative workflows while the plugin itself enforces the local implementation boundary that UAIX leaves to operators.

The best-fit architecture is a plugin-first, theme-independent design with a hybrid storage model: use the Options API for durable plugin configuration, a custom post type for human review objects such as change requests, and custom database tables for high-write, relational, and graph-like data such as anchors, versions, action runs, webhook deliveries, and audit logs. That matches WordPress guidance: options are appropriate for setup information, post meta is preferred when practical, but growing plugin data can justify separate tables managed with dbDelta() and version-aware migrations. Plugin activation, uninstall, admin menus, REST route namespaces, and multisite handling also fit naturally in plugin lifecycle hooks rather than theme code. The uploaded background memo usefully frames synchronization and review concerns, but I would still keep this runtime in a standalone plugin so governance survives theme changes and can be administered consistently.

For external AI-agent access, I recommend a REST-first control plane with a versioned namespace such as toa/v1, explicit permission_callback handlers on every route, JSON-schema validation/sanitization, and capability-aware responses. For interactive browser admin, use standard WordPress cookie auth plus X-WP-Nonce; for remote services and richer external integrations, front the plugin with OAuth 2.0 / OpenID Connect and optionally mTLS-bound tokens for high-trust clients. WebSockets are useful for live dashboards and status streams, but not as the canonical mutation API. gRPC is best reserved for an optional sidecar or internal service bridge, not the public plugin surface. That recommendation lines up with WordPress REST patterns, OAuth/OIDC requirements, WebSocket and gRPC protocol properties, OpenAI’s current developer surfaces for Agents, ChatGPT Apps/Actions, MCP/connectors, webhooks, and WebSocket mode, and UAIX’s guidance to keep durable project memory separate from runtime execution.

The most important architectural conclusion is this: external agents should never get a direct “edit protected anchor” capability. In Talisman mode, protected anchors are request-only for agents. Agents can query memory, describe conflicts, propose changes, trigger allowed actions, and emit change requests, but the actual mutation of protected anchors must remain a human-reviewed, audited, out-of-band apply step. That is the single strongest design choice in this report, because it reproduces the central invariant of the UAIX talisman pattern inside WordPress.

Research Basis and Design Principles

UAIX gives four design constraints that should shape the plugin from the start. First, the Talisman system is for complicated, persistent, multi-actor ecosystems, not ordinary chatbots or simple single-agent workflows. Second, talisman.uai, totem.uai, and taboo.uai are read-only to the agent. Third, when an anchor blocks action, the agent must no-op and write a talk-back change request. Fourth, the actual write protection must be enforced by repository protections, filesystem permissions, CI rules, deployment policy, or runtime interception outside the model. A WordPress implementation therefore needs a policy engine, a review queue, immutable audit/version records, and a boundary between “requested” and “applied.”

A second important principle comes from UAIX’s wizard placement rule: talisman setup should not be mixed into the ordinary memory-package authoring flow. UAIX says it belongs behind one advanced gateway link only, with a warning label, while ordinary package creation stays on the normal path. That is a good UI principle for WordPress too. In practice, “Talisman of Admin” should default to standard memory mode and require an explicit Protected Anchor Mode enablement step with warnings, review-owner assignment, checksum policy, and rollback policy before the feature becomes active.

A third principle comes from WordPress itself. Admin pages should be attached through plugin menus guarded by capabilities, with the render callback re-checking capability. REST routes must be registered on rest_api_init, must be namespaced, and should always define permission_callback. Route inputs should be validated and sanitized using route args or REST schema helpers. Nonces help with CSRF and intent, but WordPress is explicit that nonces are not authorization and must be paired with capability checks such as current_user_can().

A fourth principle comes from UAIX’s OpenAI handoff guidance and OpenAI’s current developer surface. UAIX recommends keeping the runtime and the durable project-memory layer separate: OpenAI runs the agents, while repo-local files such as AGENTS.md and .uai/* preserve durable state, constraints, decisions, progress, and verification plans. In parallel, OpenAI’s current developer docs expose relevant surfaces for Apps SDK, ChatGPT Actions, MCP/connectors, webhooks, and WebSocket mode. The practical implication is that the plugin should support both a live API surface and a portable handoff bundle so Teleodynamic can work with multiple current and future agent runtimes without making WordPress the only durable memory location.

flowchart LR
    A[WordPress Admin UI] --> B[TOA Application Layer]
    C[REST API toa/v1] --> B
    D[Optional WebSocket or gRPC Sidecar] --> B
    E[External AI Agents<br/>ChatGPT Action / MCP Bridge / Service Client] --> C

    B --> F[Policy Enforcer]
    B --> G[Change Request Service]
    B --> H[Memory Graph Service]
    B --> I[Audit and Observability]
    B --> J[Backup and Restore]
    B --> K[Agent Registry and Webhooks]

    F --> L[(toa_anchor)]
    F --> M[(toa_anchor_version)]
    G --> N[(toa_change_request CPT)]
    H --> O[(toa_graph_node)]
    H --> P[(toa_graph_edge)]
    I --> Q[(toa_action_run)]
    I --> R[(toa_audit_log)]
    K --> S[(toa_agent_app)]
    K --> T[(toa_agent_token)]
    K --> U[(toa_webhook_delivery)]
    J --> V[(toa_backup_snapshot)]

    W[Cron and WP-CLI] --> B
    X[Reviewers and Operators] --> A

The architecture above is a design recommendation derived from UAIX’s external-enforcement model, WordPress plugin lifecycle and REST patterns, and the need to separate human-reviewed anchor application from agent-requested change proposals.

Plugin Architecture

I would implement the plugin under a namespace such as Teleodynamic\TalismanOfAdmin, with a top-level module split that reflects real operational boundaries rather than WordPress file categories alone:

This modular split is not mandated by WordPress, but it maps cleanly onto the constraints WordPress does set: plugin lifecycle hooks for setup/cleanup, REST controllers registered on rest_api_init, capability-based menus, options/settings storage, privacy exporters/erasers, and cron-triggered maintenance.

Storage model

The storage model should be hybrid.

Use custom tables for canonical operational data because this plugin must support versioned anchors, graph traversals, action run logs, token registries, retry queues, and audit trails. WordPress explicitly notes that setup information generally belongs in options, post meta is preferred when practical, but plugin data that grows with use can appropriately live in separate tables. Those tables should be created and updated with dbDelta(), with a plugin database version checked after updates because activation hooks do not run on plugin upgrade.

Use a custom post type for human review objects because change requests benefit from editorial affordances familiar to WordPress: custom statuses, comments/discussion, author attribution, search, moderation-like list views, and optional revision history. The source of truth for protected-anchor content should still remain in custom tables, but the human review queue fits naturally as a CPT. Custom post type capabilities and map_meta_cap handling make that practical.

Use taxonomies and registered meta sparingly. Taxonomies are useful to classify change requests by request type, risk, or scope. Registered meta is useful for selected CPT metadata that needs schema-aware validation and optional REST exposure.

Proposed schema

The storage split above is a proposed schema, but it is grounded in WordPress’s own division of concerns: options for setup data, custom tables for growing plugin data, CPT capabilities for review objects, and taxonomy/meta support when classification or schema-aware metadata is useful.

Custom post types, taxonomies, and meta

I recommend one primary CPT:

• toa_change_request: source object for all agent-emitted talk-back records and human-initiated protected-anchor change proposals.

I recommend these taxonomies:

Recommended registered meta for toa_change_request includes _toa_target_anchor_id, _toa_target_anchor_type, _toa_blocked_action, _toa_requested_change, _toa_evidence_json, _toa_no_op_performed, _toa_action_run_id, _toa_source_agent_app_id, _toa_apply_result_version_id, and _toa_reviewer_summary. Use register_meta() with explicit types, auth callbacks, and REST schema only for fields that truly need API exposure.

Roles and capabilities

WordPress is capability-first, not role-name-first, and explicitly discourages checking role names in place of capabilities. For Talisman of Admin, I would create three plugin roles and a compact capability lattice, then back object-sensitive operations with meta-cap mapping.

I would also define meta capabilities such as toa_view_anchor, toa_edit_anchor, toa_review_request, toa_apply_request, and toa_view_audit_record. The meta-cap layer should enforce separation of duties, for example: a requester should not approve their own high-risk protected-anchor change unless they also have an explicit override capability and that override is independently logged. This is a recommended application of WordPress’s meta-cap pattern, not a core requirement, but it aligns very well with the talisman review model.

This mapping is a recommended cap model built on WordPress role creation, current-user capability checks, post-type capability mapping, and taxonomy capabilities.

Hooks, cron, backup, and restore

The plugin should register the following WordPress hooks and lifecycle behaviors:

Cron jobs should exist, but because WP-Cron runs only on page load and can drift on low-traffic sites, I would treat server cron or scheduled WP-CLI invocation as the production-grade path for critical jobs.

Recommended scheduled jobs:

For backup and restore, I recommend two layers:

Logical plugin backup

• ZIP or tarball containing JSON/YAML exports of anchors, versions, graph nodes/edges, action runs metadata, change request CPT content/meta, webhooks, and settings.
• Signed manifest with checksums.
• Optional field-level encrypted blobs for sensitive payloads.
• Plugin-specific restore endpoint and WP-CLI command.

Full database backup

• Rely on wp db export / wp db import or hosting backups for disaster recovery.
• Use logical plugin exports for audited migration, partial restore, environment promotion, and rollback rehearsal.

That distinction matters because wp export creates WXR files for authors, terms, posts, comments, and attachments, but does not include site configuration or arbitrary plugin tables. Accordingly, Talisman of Admin needs its own logical export/restore path for canonical plugin data.

Admin Experience and Governance Workflow

The admin UX should feel native to WordPress, but it should not feel like a normal content-authoring plugin. In Talisman mode, the UI is fundamentally about controlled review, observability, and high-signal diffs, not free-form editing. That is why the first-run flow should ask for: whether Protected Anchor Mode is really required, who the reviewers are, what files/anchors are protected, what retention policy applies, where backups go, and whether external runtime enforcement exists. If those answers are incomplete, the plugin should refuse to enable Talisman mode and keep the site in ordinary memory mode. That mirrors UAIX’s “all conditions must be true” rule.

The admin surface should be a top-level menu page such as Talisman of Admin with sub-pages. WordPress’s menu APIs are a natural fit here, with capability-gated menu visibility and callback-level capability rechecks.

Recommended screens

The UI above is a recommended composition derived from UAIX’s review and rollback expectations plus WordPress admin patterns for menu pages and settings.

Sample admin mockup

┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Talisman of Admin                                    Site: teleodynamic.com   Mode: Protected│
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Overview │ Anchors │ Change Requests │ Memory Graph │ Action Runs │ Agents │ Audit │ Settings│
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ KPIs                                                                                         │
│ [Protected Anchors: 3] [Pending Reviews: 5] [No-Op Events 24h: 12] [Failed Webhooks: 1]    │
│ [Integrity Drift: 0]  [Expired Tokens: 4] [Last Backup: 2026-06-08T05:00:00Z]              │
├───────────────────────────────┬──────────────────────────────────────────────────────────────┤
│ Alerts                        │ Pending Review Queue                                         │
│ • Repeated taboo-loosening    │ #CR-104  Update taboo scope         High     Pending        │
│   requests from agent app A   │ #CR-105  New totem mission clause   Medium   Pending        │
│ • Webhook retry attempt 3     │ #CR-106  Reindex graph override     Low      Needs context  │
│ • Token nearing expiry        │                                                              │
├───────────────────────────────┼──────────────────────────────────────────────────────────────┤
│ Anchor Health                 │ No-Op / Conflict Trend                                        │
│ talisman.uai  ✓ signed        │ 7d sparkline + filters by anchor/app/risk                    │
│ totem.uai     ✓ signed        │                                                              │
│ taboo.uai     ✓ signed        │                                                              │
├───────────────────────────────┼──────────────────────────────────────────────────────────────┤
│ Memory Graph Snapshot         │ Audit Feed                                                  │
│ miniature node graph          │ 09:14Z reviewer approved CR-104                             │
│ color by trust/sensitivity    │ 09:08Z agent app "chatgpt-prod" emitted talk-back           │
│ click to inspect              │ 08:55Z checksum verification passed                         │
└───────────────────────────────┴──────────────────────────────────────────────────────────────┘

UX specifics that matter

The Overview screen should surface the metrics that UAIX itself says are operationally meaningful: repeated no-op events, repeated requests to loosen taboo.uai, checksum/signature state, and the health of the review queue. Those are not vanity metrics; they are exactly the patterns UAIX associates with over-constrained ecosystems, unsafe pressure, or prompt injection pressure.

The Protected Anchors screen should not expose a single-click inline editor. Instead, it should show current canonical text, prior versions, normalized diffs, approval history, and an “Open change request” action. A direct edit surface may still exist for explicitly authorized humans, but even that should route through a generated internal change request and produce a versioned apply event rather than silently mutating the current row. That keeps human edits auditable and preserves the same governance pattern as agent proposals. The underlying principle comes directly from UAIX’s talk-back and human-reviewed apply flow.

The Change Requests screen should be the center of gravity. The right-hand detail panel should show:

• target anchor
• blocked action
• requested change
• evidence
• risk summary
• rollback impact
• source agent/app
• linked action run
• compare-before/apply-after diff
• reviewer checklist
• result timeline

That shape mirrors UAIX’s example talk-back record and review requirements.

The Memory Graph screen should support two modes: a topological graph for exploratory investigation and a faceted list for scalable search. Graphs are visually compelling, but large graphs can overwhelm WP-admin. The scalable pattern is to compute neighborhoods server-side and render subgraphs around an anchor, action run, or query phrase. For WordPress admins, that is the difference between a useful visualizer and an unreadable canvas. The graph should also allow “show only protected-anchor influence,” “show only conflict edges,” and “show only action evidence” filters.

The Settings area should have a prominent Advanced Rare Use banner and separate standard memory settings from protected-anchor settings. That is the closest possible translation of UAIX’s “advanced gateway only” rule into WordPress UX.

Security and Agent Integration Design

The security model should be layered because the plugin has three distinct trust contexts: interactive WordPress admins, remote machine clients, and high-accountability protected-anchor operations. The trusted path for a logged-in admin is WordPress cookie auth plus REST nonce. The trusted path for a remote system is OAuth/OIDC or, as a fallback, WordPress Application Passwords over HTTPS. The trusted path for protected-anchor application is never an agent token alone; it always includes reviewer authorization, object-level capability checks, a decision record, and an auditable apply step. That structure is consistent with WordPress REST auth, UAIX’s enforcement boundary, and OAuth’s limited-access model.

Browser and admin security

For WordPress-internal admin requests, use:

• WordPress login cookies
• REST nonces with the wp_rest action and X-WP-Nonce
• current_user_can() checks at both route and service-layer boundaries
• object-sensitive checks through meta caps
• check_admin_referer() for classic form submissions

WordPress is explicit that nonces protect intent and help with CSRF, but they are not authentication or authorization. In other words, the plugin should never treat a valid nonce as sufficient to mutate anchors, approve reviews, or export backups.

All REST routes should:

• register on rest_api_init
• use a versioned namespace such as toa/v1
• define permission_callback
• validate and sanitize request args through route schema
• return structured errors with correlation IDs

Those are WordPress-native guardrails, and they should be treated as mandatory in this plugin.

Data validation, sanitization, and output safety

Talisman of Admin will inevitably process untrusted input: admin form fields, remote API requests, webhook payloads, and possibly AI-generated change proposals. WordPress’s own guidance is clear: validate as early as possible, prefer safelists and strict comparisons when possible, sanitize general text when necessary, and escape as late as possible on output. For a plugin like this, that means:

• safelist enums such as anchor types, risk levels, actions, and scopes
• regex validation for slugs, callback URLs, and identifier formats
• sanitize_text_field() for general single-line strings
• wp_kses() or wp_kses_post() for reviewer-visible rich text
• esc_html(), esc_attr(), esc_url(), and friends at render time
• REST-schema validation for JSON bodies
• reject malformed arrays/objects early rather than normalizing everything silently

Encryption, transport, and secrets

In transit, require HTTPS for every remote integration. OAuth revocation endpoints must be HTTPS, bearer tokens should be sent in headers not URLs, and WordPress Application Passwords are documented for HTTPS-served REST requests.

At rest, I recommend three different treatments:

• Hash opaque access tokens and refresh tokens, so the database never stores bearer material in plaintext.
• Encrypt reversible secrets such as webhook signing secrets, client secrets, and any cached third-party credentials.
• Leave anchor content plaintext by default, but support field-level encryption for restricted anchors or evidence payloads containing sensitive data.

WordPress’s own Application Passwords guide recommends storing credentials encrypted rather than in plaintext and explicitly mentions libsodium or external secret managers such as Vault. The plugin should follow the same principle for its own machine credentials.

For secrets management, the most robust design is:

• key-encryption keys in environment variables, wp-config.php constants, or external secret/KMS systems
• only encrypted data keys or sealed blobs in database rows
• secret rotation UI and cron-assisted rotation reminders
• no long-lived raw secrets in logs, exports, or support bundles

That last point matters as much for compliance as for security.

Protocol and integration options comparison

This comparison is based on WordPress REST requirements, the WebSocket RFC, gRPC core concepts, OpenAI’s currently documented product surface, and UAIX’s runtime-versus-durable-memory model.

Authentication options comparison

The OAuth/OIDC columns above follow the specifications directly: OAuth exists to grant limited access, access tokens should be scoped and short-lived, refresh tokens are optional and can mint narrower-scope access tokens, client credentials are for confidential clients, OIDC Authorization Code flow keeps tokens off the user agent and uses ID Tokens for identity, and OIDC requests require the openid scope if you want OIDC semantics. mTLS can be used for client authentication and/or certificate-bound access tokens.

Token lifecycle, scopes, and rate limits

I recommend the following starting token model:

Recommended plugin scopes:

• toa.read
• toa.memory.query
• toa.graph.read
• toa.change_request.create
• toa.change_request.review
• toa.anchor.apply
• toa.action.run
• toa.webhook.manage
• toa.audit.read
• toa.backup.export
• toa.backup.restore
• toa.admin

Recommended starting rate limits:

These numbers are recommendations, not spec requirements. The key spec-backed rules are that bearer tokens should be short-lived, scoped, and not sent in URLs, and that revocation and introspection should exist for serious integrations. Introspection should return an active boolean at minimum.

Webhook design

Outbound webhooks should be first-class because they are the cleanest way to notify agents about:

• change_request.created
• change_request.reviewed
• anchor.updated
• action_run.state_changed
• integrity_check.failed
• backup.created

Recommended webhook envelope:

{
  "event_id": "evt_01JZ9P7W9Y8K0ZZZZZZZZZZZZZ",
  "event_type": "anchor.updated",
  "occurred_at_utc": "2026-06-08T10:14:22Z",
  "site_id": 1,
  "object": {
    "type": "anchor",
    "id": 12,
    "anchor_type": "taboo",
    "version_id": 44
  },
  "correlation_id": "corr_25df2d15f2d74e2f"
}

Recommended delivery rules:

• sign each request with HMAC SHA-256 on raw body plus timestamp
• include Idempotency-Key and X-TOA-Signature
• retry with exponential backoff
• persist every attempt in toa_webhook_delivery
• support replay from a bounded retention window
• redact sensitive payload fragments from non-admin views

That is a design recommendation rather than a WordPress or OAuth requirement, but it fits the plugin’s auditability goals and OpenAI’s surfaced webhook-centric integration paths.

Common interaction flows

sequenceDiagram
    participant Agent
    participant API as TOA REST API
    participant Policy as Policy Enforcer
    participant Queue as Change Request Queue
    participant Reviewer
    participant Anchor as Anchor Store
    participant Hook as Webhook Dispatcher

    Agent->>API: POST /toa/v1/change-requests
    API->>Policy: Validate auth, scope, capability, target anchor
    Policy-->>API: request_only allowed
    API->>Queue: Create pending request
    API-->>Agent: 202 Accepted + request_id

    Reviewer->>Queue: Review request
    alt approved
        Queue->>Anchor: Create anchor_version + apply
        Anchor-->>Queue: New version + checksum
        Queue->>Hook: Emit anchor.updated
        Hook-->>Agent: Webhook callback
    else rejected
        Queue-->>Agent: change_request.reviewed rejected
    end

The flow above is the direct translation of UAIX’s “talk back instead of mutate” model into WordPress plugin behavior.

sequenceDiagram
    participant Agent
    participant API as TOA REST API
    participant Policy as Policy Enforcer
    participant Graph as Memory Graph
    participant Run as Action Runner
    participant Queue as Change Request Queue

    Agent->>API: POST /toa/v1/memory/query
    API->>Policy: Check toa.memory.query scope
    Policy-->>API: Allowed
    API->>Graph: Search nodes/edges
    Graph-->>API: Result set
    API-->>Agent: 200 Memory results

    Agent->>API: POST /toa/v1/actions/run
    API->>Policy: Check action against talisman/totem/taboo
    alt action allowed
        API->>Run: Execute action
        Run-->>API: Result
        API-->>Agent: 200 or 202 Run accepted
    else blocked by protected anchor
        API->>Queue: Create talk-back request
        API-->>Agent: 409 noop_blocked + change_request_id
    end

This second flow is the most important operational safeguard for remote agents: actions may execute, but protected-anchor conflicts should become no-op plus request, not “best effort mutation.”

Sample REST endpoints

All of these should be registered through register_rest_route() on rest_api_init, with explicit permission callbacks and schema-based argument handling.

Sample API payloads

Create protected-anchor change request

POST /wp-json/toa/v1/change-requests
{
  "target_anchor_id": 12,
  "target_anchor_type": "taboo",
  "blocked_action": "Allow agent to apply anchor mutation directly.",
  "requested_change": "Clarify that direct mutation remains forbidden but reviewer may approve a new exception process for staging-only imports.",
  "risk_level": "high",
  "evidence": {
    "anchor_conflict": "Current taboo blocks all autonomous protected-anchor mutation.",
    "risk": "Direct agent mutation would violate talisman semantics.",
    "rollback_impact": "If approved change causes unsafe loosening, revert to version 43 immediately."
  },
  "source": {
    "agent_app_id": 7,
    "action_run_id": 221
  }
}

Response

{
  "request_id": 104,
  "status": "pending_review",
  "no_op_performed": true,
  "next_allowed_actions": ["query_memory", "await_review"]
}

Query memory

POST /wp-json/toa/v1/memory/query
{
  "query": "Find all memory nodes related to webhook signing and protected-anchor review",
  "filters": {
    "node_types": ["policy", "action", "artifact"],
    "anchor_types": ["talisman", "taboo"],
    "limit": 25
  },
  "include_graph": true
}

Run action

POST /wp-json/toa/v1/actions/run
{
  "action": "reindex_graph",
  "arguments": {
    "site_id": 1,
    "scope": "protected_anchors"
  },
  "dry_run": false,
  "idempotency_key": "7d2392de-7f09-4cfd-8844-ec6d1c2a5e34"
}

Blocked action response

{
  "run_id": 221,
  "state": "noop_blocked",
  "blocked_by": {
    "anchor_type": "taboo",
    "anchor_id": 12
  },
  "change_request_id": 104,
  "message": "Protected anchor conflict. No-op performed and review request created."
}

Developer Surface and Sample APIs

The developer surface should be intentionally simple and boring. I would publish three things:

• a stable OpenAPI spec for toa/v1
• a portable UAIX export bundle generator
• small typed SDKs generated from the OpenAPI spec plus a webhook verifier utility

That gives Teleodynamic the broadest interoperability story: WordPress-native admin usage, external API usage, and agent-runtime seeding through .uai artifacts. The UAIX/OpenAI handoff guide is especially relevant here because it argues for durable project memory in repo-local files like AGENTS.md and .uai/* even when OpenAI or Codex handles the active run. Talisman of Admin should therefore support an “Export Handoff Bundle” action that writes or downloads:

• AGENTS.md
• .uai/context.uai
• .uai/constraints.uai
• .uai/progress.uai
• .uai/test-plan.uai
• .uai/totem.uai
• .uai/taboo.uai
• .uai/talisman.uai when protected-anchor mode is enabled

I would suggest these packages:

PHP example

<?php

declare(strict_types=1);

use GuzzleHttp\Client;

$client = new Client([
    'base_uri' => 'https://teleodynamic.com/wp-json/toa/v1/',
    'timeout'  => 15,
]);

$token = getenv('TOA_ACCESS_TOKEN');

/**
 * Query the Talisman of Admin memory graph.
 */
$response = $client->post('memory/query', [
    'headers' => [
        'Authorization' => 'Bearer ' . $token,
        'Accept'        => 'application/json',
    ],
    'json' => [
        'query' => 'Find all taboo edges related to webhook replay policy',
        'filters' => [
            'node_types' => ['policy', 'artifact'],
            'limit'      => 10,
        ],
        'include_graph' => true,
    ],
]);

echo $response->getBody()->getContents();

JavaScript example

/**
 * Create a protected-anchor change request using the TOA REST API.
 */
async function createChangeRequest(accessToken) {
  const response = await fetch("https://teleodynamic.com/wp-json/toa/v1/change-requests", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "Authorization": `Bearer ${accessToken}`
    },
    body: JSON.stringify({
      target_anchor_id: 12,
      target_anchor_type: "taboo",
      blocked_action: "Direct protected-anchor mutation",
      requested_change: "Request reviewer clarification for staging-only exception handling.",
      risk_level: "high",
      evidence: {
        anchor_conflict: "taboo forbids autonomous mutation",
        risk: "Applying change without review would violate talisman policy",
        rollback_impact: "Rollback to prior taboo version if unsafe loosening occurs"
      }
    })
  });

  if (!response.ok) {
    throw new Error(`TOA request failed: ${response.status}`);
  }

  return response.json();
}

Python example

import os
import requests

BASE_URL = "https://teleodynamic.com/wp-json/toa/v1"
TOKEN = os.environ["TOA_ACCESS_TOKEN"]

headers = {
    "Authorization": f"Bearer {TOKEN}",
    "Accept": "application/json",
    "Content-Type": "application/json",
}

payload = {
    "action": "reindex_graph",
    "arguments": {
        "site_id": 1,
        "scope": "protected_anchors",
    },
    "dry_run": False,
    "idempotency_key": "fc5f3af7-8d7f-4c0d-9d63-7f4f8fd08f02",
}

response = requests.post(f"{BASE_URL}/actions/run", headers=headers, json=payload, timeout=15)
response.raise_for_status()

print(response.json())

Suggested internal plugin API

Even though the public surface should be REST-first, the internal PHP API should remain strongly separated from transport concerns. I would define service interfaces roughly like this:

interface AnchorRepositoryInterface {}
interface AnchorVersionRepositoryInterface {}
interface ChangeRequestServiceInterface {}
interface PolicyEnforcerInterface {}
interface MemoryGraphServiceInterface {}
interface ActionRunServiceInterface {}
interface AuditLoggerInterface {}
interface AgentAuthServiceInterface {}
interface BackupServiceInterface {}
interface WebhookDispatcherInterface {}

That makes it practical to add:

• a WP-CLI surface later
• a sidecar protocol bridge
• full test doubles for policy, storage, and webhook behavior
• optional network-mode services on multisite

Operations, Compatibility, and Compliance

Testing, CI/CD, and deployment checklist

This plugin should be treated like a governance system, not just a content plugin. That means the test strategy needs to prove both functional correctness and boundary preservation.

Recommended deployment checklist:

The WordPress basis for the deployment mechanics is straightforward: use activation hooks for setup, version checks after update, deactivation only for transient cleanup, uninstall for permanent data removal, and staged database export/import for disaster recovery.

Migration and compatibility considerations

WordPress compatibility considerations are mostly about features, not branding:

• If you want core Application Passwords, you need WordPress 5.6+.
• If you want built-in privacy exporter/eraser integration, you need 4.9.6+.
• For modern REST-first admin UX, target current maintained WordPress branches and test both classic admin and block-editor enabled environments.

For multisite, WordPress documents that each site has its own tables while users are shared, and core provides is_multisite() and switch_to_blog() for cross-site operations. My recommendation is:

• Default v1 mode: per-site isolation, using site-prefixed tables and site-local settings.
• Network dashboard: aggregate via switch_to_blog() for read-only summaries.
• Network governance mode: roadmap item, not day-one default, because centralized write paths across sites substantially increase review and migration complexity.

For settings storage, use per-site options by default and site options (_site_ variants / wp_sitemeta) only for truly network-wide policy. WordPress explicitly distinguishes these storage paths in multisite.

Performance, scaling, and monitoring

The main performance risks are predictable:

• graph traversal and visualization payloads
• audit-log growth
• action-run history growth
• webhook retry storms
• expensive network aggregation on multisite
• backup generation on shared hosting

To keep the plugin fast, I recommend these operational defaults:

Monitoring should include:

• anchor integrity failures
• unusual no-op spikes
• repeated taboo-loosening requests
• queue age for pending reviews
• webhook dead-letter counts
• token revoke/expiry anomalies
• backup freshness
• migration result state

UAIX itself identifies repeated no-op events and repeated requests to loosen taboo.uai as signals worth attention. WordPress also warns that WP-Cron is page-load-driven and can drift, which is exactly why critical maintenance should not depend on traffic patterns alone.

Privacy and compliance notes

This plugin will almost certainly process some form of personal data, even if the primary payload is “AI memory,” because audit logs, application metadata, reviewer identities, IP history, webhook destinations, and exported evidence can all become personal data in context. WordPress’s privacy guidance is directly relevant here: plugins should integrate with personal data export and erasure tools and should suggest text for the site privacy policy.

Recommended privacy posture:

For GDPR-style compliance, the plugin should:

• register a personal data exporter callback
• register a personal data eraser/anonymizer callback
• document what is retained and why
• expose retention configuration in admin
• support data minimization per table and field
• separate necessary governance records from optional verbose traces

One subtle but important point: some records should be anonymized rather than deleted if they are needed to preserve system integrity or security for other users. WordPress’s eraser guidance is explicitly about erasing or anonymizing personal data, not necessarily deleting every related system artifact.

Roadmap, Effort, Risks, and Open Questions

Implementation roadmap

Principal risks

The largest architectural risk is trying to make WordPress itself the complete identity provider, OAuth authorization server, OpenID provider, WebSocket broker, graph engine, and durable memory authority all at once. It can be done, but the complexity cost is high. A better pattern is:

• WordPress plugin as the control plane and canonical policy UI
• external IdP or auth gateway for serious OAuth/OIDC
• optional sidecar for WebSocket/gRPC
• optional repo-local .uai bundle for durable cross-runtime memory

The largest governance risk is accidentally exposing a direct protected-anchor mutation path to remote agents. That would violate the core Talisman invariant and reduce the plugin to a normal admin tool with better marketing. Protected-anchor changes must remain request/review/apply, not request/apply.

The largest operational risk is inadequate review ownership. UAIX is explicit that talisman mode requires named reviewer paths, audit records, rollback evidence, and no-op tolerance. If Teleodynamic cannot commit to that operating model, the right answer is to use ordinary memory-mode features and stop short of full talisman mode.

Open questions and limitations

A few design decisions remain materially important and should be resolved before implementation starts:

My highest-confidence recommendation is to start with site-local governance, REST-first APIs, request-only agent mutation for protected anchors, an external IdP for serious OAuth/OIDC, and a portable handoff export path. That combination is the cleanest match to UAIX’s talisman boundary, WordPress’s plugin architecture, and current AI-agent integration realities.