Architectural Blueprint for the Teleodynamic Talisman WordPress Plugin and ChatGPT Integration Framework

Full report

On this page

Introduction to the Ecosystem and Architectural Objectives

The integration of advanced artificial intelligence agents, such as ChatGPT Plus, into structured, resource-bounded web ecosystems represents a profound engineering and philosophical challenge. The requirement to deploy a WordPress administration plugin designed to manage the Talisman system of the UAIX framework necessitates a rigorous architectural design that prevents autonomous overreach while maintaining absolute ontological integrity. The Teleodynamic ecosystem, which serves as the philosophical fulcrum, establishes a strict paradigm for constraint-maintaining intelligence.1 Within this paradigm, the Talisman system acts as a foundational governance anchor, dictating precisely how AI agents interact with, interpret, and request modifications to ecosystem constraints.3 The deployment of this plugin—while simultaneously exposing secure, read-only and highly constrained write-request external interfaces for AI agents—demands a synthesis of advanced content management system architecture, secure API endpoint engineering, and unyielding adherence to teleodynamic theoretical principles.4 This exhaustive architectural specification details the design, deployment, and lifecycle management of the Teleodynamic Talisman WordPress plugin. The specification encompasses the theoretical underpinnings of resource-bounded AI systems, the structural requirements of the Talisman Totem and Taboo models, the precise engineering of custom WordPress REST API routes, and the creation of an OpenAPI 3.0-compliant communication bridge for ChatGPT Custom Actions.6 Furthermore, the analysis heavily details the deployment of the Reconciliation Closure Dashboard for human maintainers, ensuring that AI-driven requests remain firmly governed by strict human-in-the-loop review gates and explicit claim boundaries.1 The fundamental tension addressed in this architecture is the user requirement for an AI agent to "manage the ecosystem" juxtaposed against the strict Teleodynamic prohibition of runtime agent control.2 The architecture resolves this by defining "management" not as direct database mutation by the AI, but rather as the AI’s ability to submit structured proposals via a UAIX-compliant Talkback protocol.8 This ensures the ecosystem evolves adaptively without ever sacrificing its resource-bounded integrity or collapsing into uncontrolled morphodynamic drift.8

Deconstructing the Talisman System and Ecosystem Memory

The core utility of the WordPress plugin is the governance of the Talisman system. A Talisman within the UAIX interoperability standard acts as a high-meaning, high-change-bar governance anchor for resource-bounded AI handoffs.3 Long-running AI handoffs inevitably degrade when they rely exclusively on volatile task memory or raw contextual windows; therefore, the Talisman provides an immutable, source-controlled continuity layer that actively preserves agent identity, lane boundaries, and operational constraints.3 While the specific URL detailing the UAIX Talisman system architecture (https://uaix.org/en-us/ai-memory/talisman-system/) is currently inaccessible, the architectural equivalent is exhaustively defined within the Teleodynamic framework and its interaction with the UAIX interoperability standard.2 The plugin must construct its data models based on the Teleodynamic-UAIX Boundary Map, which strictly delineates authority across the federated network.2

Authority Lanes and Claim Boundaries

A critical requirement of the plugin design is the enforcement of source-routed ecosystem boundaries.2 The WordPress plugin will bridge several distinct conceptual domains, and its database architecture must explicitly flag the origin and authority limit of every data object. The following authority boundaries must be strictly programmed into the plugin's schema validation logic:

The WordPress plugin must adhere to a strict "no-overclaim" policy.2 The system architecture must programmatically prevent any API responses, admin dashboard notifications, or generated JSON payloads from claiming runtime AI behavior control, biological equivalence, safety certification, or hidden subjective consciousness.1

The Totem and Taboo Binary

To manage memory effectively, the Talisman is split into two complementary surfaces that the WordPress plugin must model as distinct, highly structured data entities. The Totem represents a positive attractor.3 It explicitly communicates to an incoming AI agent what the specific ecosystem or sub-project is actively attempting to preserve, grow, or accomplish.3 In the WordPress database schema, Totem entries will contain positive commitments, structural goals, bounded semantic definitions, and alignment metrics.6 Conversely, the Taboo represents a negative perimeter.3 It serves as a strict boundary definition that instructs the agent on what must not be widened, executed, proposed, or claimed without prior human review.3 The Taboo schemas encode explicit prohibitions, ensuring that the AI agent respects the predefined teleodynamic boundaries and avoids actions that would drain system resources or violate compliance rules.

The Talisman Fulcrum Source and Agent Indexing

The plugin must serve as the Talisman Fulcrum Source, the canonical, per-agent repository for Totem and Taboo logic.1 This source programmatically governs the receiver lock policy, dictating how and when receiver sites or AI agents can ingest updated constraints, and determines source priority for conflicting rules when multiple agents interact.1 To systematically manage multiple AI agents interacting with the ecosystem via the API, the plugin must generate and continually update the Talisman Agent Index JSON.1 This machine-readable catalog maps out the canonical paths for each specific talisman assigned to different agents across the network.1 The architecture necessitates a dedicated WordPress background process to regenerate this static JSON file whenever a human maintainer approves a change to an agent's Talisman configuration, ensuring that querying agents always receive the most up-to-date governance parameters.

Theoretical Foundations of Resource-Bounded Management

To architect a successful integration between an external Large Language Model and the WordPress Talisman plugin, the system design must firmly encode the theoretical boundaries of Teleodynamic AI. The framework is inherently hostile to unchecked generative autonomy; it functions exclusively as an engineering lens for resource-bounded, self-maintaining systems where structure, parameters, and resource budgets co-evolve under highly explicit, mathematically modeled constraints.9

The Deacon-Style Dynamical Hierarchy

The architecture must enforce a conceptual hierarchy of computational patterns, translating these directly into the logic of the WordPress plugin's state management and caching mechanisms. This hierarchy is derived from the theoretical synthesis of far-from-equilibrium thermodynamics and complex systems biology, applied practically to machine learning architectures.9

If the WordPress plugin allows an AI agent to freely mutate database state without tracking resource costs or verifying constraints, the system violates the highest tier of the hierarchy.9 Consequently, the plugin architecture must strictly separate public meaning interpretation from internal mutation layers. AI agents are permitted to read public symbols and submit highly structured Talkback requests, but they are architecturally severed from directly executing UPDATE or INSERT commands on the canonical database tables storing the Talisman rules.8

Turney Model-S and Symbiogenesis in Software

The architecture is further grounded in the Turney Model-S symbiogenesis framework, which asserts that major improvements in system robustness require the synergistic fusion of distinct submodels rather than simple incremental parameter mutation.9 In the context of the WordPress plugin, the "Genome" is represented by source-controlled constraints, schemas, and traceable operating rules encoded in the PHP logic and custom tables.9 The "Phenome" is the observed behavior—rendered API outputs, route summaries, and human-review artifacts generated by the plugin.9 The concept of "Multicellularity" in this theoretical mapping is crucial: reviewed components, memory packets, endpoint sandboxes, and operator traces coordinate with one another without ever merging their distinct authorities.9 The WordPress plugin acts as the coordinating matrix, ensuring that a decision made by an AI agent (one cell) must be passed through a distinct structural review process (another cell) before it can influence the systemic "Genome."

CLOSET and the Semiotic Lens

All data modeled within the plugin must conform to the CLOSET framework (Culture, Language, Organization, Science, Economics, and Technology), which serves as a bounded semiotic lens.9 Symbolic structures proposed by AI agents are never treated as possessing hidden, innate meanings; rather, they are public, reviewable constraints.9 To remain in the active memory of the ecosystem, these symbolic structures must continuously earn their place by demonstrating evidence, ensuring algorithmic comprehension, and proving that their predictive utility outweighs their computational maintenance cost.9

Structuring Semantic Meaning: The Glyph Object Specification

A significant responsibility of the Talisman plugin is facilitating the communication of semantic rules and constraints to the AI agent. To achieve this without ambiguity, the system employs the Glyph Object Specification for Semantic Glyph Systems.4 This framework operationalizes the separation of a visible output from its internal evidence and canonical interpretation, ensuring that interpretation remains bounded, transparent, and reviewable.4 The core architectural principle here is that "one row is not enough".4 A standard database string or a simple key-value pair collapses complex meanings, removing the ability of a human maintainer to audit the evidence trail. The API must output constraint definitions to the AI agent utilizing a deeply structured four-layer model.4

The Four Layers of Data Transparency

JSON Schema Mapping and Internal-Only Status

When the WordPress API serves a constraint or rule to the ChatGPT agent, the response must conform to this specific structure. The structure layer ensures the AI comprehends the mechanical composition of a rule, while the embedding layer explicitly forces the AI to acknowledge the vector paths that lead to the canonical interpretation.4 A critical mechanism within this specification is the "internal-only" status restriction. If a data object within the plugin fails certain automated checks, it is designated as internal-only.4 This means the system can use the record for internal analysis, maintainer review, or model improvement, but the API will refuse to present it as a public semantic output or an enforceable rule for the AI.4 Triggers for this restriction include weak provenance (where the source family cannot be validated), excessive reliance on a single rendering profile, or ontology conflicts where a proposed gloss violates predefined relationship logic.4

WordPress Admin Plugin Architecture and State Management

The engineering of the WordPress plugin requires a rigorous separation of concerns, adhering to strict architectural patterns. The integration principle mandates that three layers remain completely separate: public website content, internal interpretation services, and the external Protocol5-style APIs accessed by ChatGPT.4 The public website acts merely to explain the model and allow users to inspect evidence; it must never become a mutation surface where public readers or external agents alter symbol registries, embedding stores, or source ontologies.4

Core Data Structures and Custom Post Types

To securely and natively manage Talisman data, the plugin will instantiate hidden Custom Post Types (CPTs) within the WordPress ecosystem. The primary CPT, talisman\_record, will utilize WordPress post meta to store the highly structured, four-layer JSON payloads required by the Glyph Object Specification. A secondary CPT, talisman\_talkback, will act as the ingestion queue for incoming requests from AI agents.4 By routing data through CPTs, the plugin inherits and leverages the native WordPress role and capability management framework. The architecture will define highly specific custom capabilities (e.g., edit\_teleodynamic\_talismans, review\_uaix\_talkbacks, approve\_canonical\_mutations) and assign them exclusively to administrator or specifically designated maintainer roles.11 This architectural decision ensures that unauthorized users—and explicitly the external AI agents—cannot bypass the application logic to mutate the canonical records directly.

The Reconciliation Closure Dashboard

The epicenter of human-in-the-loop governance is the Public Reconciliation Closure Dashboard, a robust closure-management layer injected into the WordPress admin interface.1 This dashboard organizes unresolved findings, attachment references, public-safe review narratives, and root-static drift resolution steps following deployment cycles.1 The dashboard explicitly disclaims automated live deployment reviews, completed remediations, or completed issue closures until a human maintainer supplies verifiable evidence.1 To support complex enterprise accessibility standards, the administrative interface is hardened. All data tables generated by the plugin are outfitted with captions, ARIA labels, keyboard-readable wrappers, explicit row and column headers, and small-screen containment formatting.1 The dashboard categorizes pending AI requests, system drifts, and required human interventions into five distinct closure states, all of which default to a boolean status of Claims resolved: false until evidence is provided 1:

Evidence Attachment Index and Auditability Enforcement

To maintain the fundamental teleodynamic principle of absolute auditability, the WordPress plugin enforces a stringent Evidence Attachment Index.1 When an AI agent submits a Talkback request proposing a new ecosystem constraint, the maintainer cannot simply click an "approve" button. The plugin's application logic keeps all closure fields disabled until the maintainer uploads, links, or writes specific evidence references.1 The required evidence schema includes multiple vectors of validation. If visual changes are proposed, screenshot evidence must be supplied, requiring metadata such as the target route, viewport dimensions, file name, and UTC capture time.1 Reviewer notes must detail the summary of the review alongside an explicit assessment of remaining open risks.1 When API parity or schema changes are involved, the maintainer must supply JSON parse outputs, root-static comparison notes, and .uai export parity documentation.1 By forcing the attachment of this evidence, the plugin ensures that an independent third party can reconstruct exactly why a representation was added or retired, satisfying the final phase of the teleodynamic roadmap.12

Root-Static Drift Resolution Engine

A unique feature of this plugin is its responsibility for monitoring the WordPress document root for drift between deployed static files and canonical teleodynamic packages.1 The dashboard contains a Root-Static Drift Resolution Map that guides maintainers through resolving mismatches in critical discovery files, ensuring the ecosystem's public footprint remains mathematically aligned with its internal database.1

The UAIX Talkback Request and Response Lifecycle

Because the fundamental invariant of the system is that AI agents cannot directly execute write commands on canonical Totem or Taboo files, the system facilitates all agent-driven ecosystem management through the UAIX Talkback protocol.8 This static-first route allows receiver sites and AI agents to request clarifications or propose changes without mutating local files, leaving a structured request note for human and teleodynamic review.8 The WordPress plugin must rigorously manage the state machine for these requests. Every incoming POST request must progress through a highly standardized twelve-step lifecycle encoded into the plugin's database 8:

1. Draft
2. Submitted
3. Received
4. Under-review
5. Needs-more-detail
6. Accepted-for-next-talisman
7. Accepted-with-revision
8. Rejected-boundary-conflict
9. Deferred
10. Superseded
11. Local-only-note
12. Closed-without-canonical-change 8

Talkback Operational Intents

AI agents must categorize their submissions under specific operational intents. The plugin's routing logic will reject any payload that does not match one of the predefined UAIX requestKind strings.8 The allowed intents are heavily biased towards boundary maintenance rather than generative expansion. Agents can submit a totem-addition-request, totem-removal-request, or totem-clarification-request to propose modifications to the positive attractors.8 For negative perimeters, they may submit a taboo-addition-request, taboo-removal-request, taboo-narrowing-request, or taboo-clarification-request.8 Crucially, the protocol supports conflict resolution through boundary-conflict-notice, local-safety-hold-notice, implementation-question, no-op-justification, and source-priority-question intents.8

Talkback Request Schema Validation

When the AI agent submits a Talkback, the payload must perfectly match the Request Schema. The plugin utilizes PHP's data sanitization functions to validate every field.8 Required fields include protocol tracking (uaixMessageType, messageId), temporal ordering (createdAtUtc), origin identification (fromSite, fromSiteSlug), and target linkage (targetTalisman, targetAnchor).8 The most critical validation occurs regarding the boolean boundary flags.8 The agent must declare the status of publicSafe, evidenceSupplied, localAutonomyPreserved, commandAuthorityClaimed, runtimeControlClaimed, safetyCertificationClaimed, and closureClaimed.8 If the incoming request sets runtimeControlClaimed or safetyCertificationClaimed to true, the plugin's API must immediately reject the payload with a 422 Unprocessable Entity response, as this violates the core Teleodynamic prohibition against autonomous runtime command.2 Finally, the agent must supply narrative and structural justifications in the fields for triggeringContext, teleodynamicTrace, noOpJustification, proposedMutation, requestedAction, and publicSafeSummary.8

Talkback Response Schema Engineering

Following the human review via the Reconciliation Dashboard, the plugin prepares a response based on the Talkback Response Schema. This payload is stored for asynchronous retrieval by the AI agent.8 The response contains the outcome of the review (decision), detailed analysis of the impact (canonicalEffect), and arrays detailing exactly which elements were accepted (acceptedTotemEntries, acceptedTabooEntries) and which were rejected (rejectedEntries).8 The response also explicitly returns receiverInstruction and noOverclaimBoundaries directives to constantly reinforce the systemic constraints upon the agent.8

Exposing the Ecosystem to ChatGPT Plus: REST API and OpenAPI 3.0

The technical integration allowing an AI agent like ChatGPT Plus to interface with the Talisman ecosystem relies entirely on custom WordPress REST API endpoints.5 The API acts as the secure bridge, exposing read-only governance data and a tightly controlled ingress queue for Talkback requests.4

REST API Endpoint Registration and Namespace Isolation

The plugin will register a unique namespace, talisman/v1, during the rest\_api\_init action hook to encapsulate all ecosystem operations cleanly.13 The architecture defines three primary endpoints:

1. Agent Index Endpoint (GET /talisman/v1/agent-index): Returns the machine-readable Talisman Agent Index JSON, mapping canonical paths.1
2. Talisman Verification Endpoint (GET /talisman/v1/verify/(?P\<agent\_id\>\\w+)): Allows specific agents to query their assigned Totem and Taboo rulesets, formatted according to the Glyph Object Specification.4
3. Talkback Submission Endpoint (POST /talisman/v1/talkback): Designed strictly to accept UAIX schema-compliant request notes.8

Advanced Authentication and Permission Callbacks

Security is the paramount concern. Since WordPress version 5.5, the REST API infrastructure strictly requires a permission\_callback argument when registering routes; omitting this triggers a persistent \_doing\_it\_wrong architectural notice and poses severe security risks.15 For read-only discovery routes intended for public consumption (like the Agent Index), the plugin implements the built-in \_\_return\_true callback, allowing unauthenticated requests while still fulfilling the API requirement.15 However, the Talkback Submission endpoint enforces rigorous authentication. The permission\_callback for the POST route executes a custom PHP function that intercepts the incoming request context, verifies authorization headers, and checks the user entity against specific WordPress capabilities (e.g., current\_user\_can('submit\_uaix\_talkback')).11 Unauthorized attempts are immediately rejected with a 403 Forbidden response.11

AI Authentication via Application Passwords

To facilitate the connection from ChatGPT Plus, the system relies on WordPress Application Passwords rather than traditional cookie-based nonces or complex OAuth2 handshake flows that are difficult for static LLM configurations to maintain.18 This method mitigates the security risks of hard-coding administrative login credentials and provides a mechanism for human maintainers to instantly revoke AI access from the WordPress user profile screen in the event of anomalous behavior.19 The integration flow requires the generation of a 24-character Application Password bound to a dedicated WordPress user account provisioned exclusively for the AI agent.19 To authenticate, the username and application password are concatenated with a colon and encoded into a Base64 string.18 The ChatGPT Custom Action is configured to attach this encoded string to the Authorization header as a Basic token for every request directed to the talisman/v1 namespace.19 The WordPress REST API natively intercepts this header, validates the Application Password without establishing a persistent cookie session, and temporarily authenticates the context, allowing the permission\_callback to accurately assess the agent's capabilities.11

Defining the OpenAPI 3.0 Specification

For ChatGPT Plus to understand how to interact with the WordPress API, the developer must provide an OpenAPI 3.0 specification file (YAML or JSON) defining the capabilities, constraints, and data structures of the custom action.7 This specification acts as the cognitive map for the LLM, translating natural language intent into precise HTTP operations.23 The OpenAPI schema must be strictly compliant with the subset of features supported by OpenAI. Notably, the specification must omit unsupported schema features such as the enum field for restricting parameter values; instead, developers must explicitly describe allowed categorical values within the parameter's text description strings to guide the LLM's generation.23 The schema begins by defining the target server URL pointing to the WordPress domain, followed by precise path definitions.24 For the GET request to retrieve Talisman rules, the schema defines the /wp-json/talisman/v1/verify/{agent\_id} path, assigning an operationId such as verifyTalismanRules.8 The parameters array designates agent\_id as a required string.24 Crucially, the POST path definition for /wp-json/talisman/v1/talkback must meticulously define the requestBody.7 The schema must mandate that the application/json payload conforms exactly to the Talkback Request Schema.8 Every property—from uaixMessageType to proposedMutation—must be typed correctly. The text descriptions attached to the boolean boundary flags within the YAML file must contain explicit prompt instructions warning the AI that setting fields like runtimeControlClaimed to true will result in immediate rejection.8 This tight coupling of API enforcement and OpenAPI prompting ensures the agent remains aligned before the network request is even dispatched.

Implementation Roadmap and Evaluative Gates

The deployment of the Talisman WordPress plugin must strictly adhere to the Teleodynamic Architecture Improvement Roadmap.12 This ensures the system is built incrementally and safely, enforcing the principle that a prototype is not considered teleodynamic until its split, merge, add, retire, and no-op decisions are resource-gated, locally justified, appended to immutable logs, and highly visible in phase plots.12

The Six-Phase Rollout Strategy

The engineering effort progresses through six defined phases, building the smallest viable substrate first rather than initiating deployment with complex agent connectivity 12:

Systemic Verification and Quality Assurance Gates

Before any live API connection is granted to ChatGPT Plus, the system must pass a series of rigorous validation gates defined within the Evaluation Lab framework.4 These gates guarantee that the plugin is not merely functioning mechanically, but is enforcing semantic and ontological constraints: The public output gate requires that any data presented by the API is an assigned character or valid public sequence; failures mandate returning an unresolved status.4 The ontology gate checks that candidate Talkback requests obey type and relation constraints, downgrading confidence scores upon failure.4 The evidence gate ensures that internal retrieval lanes do not contradict each other.4 Crucially, the resource closure gate requires that the internal metric tracking [Figure omitted from source export] can pay the action cost of the API request; if the system is overloaded, the API must block the action or force a no-op response.4 Finally, the auditability gate requires that a reviewer must be able to fully reconstruct the decision tree; if this fails, the entire interpretability claim of the deployment is rejected.4 Through this exhaustive architectural synthesis of WordPress capability management, rigorous REST API security, UAIX Talkback protocols, and foundational teleodynamic theory, the resulting system successfully allows an AI agent to interface with and propose management actions for an ecosystem, while remaining absolutely constrained by human oversight, resource closure, and immutable ontological boundaries.

Works cited

1. Reconciliation Closure Dashboard and Root-Static Drift Resolution | Teleodynamic.com, accessed June 8, 2026, https://teleodynamic.com/ecosystem-personality-and-cognitive-liberty-reconciliation-closure/
2. Teleodynamic-UAIX Boundary Map, accessed June 8, 2026, https://teleodynamic.com/teleodynamic-uaix-boundary-map/
3. Teleodynamic Governance Anchors, accessed June 8, 2026, https://teleodynamic.com/teleodynamic-governance-anchors/
4. Developer Integration Guide for Interpretable AI Architecture, accessed June 8, 2026, https://teleodynamic.com/developer-integration/
5. register\_rest\_route() – Function \- WordPress Developer Resources, accessed June 8, 2026, https://developer.wordpress.org/reference/functions/register\_rest\_route/
6. Cognitive Liberty and the AI Declaration | Teleodynamic.com, accessed June 8, 2026, https://teleodynamic.com/cognitive-liberty-and-ai-declaration/
7. openapi.yaml \- openai/plugins-quickstart \- GitHub, accessed June 8, 2026, https://github.com/openai/plugins-quickstart/blob/main/openapi.yaml
8. Talisman Talkback \- Teleodynamic AI, accessed June 8, 2026, https://teleodynamic.com/talisman-talkback/
9. Teleodynamic AI Summary for Machine Readers, accessed June 8, 2026, https://teleodynamic.com/ai-summary/
10. accessed December 31, 1969, https://uaix.org/en-us/ai-memory/talisman-system/
11. Make authorization mandatory on custom routes \- WordPress Stack Exchange, accessed June 8, 2026, https://wordpress.stackexchange.com/questions/338490/make-authorization-mandatory-on-custom-routes
12. Teleodynamic AI Roadmap for Self-Maintaining Systems, accessed June 8, 2026, https://teleodynamic.com/roadmap/
13. How to Add Custom REST API Route in WordPress? \- Webkul, accessed June 8, 2026, https://webkul.com/blog/add-custom-rest-api-route-wordpress/
14. Creating Custom REST API Endpoints in WordPress \- DEV Community, accessed June 8, 2026, https://dev.to/seanaus120/creating-custom-rest-api-endpoints-in-wordpress-4bnk
15. Adding Custom Endpoints – REST API Handbook \- WordPress Developer Resources, accessed June 8, 2026, https://developer.wordpress.org/rest-api/extending-the-rest-api/adding-custom-endpoints/
16. Specify \permission\_callback\ for custom post search REST route, accessed June 8, 2026, https://github.com/google/site-kit-wp/issues/1924
17. Proper use of permission\_callback in register\_rest\_route with JWT? \- Stack Overflow, accessed June 8, 2026, https://stackoverflow.com/questions/79627382/proper-use-of-permission-callback-in-register-rest-route-with-jwt
18. Build a Custom GPT That Creates and Searches WordPress Posts Using the REST API, accessed June 8, 2026, https://jonbishop.com/guides/build-a-chatgpt-custom-gpt-that-creates-and-searches-wordpress-posts-using-the-rest-api/
19. How to Authenticate WordPress with Application Passwords for ChatGPT | Kevin Dees, accessed June 8, 2026, https://kevdees.com/how-to-authenticate-wordpress-with-application-passwords-for-chatgpt
20. WordPress REST API application password authentication in Javascript \- risk?, accessed June 8, 2026, https://stackoverflow.com/questions/77995736/wordpress-rest-api-application-password-authentication-in-javascript-risk
21. Publish WordPress Drafts with Custom GPT \+ OpenAPI \- Juanlu, ElGuerre, accessed June 8, 2026, https://elguerre.com/2025/09/11/publish-wordpress-drafts-with-custom-gpt-openapi-2/
22. GPT Action authentication | OpenAI API, accessed June 8, 2026, https://developers.openai.com/api/docs/actions/authentication
23. Define OpenAPI schemas for your agent's action groups in Amazon Bedrock, accessed June 8, 2026, https://docs.aws.amazon.com/bedrock/latest/userguide/agents-api-schema.html
24. How to create a GPTs with actions | by Emma \- Medium, accessed June 8, 2026, https://medium.com/@aluotslan/how-to-create-a-gpts-with-actions-6216a4035724