Zia Developer AI Requirements

Consolidated introduction, product requirements, and engineering contracts

This document records official support for ChatGPT Work scheduled plugin execution, while retaining separate Zia integration qualification and explicit loop/graph enforcement responsibilities. The language decision remains: typed Python is the default for generated AI workers, while TypeScript remains the implementation language for Zia tooling. Part 1 covers product purpose, scope, user experience, milestones, and release decisions. Part 2 contains the detailed requirements, schema contracts, examples, capability evidence, and acceptance tests.

Part 1 states the product and release plan; Part 2 defines the matching engineering contracts. Future-target requirements apply only to their assigned release. No section overrides a conflicting requirement; inconsistencies must be corrected before implementation. All requirement identifiers and the existing section labels are preserved.

The first worker built with Zia, the GIAIC/PIAIC/Panaversity AI Support pilot, has its own page: First Pilot. Product Section 6 below keeps the shared release path and points there for the pilot itself; the pilot-only requirements FR-J12 and FR-L5, the pilot tests P01 to P11, and acceptance criteria AC-40 to AC-42 are defined on that page.

Contents

Part 1 · Product purpose and requirements

• 1 Purpose
• Choosing automation, an assistant, or a Digital FTE
• 2 The specification model
• 3 What Zia produces
• Plugin-first selection and Routines
• Cowork and ChatGPT Work targets
• API-triggered workers
• MCP-callable workers
• 4 User experience
• 5 Release baseline and technology decisions
• Language decision and evidence
• 6 First end-to-end milestone
• 7 Product requirements
• 8 Quality and release decision
• 9 Boundaries and remaining decisions

Part 2 · Engineering contracts

• E1 Reading rules and release scope
• E2 Specification and build contracts
• E3 Composition and feasibility
• E4 Runtime and evaluation contracts
• E5 Functional requirements
• E6 Non-functional requirements
• E7 Capability evidence matrix
• E8 Development-host declarations
• E9 Versioning, locks, and approval integrity
• E10 Reference workers
• E11 Release acceptance
• E12 Source register
• E13 Traceability record

Part 1 Product purpose and requirements

1 Purpose

Zia Developer AI helps developers and domain specialists turn business problems into specified, tested, deployable AI workers. Its central purpose is to manufacture Digital FTEs: workers that perform recurring or continuous responsibilities under defined controls, with evaluation evidence and an operating owner.

Some problems call for conventional automation or an interactive assistant. Zia should identify that early and produce the appropriate recommendation or deliverable. An assistant is useful without being labeled a Digital FTE.

Zia Developer AI runs within a coding agent. Zia supplies the development method, reusable knowledge, specifications, and validation workflow. The host coding agent performs authorized implementation work. A developer and the assigned domain reviewers judge the result and release it.

Zia Tutor AI teaches the method. Zia Developer AI applies it to working software. Both draw on the Agent Factory knowledge System of Record.

Choosing the appropriate solution before building

The purpose of the early decision is to solve the customer’s problem with the least unnecessary complexity. A useful deliverable can be a conventional automation recommendation, a one-time playbook, an interactive assistant plugin, or a rostered AI worker. These are different operating arrangements, not a ladder of quality. The following examples are proposed product scenarios, not claims about completed deployments.

Conventional automation follows explicit rules over defined inputs. Formulas, validation scripts, scheduled reports, and application workflows often fit this category. AI may help write and test the code during development without being needed when the resulting program runs. Repetition and scheduling alone do not turn a program into an AI worker.

An interactive assistant helps a person perform a task. The person normally initiates the work, provides context, reviews the result, and decides what happens next. The assistant can use tools, execute multiple steps, create files, and perform authorized actions. It can be a reusable plugin with substantial business value. Its defining characteristic here is that it assists user-directed work rather than owning an assigned recurring responsibility.

A Digital FTE, in this specification, is an AI worker at the rostered-worker or autonomous-service level. It has an assigned responsibility, a defined trigger, persistent operating state where required, measurable acceptance criteria, an operating owner, and appropriate recovery and escalation. It can still require human approval for consequential actions. The label does not promise that one worker replaces one full-time employee or achieves a particular labor saving.

Question	Conventional automation	Interactive assistant	Digital FTE
What drives the work?	Explicit rules and defined transformations	A person’s request and ongoing judgment	An assigned recurring or continuous responsibility
Is model interpretation needed at runtime?	Usually no	Yes, where it helps the requested task	Yes, for the parts needing interpretation or adaptive decisions
Who initiates it?	A person, schedule, or event	Normally a person	A defined roster, event, queue, or other operating trigger
What does completion mean?	The rule-based job passes its checks	The requested assistance or artifact is delivered	The assigned operation reaches an accepted, blocked, escalated, or failed state
What should Zia produce?	A reasoned recommendation and implementation brief	A playbook or reusable assistant plugin	A worker spec, implementation, deployment configuration, and operating evidence

Example 1: Calculate an indirect rate

Request: “Each month, divide the approved indirect-cost pool by its approved allocation base and produce the rate table.”

If the inputs, mappings, exclusions, zero-base treatment, and rounding rules are already defined, this is primarily conventional automation. Tested arithmetic should perform the calculation. Scheduling the calculation monthly does not create a need for an LLM.

Zia should identify the supplied rules, document unresolved business choices, and recommend a spreadsheet formula, script, API operation, or existing calculation engine as appropriate. Its implementation brief should specify inputs, outputs, failure cases, and independent expected results. It must not invent accounting policy to fill gaps.

Change that could justify AI assistance: “Explain why the rate changed, using the underlying cost movements and approved management commentary.” Keep the rate calculation deterministic and add an assistant for evidence-based explanation. The whole calculation engine does not need to become an agent.

Example 2: Explain a project variance on demand

Request: “Here is this month’s project report. Explain the largest variances and help me prepare questions for the project manager.”

This fits an interactive assistant. The user starts the analysis, chooses the project and period, and reviews the explanation. Calculations should come from validated tools; the model connects the evidence, drafts explanations, and identifies missing information. If the report shows a cost increase but gives no cause, the assistant should distinguish the measured increase from possible explanations and questions to investigate.

For a one-time task, Zia can produce a Mode 1 playbook for the existing host. If the consultant wants the same reviewed workflow reusable across projects, Zia can manufacture a Mode 2 assistant plugin with input templates, tools, source requirements, and acceptance fixtures. Both remain assistant-level solutions. Reusability, plugin packaging, and a sophisticated execution graph do not by themselves make either a Digital FTE.

Example 3: Prepare the month-end reconciliation package

Request: “For every approved reporting period, collect the available inputs, reconcile them, prepare the exception report, and route the package to the accounting owner for approval.”

This fits a rostered AI worker when interpreting exceptions or preparing supported explanations requires AI. Its responsibility extends beyond one conversation. It records which period is being processed, waits or escalates when an input is missing, preserves progress, and tracks the package through review. Deterministic tools still own arithmetic and control totals.

The operating loop covers the trigger, input readiness, bounded retries, checker, stop conditions, approval, and completion. The execution graph might retrieve ledger and budget data in parallel, wait for both, calculate reconciliation, draft explanations, independently check them, and create a pending-review package. Publication requires the designated reviewer’s operation-bound approval. Duplicate attempts must not produce duplicate committed business effects.

Zia should generate the approved worker contract, plugin and tool bindings, qualified scheduler configuration, durable records, tests, and an operating handover. If the chosen host cannot enforce a requirement, Zia must report the gap or use an explicitly approved backing service. Calling this a Digital FTE never waives the human review requirement.

Example 4: A scheduled report is not automatically a Digital FTE

Request: “Email the same approved dashboard export every Monday.” If this involves a fixed query, template, recipient list, and delivery rule, recommend conventional automation. It may run unattended and have logs and retries without needing an AI worker.

Different request: “Every Monday, investigate unusual project movements, draft an evidence-based briefing, and track unresolved questions until the assigned owner responds.” This may justify a rostered AI worker because it combines recurring responsibility with interpretation and follow-through. Zia must establish thresholds, evidence, ownership, permissions, and escalation before manufacturing it.

Zia’s early decision and deliverable

1. Identify the outcome and evidence of success. Ask what the user needs produced or changed and how they will judge it.
2. Separate fixed rules from interpretation. Keep known calculations and checks in deterministic tools. A hybrid solution is valid.
3. Determine the operating responsibility. Distinguish help with a user-initiated task from a duty that must be performed and tracked over time.
4. Check the simplest sufficient existing capability. Reuse an approved application, tool, or host workflow where it meets the need.
5. Return a clear recommendation. State the chosen solution, why it fits, what Zia will deliver, required inputs and controls, and any named capability gaps. Cite the pinned method where the gate requires it.
6. Build only the appropriate artifact. Agent manufacturing is not the default response to every business request. Do not ask irrelevant agent-runtime questions when recommending a deterministic script.

In the current product scope, a conventional-automation result includes a recommendation and an implementation brief, with suggested acceptance cases and an explicit handoff to the development host. It does not silently add a general-purpose automation code generator to Zia’s supported output targets. If the user separately authorizes conventional implementation, the coding host may do that work under its normal workflow; it must not be reported as a certified Zia AI-worker target.

An assistant is therefore a successful outcome when the task calls for assistance. Its value should be measured through correctness, usefulness, time saved, and user acceptance. Adding a scheduler or labeling it a Digital FTE is unnecessary unless the operating responsibility actually changes. Promotion to a rostered worker requires a revised approved specification and evidence for the added controls; it is not a label change.

2 The specification model

The platform combines reusable engineering knowledge with domain and customer requirements.

Layer	Owner	Example for an accounting worker
Horizontal	GIAIC/PIAIC/Panaversity	Tool validation, safe retries, permission controls, specification schemas, evaluation methods
Vertical	Domain specialist or consultant	Reconciliation rules, calculation methods, accounting vocabulary, independent expected results
Customer	Client and consultant	Chart of accounts, reporting periods, access limits, data policies, system mappings
Project	Implementing developer	The specific worker, input/output contracts, selected workflow, and acceptance cases

The composer produces one resolved specification with source versions and field provenance. Required project fields may come from parent layers. Customer-free projects may extend a vertical or the horizontal package directly. Personal projects still record reviews and controls, with the developer filling the relevant reviewer roles.

MCP provides access to the book and specification packages. The underlying store owns persistence, versioning, and approvals. The book's explanatory text and its mandatory requirements must be distinguishable.

The generated worker's business System of Record is separate from this development knowledge. It may be an ERP or application database. Model memory or a vendor session must never be its sole authoritative business record. Run-state and business-state records may share infrastructure with separate ownership and access rules.

Agent Factory method and expert records

Zia is the reference domain builder in Layer 2 of the FDE Agent Factory Model. Vertical teams specialize its knowledge and constraints for a profession; customer projects supply the operating context. Zia Tutor teaches the method, while Zia Developer turns it into reviewed implementations. FDE AF Model

The 10–80–10 rhythm means intent, execution, and verification: the human owns the problem and approves the specification, Zia helps clarify and document it, the coding host performs the authorized build, and the human evaluates the evidence and decides whether to ship. The percentages express responsibility, not a promised effort split. This maps to intake/spec approval (FR-A, FR-B), controlled implementation (FR-D), and independent evaluation/handover (FR-E, FR-L). Zia Developer AI

The builder adapts the Expert Twin pattern through four governed records already required in FR-H1 to FR-H4:

Record	Purpose in Zia Developer AI	Required discipline
Knowledge	Horizontal method and vertical expertise	Pinned sources and provenance
Identity/Praxis	Expert judgment, decision order, and explanation style	Versioned method; representation of a real expert requires consent
Developer	Stated goals, preferences, and relevant experience	No inferred personal facts
Project	Decisions, specifications, builds, approvals, evaluations, and progress	Durable history and customer isolation

These are this product’s four records; they do not assert that every Tutor or Expert Twin implementation uses the same record count. Learners receive explanations and practice fixtures. Consultants receive domain traceability, customer controls, and reproducible handover. Both follow the same acceptance discipline.

Technical architecture at a glance

Five layers, with control flowing down and evidence flowing back up. Zia has no runtime of its own: it runs inside a coding agent, reads the method from a pinned System of Record, composes a specification that lower layers can only tighten, and hands the approved contract to a target adapter that scaffolds the worker. The worker's state and side effects live outside the model, in services the operating owner controls.

Layer	Contains	Talks to
Development host	Claude Code CLI or Codex CLI	Runs Zia as a plugin; performs authorized edits, shell work, and permission enforcement
Zia Developer AI	Decision gates, composer, schema validators, eval compiler, target adapters, fail-closed error codes (Group I)	Reads the System of Record over MCP; takes intake; emits the specification and evidence
Specification layers	Horizontal → vertical → customer → project; agent.spec.md, agent.resolved.json, build configuration, af.lock	Composed tighten-only (E3); approved before any build (FR-K1, FR-K7)
Generated worker	Claude Code plugin (1.0), Claude Managed Agents (1.1), OpenAI Agents SDK Python (1.2)	Acts only through owned MCP tools; reports traces, eval results, and cost back to Zia
Owned runtime services	Business system of record, operation ledger, approval records, enforcement service, channel gateway and case service	Enforce graph, loop, budgets, and approvals independently of model instructions (FR-J1 to FR-J9)

Direction	Content
Inputs	Plain-language problem statement; policies, schemas, approved sample or synthetic data (never production records, FR-A10); the pinned System of Record release and applicable vertical and customer packages; gate answers and approvals
Outputs, conventional automation	Recommendation and implementation brief; no agent scaffold (FR-A4)
Outputs, Mode 1	Cited playbook for an existing agent; no new runtime (FR-A9)
Outputs, Mode 2	agent.spec.md, resolved specification, approved build configuration, worker package with lockfiles, compiled eval suite with fixtures and rubrics, per-target trace and cost evidence, both data-handling statements, reproducible handover (FR-L1)

3 What Zia produces

Output form	Deliverable	Typical use
Plugin	Skills, tool declarations, and tested host-specific configuration	An interactive assistant or a rostered worker operating within a coding host
Process	A typed Python application by default, or a separately qualified TypeScript profile, using a supported agent SDK	An interactive API, a scheduled worker, or an event-driven service
Managed	Agent configuration and integrations on a supported managed runtime	A worker whose orchestration and environment use a vendor-managed platform

A target is a particular implementation within a form, such as openai-agents-sdk. A development host runs Zia, such as Codex CLI. A surface is a plugin that exposes an existing process or managed worker's tools and skills without duplicating its business logic.

The business specification describes behavior and constraints. A separately approved build configuration chooses the target, concrete models, infrastructure, secrets references, and surfaces. Moving a compatible worker changes deployment settings and target wiring while preserving business contracts and domain expectations. Each destination still needs its own operational evidence. If a move requires different business behavior or weaker controls, it is a specification change.

Default output selection and deployment

Zia’s first choice is to generate another plugin: a reusable AI worker that operates in a supported host. Select the simplest qualified output that satisfies the approved specification, in this preference order:

Preference	Output	Selection rule	Ease of use and testing
1 — default	Host plugin	Use the customer’s supported host for interactive work or qualified scheduled/event-triggered work. For Claude Code, prefer Routines for compatible unattended workloads.	Fast installation, demonstration, and customer acceptance testing; verify the actual host and deployment environment.
2	Claude Managed Agents	Choose when plugin execution cannot meet the specification and the managed service fits the customer’s provider, data, and operational constraints.	Reduces infrastructure work; requires cloud integration and recovery testing.
3	OpenAI Agents SDK	Choose for OpenAI requirements, custom application integration, hosting control, or specialized orchestration.	More application and deployment responsibility; strong control over isolated tests, mocks, and fault injection.

This is a suitability-based preference order, not a mandatory migration path or a ranking of framework quality. Explicit customer requirements override it. An OpenAI-only customer can go directly to OpenAI Agents SDK. A target must be released and qualified before Zia offers a build; a future target is shown as unavailable, with alternatives and their consequences. The release sequence follows this preference order. Claude Agent SDK is outside mandatory generated-output scope.

Plugin-first prioritizes time to a useful worker and low operating effort. It does not claim that plugins are universally easiest to test. Keep deterministic business calculations, tool contracts, and independent acceptance fixtures reusable across outputs; run host/runtime-specific operational tests separately. Skills and MCP improve reuse, but plugin manifests, host controls, and cloud scheduling remain platform-specific. Managed deployment increases dependence on vendor operations; SDK output offers more hosting control without automatically eliminating model or SDK dependencies.

A plugin may consist mainly of skills, instructions, manifests, and tool configuration. Generate executable code only where needed. Typed Python is the default for custom worker tools and business logic; TypeScript remains the Zia tooling language. Do not scaffold an entire SDK application merely to satisfy the language default.

Claude Code Routines as a plugin deployment profile

Routines can start Claude Code work on a schedule, through an API call, or from GitHub events, without an open laptop. This strengthens the case for plugins as reusable workers that can also operate unattended. Routines is a Claude Code execution option, distinct from the Claude Managed Agents target. Introducing Routines

Claude Code supports enabling plugins for cloud sessions through committed project settings, including enabledPlugins in .claude/settings.json; private or custom plugin sources also need resolvable marketplace configuration and authorized access. A local user-scoped installation does not automatically transfer. Plugin installation documentation, Catch security issues as Claude writes code

Zia shall support a qualified Claude Code plugin running through Routines. This combines documented cloud-plugin loading with Routines’ cloud execution; it is an integration design to test, not proof that every plugin component works unchanged. The blog itself does not explicitly promise universal plugin compatibility. Pin the plugin and verify its required skills, tools, dependencies, and controls in the actual routine environment before advertising support.

Current Routines documentation describes research-preview status, separate run sessions, account usage limits, and cloud-specific connector configuration. Local MCP configuration is not automatically available. A green run status alone does not establish business-task success. Use the current documentation for behavior rather than historical launch limits. Routines documentation

For example, an accounting plugin can reconcile approved inputs interactively, then run the same business contracts through a nightly routine to prepare an exception report. Publication or accounting writes retain their specified approval boundary. Scheduling alone does not supply exactly-once business effects, durable approvals, or an always-running service.

Routines deployment constraints

Routines supports Anthropic-managed execution and routing to an organization’s self-hosted environment. Record the actual route, environment, and execution location in E2.5; independently assess inference, session records, memory, logs, and business storage. Either route can satisfy a location policy only with matching evidence. Self-hosting is not evidence of complete data residency. Routines documentation

Before any protected operation, the runtime must prove all mandatory controls are active, including after a fresh installation, restart, or update. Until first-operation hook enforcement is verified for the exact host/profile version, mandatory Routines controls must bind to an owned enforcement tool or service. It must hold the protected credentials and deny bypass through direct connectors, shell access, or alternate tools. Test a forbidden operation before any allowed write; missing enforcement stops the run. This is a defensive qualification requirement, not a claim that all current first sessions lose hooks.

The scheduler profile must declare minimum recurrence interval, timing tolerance, account-wide available run capacity, shared workload commitments, retry/catch-up allowance, and approved overage behavior. The current documented recurring minimum is one hour. Reject a 15-minute recurring request. Check planned aggregate demand against available capacity before build approval; unknown constrained capacity blocks approval. At runtime, detect exhaustion and enforce the approved missed-run policy. API/GitHub triggers require their own limits and cannot be presented as a workaround for an unsupported schedule. Routines scheduling and limits

Claude Cowork and ChatGPT Work output targets

Zia shall generate AI-worker plugins for Claude Cowork and ChatGPT Work as planned additions to the plugin output family. Developers build with Zia in Claude Code or Codex; accountants and other professionals use the generated worker in their selected work environment. These destinations are not additional development hosts by implication.

Zia target identifier	Destination	Execution profiles	Qualification status
host-plugin/claude-code	Claude Code	Interactive, Routines, CI	Existing 1.0 commitment
host-plugin/claude-cowork	Claude Cowork	Interactive; Cowork scheduled tasks	Planned, Q-CW qualification required
host-plugin/chatgpt-work	ChatGPT Work	Interactive; web and desktop scheduled tasks	Platform scheduling documented; Zia Q-W integration tests pending

These identifiers are Zia’s internal build vocabulary, not vendor API names. The plugin family stays first in output preference. Among qualified plugin hosts, choose the customer’s requested environment and required capabilities; Claude Code remains the default when no destination is specified. Do not assume equivalent manifests, hooks, authentication, filesystem access, or scheduling across hosts.

Anthropic documents that Cowork scheduled tasks can use installed plugins, skills, and connected tools. Qualify the selected local or remote execution profile and its file access separately; do not promise access to a user’s local files from a remote run. Cowork scheduled tasks are distinct from Claude Code Routines. Cowork scheduling

OpenAI documents installable plugins containing skills and MCP servers, and lifecycle hooks for the runtime used by ChatGPT Work and Codex. Its builder guidance covers custom plugin creation and distribution. Scheduled plugin and skill execution is explicitly documented in OpenAI’s scheduled-task guide [38]. This establishes platform capability; it does not establish that Zia’s generated package passes its tool, permission, state, or enforcement tests. Skills & Plugins, Build plugins

ChatGPT Work scheduling verification — September 13, 2026: OpenAI documents that scheduled tasks created in Work on the web, or Work/Codex in the desktop app, can use plugins and skills. Web runs can access the chat’s available plugins, connected tools, and uploaded context. Name the intended skill explicitly in the saved task prompt. Web runs do not preserve a local folder or worktree; keep required material in accessible uploads, projects, or connected services. Desktop tasks requiring local files need the computer on and the application running. Scheduled tasks

Zia shall record the web or desktop profile, selected skill, required plugin/tool access, accessible inputs, and durable state location in the build configuration. Do not use transient local files as cross-run state for web tasks. Missing required inputs or revoked access must produce a clear failure. Qualification must inspect a real scheduled run, including skill activation and tool results. No live scheduled Zia-plugin run was performed for this documentation check. Status: scheduled plugin execution documented; Zia integration testing pending.

Loop engineering and graph engineering apply to workers on both destinations. The same approved domain specification, loop definition, graph definition, tool contracts, and business fixtures feed each target adapter. Simple interactive assistants need only the controls their job requires; rostered workers require durable state, bounded retries, appropriate triggers, independent checking, and approval/recovery behavior.

Implementation part	Responsibility
Plugin skills and resources	Describe the job, procedures, decision rules, expected results, and review experience
Qualified host capabilities	Provide interaction, tool execution, supported lifecycle events, and verified automation
Executable workflow controls	Enforce dependencies, resource access, calculations, durable checkpoints, approvals, and prevention of duplicate business effects

For bounded work, a tested runner may execute inside the host session. When the host cannot supply required durability or enforcement, a connected MCP service owns those responsibilities. Installing a plugin does not deploy its external services automatically. The deployment inventory must state where each component runs and who operates it.

A worker may expose tools such as start_reconciliation(period), get_run_status(run_id), get_pending_review(run_id), and publish_approved_report(run_id). These are illustrative Zia tool names. The publication service checks completed prerequisites, the authenticated reviewer’s decision, operation ID, input digest, and approval expiry. The model cannot manufacture approval or bypass checks through another connector, shell, or credential path. Duplicate attempts may occur; duplicate committed business effects must not.

A plugin is an execution target when it performs the worker workflow through host capabilities and tools. When it only presents an already deployed process or managed worker, classify it as a surface and record that backing target separately. A host-orchestrated worker with durable tool services has shared execution responsibility; describe that architecture explicitly rather than claiming the host supplies every guarantee.

Work-environment qualification milestones

Q-CW and Q-W are approved planned target additions, with release assignment pending qualification. They are not new unconditional 1.0 gates. Start qualification after the bounded M0 workflow works; keep the existing 1.0/1.1/1.2 commitments intact. Each target is advertised only after its applicable tests pass. Interactive qualification does not imply scheduled qualification.

For each added target, Claude Code and Codex must each generate and hand over the plugin. Destination evaluation may use a documented human-assisted installation and test procedure where no supported automated interface exists; record that limitation and the actual evidence. Each added target creates two additional host/target combinations, and every advertised local, remote, or scheduled profile adds its own operational test path. Do not conceal this work in the original two-combination count.

A Work plugin may eventually provide an OpenAI-only path before the SDK release, but claim it only after the complete host, model, tools, and service chain passes provider-policy tests without Anthropic credentials. The SDK’s 1.2 acceptance remains separate.

API-triggered workers and tool-call direction

An external application or another AI worker may need to start a worker programmatically. This is a separate capability from a worker calling an application’s API through MCP. Plugin installation, tool access, and scheduling do not automatically create an inbound worker endpoint.

Direction	Example	Required capability
Worker calls application	An accounting worker retrieves transactions through an MCP tool backed by the customer’s API	Authorized outbound tool access
Application calls worker	The accounting application requests a reconciliation after the period is ready	A qualified inbound trigger endpoint
Worker calls another worker	An authorized coordinator submits a task to a specialist	The caller’s tool access plus the recipient’s inbound trigger and completion contract

Destination	Inbound API evidence as of September 13, 2026	Zia treatment
Claude Cowork plugin	A general endpoint for invoking an arbitrary Cowork plugin was not verified	Do not advertise inbound API support; scheduled and interactive evidence remains separate
Claude Code Routines	Documented routine endpoint authenticated with a routine-specific bearer token [39]	Qualify as a Routines API-trigger profile; this is not a Cowork endpoint
Ordinary ChatGPT Work plugin/chat	No general endpoint for invoking an arbitrary installed plugin was established	Do not infer inbound support from scheduled-plugin support
ChatGPT Workspace Agent	Documented API channel and Workspace Agent access token [40, 41]	Separate planned Q-WA qualification; not automatically part of Q-W plugin support

The Claude Code Routines API starts a configured routine. OpenAI’s Workspace Agent trigger queues work and currently returns 202 Accepted with no response body or run ID; its agent response cannot currently be retrieved through that API. Acceptance is not completion. Claude routine trigger, Workspace Agent trigger

Workspace Agents is documented for Business and Enterprise workspaces, subject to access and configuration. Personal ChatGPT Work access alone does not establish eligibility. Workspace Agent configuration can include skills and custom MCP tools, but Zia must verify how each required capability is configured; it must not assume a Work plugin package installs unchanged as a Workspace Agent. Workspace Agents

Accounting example: when a reporting period is ready, the application creates an operation record and sends an authorized request to the configured worker endpoint. The worker retrieves approved inputs, follows the dependency graph, runs deterministic reconciliation and independent checking, and records a pending review. An authenticated owner approves publication. The application reads the final business result from its own authorized results service. Another AI worker can submit the same type of request when explicitly authorized.

For a trigger that does not expose result retrieval, Zia’s proposed integration supplies an application-owned operation ID, durable request/result records, and an authenticated completion tool or callback. These are our components, not vendor API guarantees. Include the operation reference in the supported request payload and require execution tools to validate it against the authorized customer and immutable inputs. Free-form model interpretation of an ID is not an authorization control.

The request ledger distinguishes submitted, accepted, running, awaiting approval, completed, failed, and outcome-unknown states. A network timeout can leave trigger acceptance uncertain; reconcile through owned records and bounded recovery rather than claim failure or blindly retry. Repeated requests reuse the same business operation identifier. Execution attempts may repeat, but protected tools must prevent duplicate committed effects. A missing callback produces an unresolved operation, never false success.

Loop engineering covers trigger intake, bounded retries, durable state, escalation, and completion. Graph engineering covers dependencies and allowed operations within the run. Triggering a worker does not itself enforce either. Every inbound profile must declare input validation, caller authorization, replay handling, quota/budget behavior, approval requirements, and a tested way to observe business completion. Use an SDK or managed application with a separately qualified result contract when the caller requires synchronous results or stronger lifecycle control than the selected trigger supplies.

Q-WA is a planned capability investigation and qualification milestone with no assigned release. It introduces a Workspace Agent configuration output only if its packaging, account access, inbound trigger, tools, and completion contract qualify. It is distinct from the OpenAI Agents SDK and the OpenAI managed Agents API. Existing 1.0/1.1/1.2 commitments and plugin-first preference remain unchanged. No live inbound-trigger test is claimed by this document.

MCP-callable workers and inbound invocation

An AI worker can receive work through an MCP tool exposed by an owned MCP server. This is an optional interface capability of a qualified worker implementation, alongside API, scheduled, and interactive invocation. It is not a new implementation target or a new mandatory 1.0 deliverable. Zia should reuse the approved worker specification, business logic, and execution controls across interfaces.

MCP defines tool discovery and invocation through tools/list and tools/call. A tool implementation can validate a request and start an AI worker or a conventional workflow. The protocol does not itself supply a durable worker runtime, business approval enforcement, or protection against duplicate committed effects. [42]

Arrangement	What receives the request?	What it establishes
Cowork or Work connects to a customer MCP server	The customer's exposed tool	Outbound tool access from that host; no inbound endpoint for its installed plugins
Another agent calls a worker tool exposed by Zia's generated MCP interface	An owned service with a qualified backing worker	Inbound invocation of that backing worker
An MCP tool forwards a request to a Routines or Workspace Agent API	The destination's documented API trigger	An MCP-to-API bridge, subject to the destination's eligibility, limits, and completion contract
An MCP server is connected to an otherwise interactive-only plugin host	The server receives calls made by the host	No verified route to start that plugin externally; connecting the server does not create one

“Inbound MCP” describes direction relative to the worker service: the requesting application or agent is the MCP client, and the worker interface is the MCP server. MCP notifications or other protocol messages must not be advertised as a generic way to wake a host or start a plugin. Any such behavior requires a documented, separately tested host capability.

Example: an Indirect Rate Forecasting Worker. An authorized coordinator requests: “Run the September indirect-rate forecast for company ABC using the approved baseline.” Its MCP client invokes the worker's exposed tool. The following names and job contract are proposed Zia application conventions, not built-in MCP methods:

Application-defined tool	Inputs and behavior	Result
start_indirect_rate_forecast	Customer, reporting period, approved baseline reference, immutable input reference/digest, and idempotency key; validate caller scope and inputs before accepting work	Durable application operation ID and truthful acceptance state; completed result only if actually complete
get_forecast_status	Operation ID; verify the caller may access that customer's operation	Accepted, running, awaiting approval, completed, failed, or outcome-unknown, with permitted progress details
get_forecast_result	Operation ID; perform the same authorization check	Authorized completed forecast, calculation evidence, and artifact references; explicit pending/error response otherwise

For long-running work, the owned service durably records and dispatches the job, then promptly returns an operation reference. The caller can subsequently query status and results. This application operation ID is distinct from the MCP/JSON-RPC request ID and any vendor run ID. A repeated submission with the same scoped idempotency key and identical inputs resolves to the same operation; reuse with different inputs is rejected. Durable dispatch and reconciliation must cover a crash between recording the request and starting execution. An MCP connection closing must not silently lose an accepted job or imply its cancellation.

Graph engineering enforces the sequence: validate inputs, calculate rates deterministically, independently check calculations, explain variances, obtain required approval, then publish. Loop engineering bounds investigation of unexplained variances, additional evidence gathering, retries, and escalation. The execution service and protected tools enforce these controls. Describing the sequence in an MCP tool description or a plugin skill is not sufficient.

The receiving service authenticates callers, enforces customer and operation scope on every tool, validates schemas, applies budgets and quotas, and preserves the approval and duplicate-effect protections in FR-J10. Approval must bind to the operation and approved inputs under the existing approval contract; the invoking agent cannot create consent simply by supplying an approved argument. Record the server operator, credential owner, backing runtime, durable-state owner, and result-service owner. Assess data constraints across the complete chain.

An MCP wrapper does not improve the underlying destination's guarantees by itself. In particular, a Workspace Agent bridge must still address its trigger-only response through the owned completion contract described above. For Cowork or ordinary Work plugins, inbound MCP remains unavailable until a supported way to start the actual plugin is verified. A plugin that calls a separately hosted worker must be labeled as a surface for that backing service.

Qualification is per MCP client/server protocol version and backing execution profile. Do not assume all hosts support every MCP feature. The submit/status/result pattern is an application design; any use of protocol-native asynchronous features needs its own compatibility evidence. This revision documents the design and protocol basis, not a passing integration test.

Four independent decisions

Decision	Question	Rule
Mode	Are we solving today's problem or manufacturing a reusable worker?	Mode 1 produces a playbook using an existing agent. Mode 2 builds a reusable deliverable.
Level	How much operational independence is required?	Assistant, rostered worker, or autonomous service. The latter two qualify as Digital FTEs in this product.
Trigger	What starts the work?	A person, a schedule, an API request, an MCP tool call, a webhook, or a queue. A schedule alone does not determine the implementation form.
Form and target	Which implementation can meet the requirements?	Select using capabilities, data constraints, cost, deployment needs, and verified support.

A reusable interactive assistant can be manufactured in Mode 2 and implemented with an SDK. It is still an assistant. For version 1.x, plugin execution targets support assistants and qualified rostered workers. Autonomous services require a process or managed target because their required lifecycle guarantees are outside the plugin baseline. This is a product support boundary, not a universal definition of what plugins can do.

4 User experience

1. Describe the problem. Accept plain language, policies, schemas, and approved sample data. A completed technical specification is unnecessary. Disclose development-time data flows before accepting customer material.
2. Resolve the important decisions. Explain the recommended mode, level, workflow, and alternatives using pinned sources. Ask a focused question, or up to three related questions when that reduces effort. Keep previous answers. Continue unrelated drafting when one decision is unresolved.
3. Review the specification. Show inputs, outputs, business rules, tool effects, examples, acceptance criteria, and outstanding decisions in understandable language.
4. Choose deployment settings. Show compatible targets, costs, access prerequisites, and data flows. Unsupported requirements produce a named gap before a build begins.
5. Approve and build. Record the specification and build configuration versions. Carry out authorized implementation and repair in a reviewable change set. Preserve unrelated code and show progress.
6. Evaluate and hand over. Present independent business tests, operational evidence, limitations, cost measurements, and deployment instructions. A demonstration alone does not establish readiness.

Routine work within existing authorization should continue without repeated approval. Material changes and operations outside that authorization require the assigned reviewer. The host and runtime enforce permissions rather than relying only on prompt instructions.

5 Release baseline and technology decisions

Product releases 1.0, 1.1, and 1.2 track deliverable scope. The prototype milestone M0, described on the First Pilot page, is neither a product release nor evidence of general support.

Release	Generated outputs	Development hosts	Required evidence
1.0	Claude Code plugin; interactive and qualified Routines execution, plus CI non-preview heartbeat	Claude Code CLI and Codex CLI	Two host/target combinations, with each deployment profile tested independently
1.1	Add Claude Managed Agents and its Claude Code surface	Retain both	Common business fixtures plus managed deployment, data, recovery, and adapter tests
1.2	Add OpenAI Agents SDK, one typed Python profile initially	Retain both	SDK conformance, custom deployment, and OpenAI-only execution evidence
Q-CW / Q-W; release assignment after qualification	Add Claude Cowork and ChatGPT Work plugins, each with independently qualified profiles	Claude Code and Codex	Target-specific acceptance below; no automatic expansion of 1.0
Q-WA; release unassigned	Investigate and qualify ChatGPT Workspace Agent configuration with API trigger and owned completion contract	Claude Code and Codex; builder integration to verify	AC-37 and AC-38; separate from Work plugins and OpenAI API/SDK targets
Unscheduled extensions	Generated Codex/OpenCode plugins, OpenCode development host, additional surfaces/languages, and OpenAI managed target	Independently qualified	No release commitment or support claim until scope and evidence are approved

The default target is host-plugin/claude-code. Every use of “default target” or “default workflow” in this document refers to that target. Routines is its preferred scheduled profile when customer policy permits preview features; CI is the non-preview alternative. Claude Agent SDK is outside mandatory generated-output scope.

Codex remains a development host in 1.0. It must generate and evaluate the Claude Code plugin using the destination host and authorized Claude access. The committed OpenAI-only SDK path arrives in 1.2. A separately qualified ChatGPT Work plugin may provide an earlier path; Codex development-host support alone does not provide one. The selector offers only released, qualified targets, with future targets clearly marked unavailable. If no available target fits, report the gap rather than offer a build that cannot be delivered.

Area	Working decision
Zia tooling language	TypeScript for the composer, schema tooling, build coordination, and host integration code. This does not determine the generated worker language.
Default worker language	Typed Python with strict static checking and runtime validation. Use explicit annotations, classes, protocols, generics, and structured models where useful.
Alternative worker language	TypeScript where customer application integration, shared web contracts, or team expertise provides a material advantage. Full generation support requires a tested language profile.
Boundary contracts	Publish a versioned JSON Schema subset and shared validation fixtures. Python uses Pydantic or equivalent runtime validators; TypeScript uses Zod or equivalent. No language-specific behavior silently changes the published contract.
Toolchains	Bun and a separate TypeScript compiler check for Zia tooling. Generated Python workers use a pinned Python interpreter, isolated environment, dependency lock, strict Pyright checks, and runtime validators. Qualified TypeScript workers use their own strict compiler and tested Node.js/Bun profiles.
Portability	Isolate provider orchestration and deployment wiring. Test each advertised environment. Node compatibility does not establish Cloudflare Workers compatibility.
Ecosystems	Anthropic and OpenAI are the supported model ecosystems for 1.x. The schema can represent other providers without advertising them as supported.
Integrations	Approved skills and MCP servers may come from GIAIC/PIAIC/Panaversity, customers, or third parties. Authorship is not limited to the two model vendors.
Default for initial implementation	Claude Code plugin, with typed Python business tools only where needed.

Language decision and evidence

Python appears to be the more established language in the AI-agent ecosystem, but this review did not find a representative survey establishing what percentage of agent developers use it. Treat that assessment as an ecosystem inference, not a measured majority or a claim of technical superiority.

The 2025 Stack Overflow survey reports a seven-percentage-point increase in Python adoption and highlights its AI, data-science, and backend role [23]. This is a broad developer survey, not an agent-development language-share study. SDK availability supports feasibility rather than popularity: both Anthropic and OpenAI provide Python and TypeScript agent SDKs [4, 7, 24]. Required features still need verification in each language profile.

The product decision gives greater weight to intended developers, existing domain libraries, and accounting/analytical workloads than to sharing a language with Zia's own tooling. Python's data-processing ecosystem and Decimal arithmetic are relevant to these workers [29, 30]. Popularity alone does not establish correctness. Type annotations in Python and static types in TypeScript do not validate external inputs at runtime [13, 25]. Strict checking, runtime validation, independent tests, and enforced operating controls remain mandatory in both languages [26, 27].

Use Python as the default, with TypeScript selected when integration with an existing TypeScript application or web interface materially simplifies delivery. Do not split a small worker across languages merely to preserve the tooling choice. A worker dominated by Python business logic should normally remain a Python application. UI language, development host, model vendor, agent framework, and worker language are separate decisions.

Version 1.0 generates plugins and only the business tools they need. It does not require an SDK application. Version 1.2 adds one Python OpenAI SDK profile. Additional language profiles are unscheduled. The book includes Python instruction, but that does not establish the language preferences of every learner; curriculum coverage, maintainer experience, and pilot results guide later changes.

Decision record

These entries are selected working assumptions for planning. This revision does not claim that a product-owner release approval has already occurred.

ID	Decision and reason	Status and owner
RD-01	Restore Codex CLI development support to 1.0, matching the requested Codex support in the earlier baseline.	Included in this draft. Product owner owns release scope.
RD-02	Plugin first, Claude Managed Agents second, OpenAI Agents SDK third; capability and customer constraints govern eligibility. Claude Agent SDK is outside mandatory output scope.	Approved direction, implemented in v0.10.
RD-03	Plugin output in 1.0; add Claude Managed Agents in 1.1; add OpenAI Agents SDK in 1.2.	User-approved release sequence in v0.10.
RD-04	Generated Codex/OpenCode plugins and OpenCode host are unscheduled extensions. Codex development host remains 1.0.	Independent qualification required.
RD-05	Evaluate the OpenAI managed target only through a bounded capability spike.	Conditional. No support claim without tests.
RD-06	Typed Python is the default generated-worker language. Keep TypeScript for Zia tooling and portable contracts between them. The rationale is ecosystem and domain fit, not an agent-language market-share statistic.	Selected in v0.8 following the language review.
RD-07	Typed Python business tools in 1.0; one Python OpenAI SDK profile in 1.2. Additional worker-language profiles are unscheduled.	Use curriculum and maintainer experience to revisit toolchain choices; no learner preference is inferred.

6 First end-to-end milestone

M0 demonstrates the GIAIC/PIAIC/Panaversity customer-support worker, Zia Khan — GIAIC/PIAIC/Panaversity AI Support. Its mission, worker identity and self-description, Slack, email, and WhatsApp channels, support loop and graph, bounded prototype scope, and M0 exit evidence are on the First Pilot page. The release path below is the shared roadmap: M0 and M4 are the pilot milestones; the others are engineering milestones defined by this document.

Path from M0 to release

Milestone	Outcome	Release evidence
M0	One useful, controlled GIAIC/PIAIC/Panaversity support workflow	The exit evidence above
M1	Typed layer composition, authoring, approvals, independent evals, and resumable builds	Engineering schema/composition tests and AC-1, AC-4 to AC-7, AC-14 to AC-17, AC-19, AC-22 to AC-25
M2	Claude Code plugin generation, qualified Routines deployment, and enforceable loop/graph execution	AC-28 to AC-30; Routines acceptance below
M3	Codex development integration and reproducible plugin handover	AC-13 and Codex portion of AC-26; two host/target combinations
M4	Full GIAIC/PIAIC/Panaversity support pilot with Slack, email, and WhatsApp; learner and consultant studies; release handover	All 1.0 Must requirements and release-specific acceptance evidence
M5	Claude Managed Agents and its Claude Code surface	All 1.1 obligations, including AC-3, AC-8, AC-27, AC-31
M6	OpenAI Agents SDK with one Python profile	All 1.2 obligations, including AC-2 and AC-12

7 Product requirements

Every row is mandatory for 1.0 unless the release matrix assigns the referenced feature to a later release or unscheduled extension. Part 2 preserves the stable FR and NFR identifiers and their detailed evidence.

Product obligation	Required behavior	Detailed requirements
Guided decisions	Accept incomplete business descriptions, cite decision rules, preserve answers, and avoid unnecessary questions.	FR-A1 to FR-A11
Composable specifications	Maintain independently owned layers with pinned versions and provenance. Permit only defined merge operations. Reject known conflicts and unresolved mandatory decisions.	FR-B1 to FR-B13, FR-C1 to FR-C9, FR-G1 to FR-G4
Controlled implementation	Build approved contracts in a focused change set. Validate external inputs. Isolate vendor dependencies and preserve unrelated source.	FR-D1 to FR-D17
Independent proof	Use protected domain expectations, deterministic checks where possible, independent narrative review, and fresh release regression evidence.	FR-E1 to FR-E12
Supported hosts	Prove the same mandatory behavior on each advertised development host, with documented setup and capability differences.	FR-F1 to FR-F10
Recoverable work	Enforce budgets, cancellation, safe retries, durable operation identities, schedules, graph dependencies, and approvals outside prompt text.	FR-J1 to FR-J9
Data and customer boundaries	Record development and runtime data flows, category-specific location constraints, named approvals, secret references, and customer isolation.	FR-K1 to FR-K9, NFR-3, NFR-4, NFR-13
Portable handover	Supply editable source and contracts, tests, deployment and recovery instructions, limitations, and operating evidence.	FR-L1 to FR-L4; FR-L5 and FR-L6 when their profiles are released

8 Quality and release decision

Ease of use is tested with representative users. Test the default Claude Code plugin workflow with ten learners in a two-hour session after access setup. At least eight must complete without assistance beyond product guidance. Report completion, assistance, failures, and setup time for all ten. At least four of five consultants must complete the supplied intake and identify its approval boundary within 30 minutes after access setup.

Cost reporting includes model usage, host access costs, infrastructure, and integrations. A local learner path has no mandatory GIAIC/PIAIC/Panaversity hosting fee, but total cost must not be described as tokens alone. Record setup prerequisites separately.

For at least 20 fixed pilot attempts per execution target, report successful-run median and p95 duration and cost, success rate across all attempts, failed-attempt costs, and total attempt cost divided by successful completions. If there are no successes, cost per success is undefined. Numerical latency goals remain provisional until measured in the pilot.

Release requires all mandatory requirements for that release to have passing evidence, all advertised affected host/target combinations to pass their conformance checks, and no unresolved defect that breaks a mandatory business rule or authorization boundary. Record accepted nonblocking limitations. Never reuse stale evidence after a material change.

Decision	Responsible reviewer
Product scope and roadmap	Product owner
Domain rules and expected results	Domain owner
Build settings, deployment, recovery, and cost evidence	Technical lead
Customer data flows and restrictions	Customer
Personal-project reviews	Developer acting in the relevant roles

The handover records exact source, specification, build, package, adapter, model, fixture, and test versions. Platform documentation supports capability assessment. Only completed integration tests support product compatibility claims.

9 Boundaries and remaining decisions

Version 1.x excludes a graphical designer, fine-tuning, a package marketplace operated by Zia, additional supported model vendors, and automatic wiring of multiple independent workers. The support pilot answers approved questions and routes exceptions. Personalized student-record access, refunds, payment handling, and enrollment changes require separate authorization and tests. Accounting is a later, release-unassigned reference case for numerical and business controls.

No release promises identical model wording, byte-identical generated code, migration of live vendor sessions, or universal portability. Shared business contracts and fixtures are preserved where capabilities permit. Each destination has its own runtime evidence.

Part 2 resolves the schema, composition, runtime-enforcement, evaluation, and data-location issues raised in review. These remaining choices are bounded implementation decisions:

Decision	Owner	Needed by
Qualify each release before advertising support	Technical lead	Evidence for the approved RD-03 sequence
Exact supported SDK, host, model, and protocol versions	Technical lead	Each integration milestone
Package distribution and license, aligned where appropriate with KSoR	Product owner	External package distribution
Storage implementation and secret backend	Technical lead	M1/M2 deployment design
Support fixtures, approved knowledge, channel access, and operating owner	GIAIC/PIAIC/Panaversity support owner and channel administrator	M0; second external channel by M4
Concrete region taxonomy and provider evidence	Technical lead and customer	Any constrained deployment

---

Part 2 Engineering contracts

E1 Reading rules and release scope

Must is a release obligation. Should is planned but may be deferred with recorded rationale. Could is optional. An unqualified requirement belongs to 1.0. References to a later feature apply when that feature ships, not before. A mixed row follows this explicit feature/release mapping:

Feature	Release
Claude Code and Codex development hosts; generated Claude Code plugin; interactive, Routines and CI profiles	1.0
Claude Managed Agents, promotion, and Claude Code surface	1.1
OpenAI Agents SDK Python profile and OpenAI-only end-to-end path	1.2
OpenCode host; generated Codex/OpenCode plugins; other surfaces/languages; OpenAI managed target	Unscheduled
Claude Cowork and ChatGPT Work plugin targets	Planned Q-CW / Q-W; release assignment after qualification
ChatGPT Workspace Agent configuration and inbound API	Q-WA; release unassigned; separate from Q-W
Claude Agent SDK output	Outside mandatory scope

AC-13 covers two host/target combinations in 1.0 and expands as targets ship. AC-12 belongs to 1.2. FR-D17/AC-31 apply in 1.1; AC-32 applies only if its unscheduled targets are approved.

Mode 1 solves a current problem with an existing agent. Mode 2 manufactures reusable software. Assistant, rostered_worker, and autonomous_service are independent levels. Assistants may use any supported output form. Rostered workers need a tested heartbeat and persistent run state. For the 1.x support baseline, autonomous services use process or managed targets. A graph, schedule, or provider requirement may rule out a target regardless of level.

Validation boundary

Stage	What it establishes	What it cannot establish alone
Schema	Required fields, types, enum values, reference syntax	Correct behavior or arbitrary semantic consistency
Composer and graph validator	Known merge rules, references, cycles, declared resource conflicts, approval dependencies, known feasibility limits	Undeclared effects hidden in executable code
Runtime enforcement	Allowed tools/resources, execution dependencies, operation-bound approvals, budgets, uniqueness and locks	Correct business expectations
Evaluation and review	Behavior on stated fixtures, independent domain expectations, faults and operational evidence	Universal correctness for all future inputs

E2 Specification and build contracts

The contracts below are the required design for schema implementation. The examples are documentation fixtures, not proof that an executable schema has passed them. At M1, implement the schema and run these positive and negative fixtures in CI.

E2.1 Source layers and resolved specifications

agent.spec.md contains YAML front matter plus explanatory Markdown. Use a custom parser/validator. Similarity to SKILL.md does not imply a host automatically understands this schema.

A reusable package includes a manifest with id, kind, owner, version, approval_status, sources, applicability, dependencies, compatibility, and a content hash in the lock. kind is horizontal, vertical, or customer. A project's source file has kind: project. A horizontal root has no parent. Other layers have one direct extends reference. Vertical chaining is optional in 1.0. A project may extend a horizontal or vertical package directly when no customer layer is needed.

Source layers are partial patches. Validate their own metadata and any fields they supply, then compose and validate the complete resolved contract. A child need not repeat a mandatory value already supplied by a parent. Omitting a field inherits it and does not delete a control.

Field	Resolved type	Rule
af_spec	positive integer	Schema major. Exact schema/package versions are pinned in af.lock.
kind	enum	Resolved deployment contract is project. Source packages may use the other kinds.
name, owner	slug, identity reference	Required project metadata.
extends	package reference	Required on non-root source layers. Resolved output retains the full package chain and provenance.
mode	1 or 2	Recorded decision. Mode 1 produces a playbook without a new process/managed scaffold.
level	assistant, rostered_worker, autonomous_service	Required for a manufactured worker. Independent of mode and trigger.
shape	registered neutral identifier	Versioned horizontal vocabulary.
allowed_providers	null or set of provider identifiers	Null means unrestricted by the spec, not supported by the product. An empty set permits no inference. Targets still obey the release support list.
data_policy	category policies	Per-category location constraints and explicit inference restrictions as defined in E2.5.
allow_preview	boolean	Defaults false. Enabling requires parent permission or a reviewed parent revision.
tools	identified tool contracts	Fields below. Missing tool access is denied.
resources	identified resources	Canonical scoped resources with schema and access semantics.
invariants	identified invariant contracts	At least one for a deployable worker.
acceptance	identified evaluation contracts	At least one for a deployable worker.
triggers	identified trigger contracts	Explicit chat trigger for assistants if none inherited. Rostered/autonomous workers need a non-chat trigger.
loop	loop contract	Required for rostered and autonomous workers.
graph	graph contract	Required for multiple jobs in a run.
roles	identified behavioral role contracts	Each declares an instruction artifact and permissions. Vendor model IDs belong in the build configuration.
actions	identified action contracts	Each declares input/output schema references. Concrete implementations belong in build bindings.
budget	limit contract	May declare max cost, active execution duration, tool calls, and iterations. Separate active execution from waiting for human approval.
feasibility	declared minima and required capabilities	Used for known satisfiability checks. Does not prove arbitrary business feasibility.
overridable	set of field paths	Parent-declared replaceable defaults. Controls cannot be made replaceable by a child.
delegation	optional allowlist	Named external workers and permissions. Cross-worker orchestration is outside the 1.x spec.

Artifact references use project-relative paths with content hashes in af.lock. The published JSON Schema subset is the authoritative interchange contract. Zia may author schemas in Zod, but export must preserve the supported semantics and produce one versioned artifact. Python Pydantic models and TypeScript validators must satisfy the same positive and negative fixtures. Explicitly test coercion, missing versus null values, extra fields, dates, enums, and decimal representations. Reject unsupported schema constructs rather than silently dropping them. The composer performs semantic checks that JSON Schema cannot express. Do not execute arbitrary package Python or TypeScript merely to validate an untrusted specification.

E2.2 Invariants, tools, resources, and acceptance

Invariant: id, statement, priority (must/should/could), owner, enforcement, validation (nonempty acceptance-ID list). enforcement has kind (code/service/runtime_control/review) and a symbolic binding. An irreversible-action gate or monetary invariant cannot use review alone. The target maps runtime_control to a verified hook, permission control, or owned enforcement service. The core enum does not contain hook.

Tool: name, effect (read/reversible/irreversible), approval (none/required), input, output, auth, permissions, reads, and writes. input/output are schema references. Access sets refer to declared resources. MCP-backed tools declare protocol_version; skill-backed tools declare format_version. Protocol identifiers must match a documented negotiated version before support is advertised. All irreversible tools require approval. A reversible tool can require approval as well.

Resource: id, scope (customer/project/worker/run), schema, and mutable. Use canonical identity plus partition keys at runtime. Two names that resolve to the same resource must not evade conflict checks. Access declarations are an enforceable contract. Unrestricted shell/network execution does not satisfy that contract.

Acceptance criterion: all records require id, statement, priority, owner, scenario, and oracle. The oracle-specific fields are a discriminated union:

Oracle	Required expectation	Evaluation
exact	actual output path and expected artifact reference	Compare normalized output to independently approved expected data.
schema	actual output path and schema JSON Schema reference	Validate the selected output.
trace	assert object with language and all predicates	Evaluate the pinned assertion grammar over normalized events. No arbitrary code evaluation.
rubric	actual, rubric, threshold between 0 and 1	Independent evaluation context and a recorded rubric version.

An acceptance criterion is a test, so it does not carry an enforcement method. Invariants reference acceptance IDs as their validation. Trace predicates in language af-trace/1 use path, op (eq/ne/lt/lte/gt/gte/contains), and a typed value. Predicates inspect normalized trace output, not unrestricted source code. More expressive grammars require explicit versioning.

E2.3 Triggers, loops, and graph execution

All triggers have id and kind. A chat trigger has an input schema. A schedule has cron, timezone (IANA name), misfire (skip/catch_up_once), overlap (forbid/queue_one/allow), and dedup_scope (logical_period). A webhook or queue has an input schema, source identity, deduplication key path, and overlap policy. Authentication and concrete endpoints are build bindings.

For schedules, derive the logical-period key from the intended fire time, time zone, trigger ID, worker ID, and customer scope. Retries reuse it. Define daylight-saving behavior through the selected scheduler profile and test it. A missed-run catch-up emits at most one run for the latest missed period. queue_one keeps at most one pending period while a run is active. The runtime needs a durable claim and unique key, not only a timer. The approved build locks its scheduler profile version.

The loop includes spine (run-state resource), checker, stop, and isolation. Checker kind is deterministic, model, or human. It references an independent role or action, criteria, and permissions. The checker cannot edit maker output or expectations. stop includes max_iterations, no_progress_after, on_failure, and an observable progress signal. isolation names a neutral requirement such as exclusive_workspace or isolated_process. The build maps it to a worktree/container/service arrangement with evidence.

Every graph node has id, kind, depends_on, reads, and writes. Agent nodes reference a role. Deterministic nodes reference an action. Human-checkpoint nodes reference a reviewer role, expiry, and approved operation scope. tools is a per-node subset of the worker tool allowlist. parallel_group is optional.

The graph validator rejects duplicate IDs, missing references, cycles, missing action/role bindings, and parallel nodes with overlapping writes or write/read conflicts. Shared immutable reads are permitted. Every approval-required tool execution must be covered by a valid operation-bound checkpoint or equivalent runtime approval gate. An ancestor checkpoint alone does not authorize all future inputs.

The runtime enforces the graph, resource access, tool allowlists, and approval records. Node inputs and outputs have declared schemas. A single run may contain parallel nodes, but the runtime must not expose undeclared mutable access. Unsupported host isolation or enforcement fails with E-CAP. A scheduling prompt, plan skill, or valid YAML file is not a substitute for these controls.

Approval records bind reviewer identity and role, decision, operation ID, input digest, spec hash, build hash, timestamp, and expiry. A changed input, scope, or expired approval requires a new decision. Persist pending checkpoints before yielding. A crash, replay, or resumed session cannot turn a pending or rejected checkpoint into approval.

E2.4 Build configuration

Field	Requirement
spec_hash	Exact approved resolved contract.
target	A release-supported target whose capabilities meet the contract.
implementation_language	python or typescript for generated executable worker code. Python is the default for process targets. Omit for declarative-only artifacts. Plugin helper tools declare their own runtime dependencies.
language_profile	Exact tested SDK/runtime/toolchain profile. Version 1.0 has no process target; the first required process profile is Python OpenAI Agents SDK in 1.2. TypeScript profiles require independent qualification.
models	Model identifiers for used roles. Same model ID may be used by maker and checker only when independent contexts and permissions are enforced and the risk policy permits it.
model_diversity	Optional risk-policy requirement, with roles and reason. No blanket model-ID inequality.
bindings.actions	Each symbolic action maps to a reviewed module/export and immutable artifact hash.
bindings.tools	Each tool maps to a tested service or local implementation, with scoped permissions and secret references.
bindings.resources	Each resource maps to a canonical physical store/partition with enforced access.
bindings.triggers	Concrete implementation/version, minimum interval, timing tolerance, quota scope/capacity evidence, shared demand, retry/catch-up allowance, and overage policy.
bindings.controls	Runtime-control bindings to verified enforcement mechanisms.
bindings.isolation	Concrete environment and evidence for the spec isolation requirement.
bindings.reviewers	Approved identities/roles and notification route for checkpoints.
data_inventory	Actual component/category/location/evidence records from E2.5.
environment	Target-specific deployment settings, including self-hosted sandbox where relevant.
surfaces	Optional supported wrapper plugins. Empty is valid.
secrets	References only. Never credential values.
telemetry	off by default or explicitly approved usage fields.

Each artifact and implementation binding is pinned through af.lock. A configuration lacking a required binding is not buildable. Every target-specific operational check must pass before support is advertised.

E2.5 Data policy and evidence

data_policy.locations has optional category entries for execution, business_storage, session_records, memory_stores, logs, and inference. Each entry is either null (unconstrained by this policy) or a nonempty allowed-region set. Use registered region identifiers. An empty intersection is invalid. allowed_providers independently restricts inference vendors.

For Routines, include the selected managed or self-hosted route and independently evidenced execution location; assess other categories separately.

The build's data_inventory lists every relevant component with category, service/provider, location or unknown, evidence reference, verification date, data classes, and retention/deletion behavior. A constrained category requires complete supported evidence. Unknown fails closed for that category. Unconstrained categories still disclose known locations, provider involvement, and unknowns.

An allowed-region sandbox establishes only the location of the tool execution it actually controls. It does not establish vendor session, memory, log, or inference locations. For example, Anthropic documents that attached skills and memory-store content are stored by Anthropic and synchronized to a self-hosted sandbox [3]. Apply the same analysis to every provider and surface. Do not infer data location from a model vendor's headquarters or a target name.

E2.6 Normative example fragments

These fragments illustrate consistent record shapes and references. They are not a complete deployable project: the package manifest, schemas, fixtures, action implementations, graph, and build inventory must also exist and be pinned. Every fragment must become a schema fixture at M1.

invariants:
  - id: money-1
    statement: Amounts preserve currency and rounding rules; unknown is not zero.
    priority: must
    owner: accounting-owner
    enforcement:
      kind: code
      binding: reconcile_period
    validation: [rec-3]
acceptance:
  - id: rec-3
    statement: Reconciliation matches independently approved period totals.
    priority: must
    owner: accounting-owner
    scenario: fixtures/period.json
    oracle: exact
    actual: result.totals
    expected: fixtures/period.expected.json
  - id: rec-7
    statement: Duplicate transaction identifiers prevent result acceptance.
    priority: must
    owner: accounting-owner
    scenario: fixtures/duplicates.json
    oracle: trace
    assert:
      language: af-trace/1
      all:
        - path: result.accepted
          op: eq
          value: false
        - path: error.contract
          op: eq
          value: TransactionSet
  - id: rec-9
    statement: Variance explanations distinguish facts from interpretation.
    priority: must
    owner: accounting-owner
    scenario: fixtures/narrative.json
    oracle: rubric
    actual: result.explanation
    rubric: rubrics/variance.md
    threshold: 0.8
  - id: rec-10
    statement: The report matches its declared output contract.
    priority: must
    owner: accounting-owner
    scenario: fixtures/period.json
    oracle: schema
    actual: result.report
    schema: schemas/report.schema.json

triggers:
  - id: month_end
    kind: schedule
    cron: "0 9 1 * *"
    timezone: Asia/Karachi
    misfire: catch_up_once
    overlap: forbid
    dedup_scope: logical_period
resources:
  - id: ledger
    scope: customer
    schema: schemas/ledger.schema.json
    mutable: false
  - id: budget
    scope: customer
    schema: schemas/budget.schema.json
    mutable: false
  - id: report
    scope: run
    schema: schemas/report.schema.json
    mutable: true
graph:
  nodes:
    - id: fetch_ledger
      kind: deterministic
      action: fetch_ledger
      depends_on: []
      parallel_group: fetch
      reads: [ledger]
      writes: []
      tools: [read_ledger]
    - id: fetch_budget
      kind: deterministic
      action: fetch_budget
      depends_on: []
      parallel_group: fetch
      reads: [budget]
      writes: []
      tools: [read_budget]
    - id: reconcile
      kind: deterministic
      action: reconcile_period
      depends_on: [fetch_ledger, fetch_budget]
      reads: [ledger, budget]
      writes: [report]
      tools: []

This graph fragment demonstrates immutable parallel reads and a bound deterministic action. The full accounting worker adds an explanation role, independent checker, owner checkpoint, and a publication action covered by that checkpoint. This accounting fragment is illustrative. The support pilot implements analogous source checks, answer review, an owner checkpoint, and protected sending, tested by AC-30 and P11 (see First Pilot).

allowed_providers: [anthropic, openai]
data_policy:
  locations:
    execution: [pk]
    business_storage: [pk]
    session_records: null
    memory_stores: null
    logs: [pk]
    inference: null

Null means no region restriction for that category. It does not mean data stays local or that provider retention is irrelevant. The data statement must disclose the actual service behavior and unknowns before approval.

E2.7 Required schema fixtures

Positive fixtures cover inherited project fields, all four oracles, code and runtime_control enforcement, an SDK assistant, declared immutable parallel reads, and a complete schedule. Negative fixtures cover missing acceptance metadata, enforcement.kind: hook, invalid oracle combinations, arbitrary trace code, missing schedule time zone, graph cycles, unbound actions, parallel resource conflicts, unresolved constrained locations, and missing approval coverage. Passing JSON Schema is only the first validation stage in E1.

E3 Composition and feasibility

Compose horizontal, vertical, customer, then project, retaining the owner and source version for every field. Packages are content-addressed and exact versions are locked. Apply these operations by field type:

Field class	Permitted child operation	Reject or escalate
Existing allowed sets	Intersection	Union that adds permissions, empty required result
Numeric ceilings	Lower within known feasible range	Increase or value below a required minimum
Required minima	Increase, subject to ceilings	Reduction or minimum above a ceiling
Identified invariants/evals	Add a new ID or inherit unchanged	Same ID with changed meaning, deletion, or silent threshold change
Approvals/checkpoints	Add obligations or retain	Remove, narrow coverage, or replace reviewer authority without reviewed parent change
Preview permission	Retain false or tighten true to false	False to true without explicit parent permission or reviewed parent revision
Replaceable defaults	Replace when the parent explicitly permits	Unmarked replacement
Absent fields	Introduce if schema permits	Unknown fields, hidden permissions, or an invalid resolved result
Free-text business rules	Inherit or add with independent owner review	Automatic claims that a rewrite is semantically stricter

An unmarked existing field is protected. An absent field is not an implicit prohibition on supplying a required project value. Permission to override a default cannot be created by the child itself.

After merging, check required tool coverage, dependencies, approval references, feasible set intersections, limit bounds, and graph integrity. Tighter does not necessarily mean feasible. If a critical mandatory task has a known lower bound above its new budget, fail with E-FEASIBILITY. When feasibility is unknown, name the unresolved question and require evidence or designated review rather than declaring proof.

Changes to an inherited obligation use a new parent-package version, an explicit migration or change report, and affected approvals. A migration note alone cannot authorize a schema-major mismatch. Test source and destination contracts plus behavioral regressions.

E4 Runtime and evaluation contracts

The target adapter exposes run(resolvedSpec, buildConfig, scenario) and returns a normalized trace reference and terminal status. Long-running or human-paused evaluations may return a pending run handle that the harness resumes. Record at least run/customer/worker IDs, logical operation IDs, spec/build versions, trigger events, node start/end, tool requests/results, approval references, resource-access decisions, retries, stop/cancel events, model usage, costs, and outcome.

Enforce writes at the committing service or a durable operation ledger with scoped uniqueness. Persist pending intent and outcome. An external timeout after a possible write is an unknown outcome, not permission to issue a new request. Reconcile through the external operation key or route to review if the service cannot establish the outcome. Unsupported safe-write behavior prevents advertising that integration.

The checker has fresh evaluation context, independent criteria, and read-only access to the result. It cannot change the source, fixtures, thresholds, or maker artifact. Deterministic calculation checks take priority over model judgment. Model diversity is a risk-policy option, with evidence, rather than a substitute for independence.

Preserve common domain expectations across targets. Separately test each target's scheduler, approval enforcement, isolation, cancellation, data flows, and recovery. A target may pass the business fixture and still fail deployment acceptance. A release reports both results.

Before changed packages, adapters, models, or generated code are released, rerun affected cases and mandatory business/security/conformance suites. Record the matrix of affected advertised combinations and fresh evidence. Optional developer watch mode is outside this mandatory gate.

E5 Functional requirements

Group A: Decision and intake

ID	Priority	Requirement	Evidence
FR-A1	Must	From a plain-language problem statement, run the book's decision gates and return the Mode (1 or 2), the FTE level, the shape, and a citation for each decision.	Decision record contains mode, level, shape, and resolvable citations
FR-A2	Must	Ask only questions that materially change behavior, controls, cost, or deployment. Prefer one focused question. Up to three closely related questions may be grouped when they can be answered together. Preserve answers, show consequences of defaults, and pause only work dependent on the missing answer.	AC-6
FR-A3	Must	Refuse to scaffold, and refuse to approve, while any required gate is unresolved. Drafting of spec sections that do not depend on the open gate may continue, with the gate shown as open.	An unresolved gate blocks build and approval but not unrelated drafting
FR-A4	Must	When the problem is not an agent problem according to the book's "Is This an Agent Problem?" gate, cite the reason and stop agent scaffolding. Provide a conventional-automation recommendation and implementation brief with inputs, rules, outputs, and suggested acceptance cases; hand off separately authorized coding to the development host. Do not classify this as a supported AI-worker target.	AC-7
FR-A5	Must	Record every gate answer, its citation, the rejected alternatives, and the constraints that determined the choice in the Project record and in the spec body.	Decision record lists rejected alternatives
FR-A6	Should	Order the gates so that the earliest questions eliminate the most options. The order is part of the Identity/Praxis record and is versioned with it.	Gate order file is versioned
FR-A7	Must	Intake accepts the problem statement plus policies, sample inputs, example outputs, and system constraints, and produces a structured brief that lists assumptions and missing information. A completed technical document is not required.	AC-14
FR-A8	Must	Show reasonable defaults with consequences. Preserve prior answers and approved progress when intake resumes.	Resume test preserves answers; AC-6
FR-A9	Must	Keep mode separate from autonomy and output form. A Mode 1 result produces a cited playbook for solving the current problem with an existing agent, without manufacturing a new runtime. A Mode 2 result manufactures a reusable worker, including an interactive assistant. A playbook may be packaged as a host skill without changing its mode.	AC-22
FR-A10	Must	Intake never requests production business records. It asks for approved samples, schemas, or synthetic data, and says why.	AC-23
FR-A11	Must	Record mode, level, trigger pattern, and required capabilities separately. Levels are assistant, rostered_worker, and autonomous_service. Only the latter two are called Digital FTEs. An assistant may use a plugin, process, or managed target. Form eligibility follows tested capabilities and the explicit first-release restrictions in E1.	AC-29

Group B: Spec and package authoring

ID	Priority	Requirement	Evidence
FR-B1	Must	Produce one file, agent.spec.md. The YAML front matter is the contract. The Markdown body holds the rationale, the gate answers, and the citations.	File exists in the format of E2
FR-B2	Must	Validate layers and resolved contracts at pinned schema versions. Publish one authoritative JSON Schema interchange subset with shared conformance fixtures. Internal Zod schema authoring is allowed. Python and TypeScript runtime validators must preserve the published supported semantics; language-specific refinements are explicit checks.	AC-1; schema interchange and coercion fixtures
FR-B3	Must	Every tool declares input/output schema references, effect class, approval policy, authentication, permissions, and resource read/write sets. MCP-backed tools pin a tested protocol version; skill-backed tools pin a tested format version.	E2 tool-contract fixtures reject missing required fields
FR-B4	Must	Every spec declares at least one invariant and at least one acceptance criterion. Every irreversible tool requires an approval gate and at least one trace assertion that covers it.	E-NO-EVAL fires on a fixture
FR-B5	Must	Keep normative business contracts independent of vendor API primitives. Use the vocabulary in E2. Target names, vendor API calls, and hook implementations belong in build configurations and adapters. Provider identifiers remain permitted in allowed_providers, and explanatory prose may name rejected technologies.	Schema rejects vendor API fields; accepts provider constraints and explanatory citations
FR-B6	Must	Citations in the spec body use stable anchors of the form page-slug#concept-id, resolved against the pinned System of Record release.	AC-5
FR-B7	Must	Every invariant carries id, statement, priority, owner, enforcement, and validation. Enforcement uses kind and binding. Every acceptance criterion carries id, statement, priority, owner, scenario, oracle, and its oracle-specific expectation. An acceptance criterion is a test and does not have an enforcement field. E2 defines both records.	Schema accepts the E2 examples and rejects missing required metadata
FR-B8	Must	The horizontal invariants include the domain correctness rules: critical calculations and business invariants are enforced by deterministic code or by the authoritative business service, never by prompts or skills alone. Monetary values carry currency, precision, and rounding rules. Unknown is distinguished from zero.	AC-20
FR-B9	Should	Explain decisions in clear American English suitable for ESL readers, with technical terms defined in context.	Comprehension check on the reference spec
FR-B10	Must	Package authoring. The plugin creates a vertical or customer package skeleton (manifest, front matter, invariants, evals, fixtures) and validates it: schema, tightening rule, citation resolution, and a composition test against a sample project. A package that fails validation is not publishable.	AC-24
FR-B11	Must	A released domain package includes independently executable evals against a sample worker before customer deployment. The sample and expected results are reviewed independently of generated implementation.	AC-24
FR-B12	Must	Rostered and autonomous workers declare a loop: run-state resource, independent checker, stop limits, failure action, and an isolation requirement. They require a non-chat trigger. Every schedule declares an expression, time zone, missed-run policy, overlap policy, and deduplication scope. Event triggers declare input contracts and stable event keys.	AC-29, AC-30; schedule contract fixtures
FR-B13	Must	Multi-job runs declare a graph with typed nodes, dependencies, resource read/write sets, and symbolic action or agent-role bindings. The composer checks references, cycles, declared parallel conflicts, and approval dependencies. Runtime controls enforce resource access and approvals. Schema validation alone does not prove absence of shared mutable state.	AC-30; E-GRAPH and E-RESOURCE fixtures

Group C: Composition

ID	Priority	Requirement	Evidence
FR-C1	Must	Compose horizontal, then vertical, then customer, then project into agent.resolved.json, with a provenance entry for every field.	Resolved spec of ref-core shows layered provenance
FR-C2	Must	Apply only the typed composition operations in E3. Restrictive set intersections, numeric limit reductions, and additions of identified obligations are permitted only if the result remains valid and known feasibility conditions pass. Never infer that an arbitrary prose rewrite is a tightening.	AC-4; conflicting-limit and rule-replacement fixtures
FR-C3	Must	A parent may explicitly mark a default replaceable. Existing controls are not replaceable by a child. A field absent from all parents may be introduced when the schema permits it. Required project fields may be inherited and are checked after composition.	Inherited-field and unpermitted-replacement fixtures
FR-C4	Must	Verify that every citation resolves in the pinned System of Record release. An unresolved citation fails composition.	AC-5
FR-C5	Must	Cross-major migration requires a versioned migration function, source and destination schema checks, a change report, tests, and renewed affected approvals. A migration note alone never permits incompatible composition.	E-MAJOR fires without a tested migration
FR-C6	Must	Report conflicting identifiers, owners, and the conflicting constraints. Enforce mechanically decidable conflicts automatically. Route unresolved semantic conflicts to designated owners. No language-model opinion can waive a mandatory control.	E-CONFLICT and unresolved-semantic-conflict fixtures
FR-C7	Must	The resolved spec records the selected package versions and their integrity hashes, the customer configuration, the decision, the level, the tool contracts, the data definitions, the loop and graph blocks, the evals, and the unresolved decisions. It links every requirement to its originating layer and to its validation evidence.	Completeness check in the composer test suite
FR-C8	Should	Support a chain of more than one vertical layer, for example accounting then audit. Each link in the chain obeys the tightening rule.	Two-vertical fixture composes
FR-C9	Must	Check composed structural validity and known feasibility bounds. Empty required allowlists, incompatible residency policies, missing mandatory tools, and limits below declared minima fail. Unknown semantic feasibility remains an explicit unresolved decision.	E-FEASIBILITY fixtures

Known scheduler infeasibility also raises E-FEASIBILITY: an interval below the profile minimum, aggregate demand beyond approved account capacity, or an unsupported timing/missed-run guarantee. Missing constrained quota evidence blocks approval. Validate schedules again when the profile or account allocation changes.

Group D: Scaffolding and build

ID	Priority	Requirement	Evidence
FR-D1	Must	Scaffold a worker from an approved resolved spec and an approved build configuration, in the form the target implies.	AC-2, AC-28
FR-D2	Must	Generate host-plugin/claude-code in 1.0; add claude-managed-agents in 1.1 and openai-agents-sdk with one Python profile in 1.2. Codex and Claude Code are development hosts. Claude Cowork and ChatGPT Work are planned Q-CW/Q-W additions with independent release qualification. Other targets and language profiles are unscheduled; Claude Agent SDK is not mandatory.	AC-28, AC-3, AC-2, AC-13
FR-D3	Must	Maintain a capability matrix per target with three states: native, adapter, unsupported. On unsupported, fail closed with the named gap and the spec field that caused it.	E-CAP fires on a fixture
FR-D4	Must	Isolate vendor orchestration calls inside target adapters and target wiring. Business modules, tool contracts, and fixtures must not import vendor SDKs. Adapters expose only the tested common contracts and explicit optional capabilities. A required capability cannot be hidden behind an unverified universal abstraction.	Import-boundary and adapter conformance checks
FR-D5	Must	Generated Python domain modules run on published Python profiles with locked dependencies. Generated TypeScript modules, when supported, pass on the published Node.js/Bun profiles without undeclared runtime-specific APIs. Isolate deployment-specific code and qualify every advertised environment separately.	NFR-11 suite; deployment-specific smoke tests
FR-D6	Must	Composition, eval compilation, and template-driven scaffolding are deterministic given af.lock. Model-generated code is not byte-deterministic. Every generation records the model identifiers, the resolved spec hash, the build configuration hash, the adapter version, and the prompts used, so that a build is explainable and reproducible in its inputs.	Two runs from the same lock produce identical resolved specs and eval suites, and a complete generation record
FR-D7	Must	Credentials never appear in a spec, a build configuration, or generated source. Build configurations hold secret references only. Targets bind credentials at runtime: the host's MCP authentication in the plugin form, environment variables or a secret store on the SDK targets, vaults on the Claude managed target, the equivalent facility on the OpenAI managed target.	AC-16
FR-D8	Must, 1.1	Promotion creates an approved build configuration and regenerates target wiring. Preserve business contracts and approved domain expectations when the new target can satisfy them. Run target-specific deployment, data, permission, and recovery checks. If behavior or a control must change, use the spec-change path and affected reapproval.	AC-3
FR-D9	Must	Check every inference provider used by the selected target and model roles against allowed_providers. Check each constrained data-location category against evidence for all relevant components. Check form eligibility and capabilities. Missing evidence for a constrained category blocks the build.	AC-25, AC-29; E-PROVIDER, E-RESIDENCY, E-FORM
FR-D10	Must	A preview-only capability requires allow_preview: true and an approved capability entry identifying its maturity, limits, and tests. Otherwise fail closed.	E-PREVIEW fixture; AC-27 for managed targets
FR-D11	Must	Python workers pass strict Pyright checking and runtime boundary validation. TypeScript tooling and supported TypeScript workers pass strict compiler checks and runtime validation. Unchecked Any/any, ignored diagnostics, and unsafe casts at boundaries require written justification and cannot bypass mandatory contracts. Run gates locally and in CI.	Deliberately incompatible Python and TypeScript fixtures fail their respective static gates; malformed boundary inputs fail runtime tests
FR-D12	Must	Runtime contracts. Generated workers validate uploaded data, model outputs, tool arguments, and integration responses against explicit schemas before trusted use. Invalid data produces an error that names the failed contract without exposing secrets, or a controlled review path.	Malformed inputs are rejected before any business operation runs
FR-D13	Must	Controlled changes. Every build works in an identifiable change set, preserves unrelated code, and reports the files it generated or modified. The reviewer can inspect one focused diff and rebuild the exact revision from the lockfile.	Diff review on the ref-core build
FR-D14	Must	Build plan and progress. After approval, produce an implementation plan. Progress shows completed work, current work, failures, and decisions needing attention. The developer can interrupt and resume from recorded progress without losing the approved spec.	AC-15
FR-D15	Must	Deployment package. Every advertised target ships a tested deployment path, a configuration schema, secret references, a health check, and operating instructions. For the plugin form the deployment path is the host's marketplace install and, for a rostered worker, the host heartbeat setup. A clean target environment deploys the worker, passes a smoke test, and reports its source revision, spec version, and build configuration version.	AC-18, AC-28
FR-D16	Must	Compile plugin procedures into skills and expose tools through MCP. Map runtime_control bindings to verified host hooks, permission controls, or owned enforcement services. Bind the heartbeat to the selected host profile: Claude Code Routines/CI, Cowork scheduled tasks, or independently verified Work automation and graph execution to a deterministic runner where required. Routines does not itself prove graph or resource enforcement. A plan skill alone cannot enforce dependencies, locks, or approvals. Unsupported controls fail with E-CAP.	AC-28; unsupported-control fixture
FR-D17	Must, 1.1	Surfaces. A process-form or managed-form build may declare surfaces. For each, the adapter produces a plugin that wraps the worker's MCP server and skills, carries the same approval policies, and duplicates none of the worker's logic. A surface is not a second worker.	AC-31

Plugin selection and Routines requirements added in v0.9

ID	Priority	Requirement	Evidence
FR-D18	Must	Evaluate target eligibility first, then recommend plugin, Claude Managed Agents, and OpenAI Agents SDK in that order. Record the selection reason, customer override, unavailable targets, and named capability gaps.	Plugin-fit, plugin-ineligible, OpenAI-only, and unreleased-target fixtures
FR-D19	Must	Generate a Routines deployment profile for compatible Claude Code plugins: versioned repository/plugin source, cloud plugin configuration, trigger and timezone, environment dependencies, least-privilege tool bindings, secret references, output destination, and operating owner. Never claim local installation is a cloud deployment.	Clean-environment load and end-to-end routine run
FR-D20	Must	Qualify required plugin components and runtime controls in Routines; declare preview use explicitly. Preserve durable operation identifiers, overlap/missed-run policy, external run state, bounded retries, budgets, and approval enforcement. Report unsupported guarantees with E-CAP rather than substituting prompt instructions.	Missing dependency, denied tool, duplicate trigger, interrupted run, and approval-bound publication fixtures

Additional work-environment requirements

These obligations apply when the Q-CW or Q-W target/profile is released; they do not add unconditional 1.0 gates.

ID	Priority	Requirement	Evidence
FR-D21	Must, Q-CW/Q-W	Generate destination-specific package metadata, skills, tool bindings, runtime dependencies, installation instructions, and explicit supported profiles from the same approved business specification. Record all host-specific deviations.	AC-33
FR-D22	Must, Q-CW/Q-W	Map loop and graph requirements to verified host capabilities or an owned runner/service. No instruction-only substitute for mandatory control. Identify whether the package executes the worker or is a surface for a backing worker.	AC-34, AC-36
FR-D23	Must, Q-CW/Q-W	Qualify interactive and scheduled execution separately, including plugin activation, credentials, tool access, files, state, limits, and approval behavior. Unsupported scheduling stays unavailable without preventing a qualified interactive release.	AC-35
FR-L6	Must, Q-CW/Q-W	Handover assigns the installer/configurer, service operator, billing owner, credential administrator, state/backup owner, business approver, and incident contact. State customer versus consultant versus vendor duties, recurring charges, and recovery procedure. GIAIC/PIAIC/Panaversity hosting is not implied.	AC-36

Inbound-trigger requirements

ID	Priority	Requirement	Evidence
FR-D24	Must, when an inbound profile is advertised	Declare the actual endpoint product/profile, account prerequisites, authentication, payload schema, trigger response, and result-observation mechanism. Never infer inbound capability from plugin installation or outbound MCP access.	AC-37
FR-J10	Must, when an inbound profile is advertised	Use durable application operation IDs, authenticated state transitions, bounded retry/reconciliation, and duplicate-effect protection. For trigger-only APIs, provide an owned results/completion service and expose unresolved outcomes explicitly.	AC-38
FR-D25	Must, when an MCP worker interface is advertised	Expose versioned input/output schemas and identify the MCP client/server versions, backing runtime, supported invocation/completion behavior, ownership, and operational limits. Treat MCP as an interface capability rather than a new target. Do not infer inbound plugin execution from outbound MCP access.	AC-39
FR-J11	Must, when an MCP worker interface is advertised	Implement durable submission and result observation for long-running jobs, scoped idempotency with conflicting-input rejection, authorization on every operation, and recovery across disconnects and dispatch failures. Apply FR-J10 and existing graph/loop/approval contracts through the backing service.	AC-38, AC-39

Worker identity and communication requirements

ID	Priority	Requirement	Evidence
FR-D26	Must, all generated workers	Generate the approved identity record and a truthful self-description with name, stable ID, AI disclosure, role, limits, sources, channels, owner, and escalation policy.	AC-40 (defined on the First Pilot page)

FR-J12 (durable cases and participant identities across Slack, email, and WhatsApp) and FR-L5 (support-pilot channel delivery and handover) apply to the support pilot only and are defined on the First Pilot page.

Group E: Evaluation

ID	Priority	Requirement	Evidence
FR-E1	Must	Compile the acceptance criteria of the resolved spec into an executable eval suite.	Suite exists for ref-core
FR-E2	Must	Support exact, schema, trace, and rubric oracles. Exact compares an approved expected artifact. Schema validates a referenced output against JSON Schema. Trace uses a versioned assertion grammar without arbitrary code execution. Rubric uses a fixed criterion and threshold with recorded grader context.	One fixture of each oracle in ref-core; E2 oracle contracts
FR-E3	Must	Each adapter implements run(resolvedSpec, buildConfig, scenario), returning a normalized trace reference and terminal status, or a durable pending handle that the harness can resume. The plugin adapter starts an authorized headless destination-host session. The Eval Engine uses only this adapter interface.	Interface conformance and paused-run recovery tests
FR-E4	Must	On every build, run every tier present in the chain: horizontal evals (no tool outside the allowlist, approval gates honored, out-of-scope requests refused, injection attempts rejected, budgets respected), then vertical, customer, and project evals where those layers exist.	AC-2
FR-E5	Must	Definition of done: every present tier passes on the selected target. The plugin reports "built" only then, and reports "not built" with the failing criteria otherwise.	AC-2
FR-E6	Must	Separate maker and checker responsibilities. The checker uses a fresh evaluation context, independent instructions and expected results, and no permission to edit the work or its tests. Deterministic checks are preferred where sufficient. Model diversity is required only by an explicit risk policy and is not itself evidence of independence.	AC-30; checker cannot edit artifacts, fixtures, or thresholds
FR-E7	Must	Fixture integrity. A repair never edits a fixture, an expected result, or a threshold. Changing an expectation requires a spec change and reapproval.	E-FIXTURE fires on a fixture
FR-E8	Must	Fixtures and expected results for vertical and customer evals are reviewed by the domain owner independently of the generated implementation.	Domain owner sign-off recorded in the Project record
FR-E9	Must	Report tokens, wall time, and any managed-tier charges (such as session-hours) per run and per tier.	Cost report present on every run
FR-E10	Must	Narrative evaluations use a fixed, versioned rubric and recorded threshold. Matching prose is not required. Provider-specific wording may differ across targets.	Rubric files and grader settings pinned with the evaluation evidence
FR-E11	Must	Before releasing or deploying a changed schema, package, adapter, model configuration, or generated worker, rerun affected tests and the mandatory common business, security, and target conformance suites for every advertised affected combination. Optional local watch-mode automation does not replace this release gate.	A version bump cannot reuse stale passing evidence; release manifest lists fresh runs
FR-E12	Must	For rostered and autonomous workers, test schedules, stop rules, independent checking, concurrent run-state consistency, durable approvals, declared resource isolation, and irreversible-operation ordering. Compare preserved business behavior across targets and run separate target-specific operational assertions.	AC-30

Group F: Host integration

ID	Priority	Requirement	Evidence
FR-F1	Must	Document installation on Claude Code and Codex CLI in 1.0. OpenCode is an unscheduled extension. Use one command where tested installation permits, and disclose prerequisites separately.	AC-9, AC-26
FR-F2	Must	Package decision knowledge as Agent Skills that conform to the agentskills.io core specification. Host-specific fields are allowed only in host-specific overlays, never in the core skill. The same rule applies to every plugin-form worker and every surface the Scaffold Engine produces.	AC-9, AC-28
FR-F3	Must	Prove decision and spec-authoring workflows on both vendors through the 1.0 development hosts. Publish the tested model configurations. Economy-tier configurations are supported only after the same required behavioral checks pass.	AC-12, AC-13
FR-F4	Should	Expose consistent conceptual entry points: decide, spec, package, approve, build, eval, promote, and handover. Document the exact syntax supported by each host and the release in which each operation is available.	Installation guide and entry-point comparison
FR-F5	Must	All advertised hosts must satisfy the same mandatory behavioral contracts. Presentation and installation may differ. Publish tested differences and unsupported capabilities.	Host gap list and compatibility evidence
FR-F6	Must	One source tree serves Zia on its released development hosts. Generated workers and surfaces include overlays only for their released execution hosts: a shared skills/ folder, one shared MCP server declaration, and one thin manifest overlay per host. No skill content is duplicated per host.	Repository layout check
FR-F7	Must	Development hosts and execution targets are independent. Claude Code and Codex CLI each build and evaluate the Claude Code plugin target in 1.0; add managed coverage in 1.1 and OpenAI SDK coverage in 1.2. Building or evaluating a Claude Code plugin from Codex still requires a Claude Code executable and authorized credentials for that target.	AC-12, AC-13, P10
FR-F8	Must	The plugin's MCP wiring, and the MCP wiring of every plugin-form worker and surface, points at remote (hosted) MCP servers or bundled servers with relative paths, and never depends on host-specific path variables.	Plugin loads with no path variables
FR-F9	Must	Respect the host sandbox and approval policy on every supported host. Never require an approval bypass for a build or evaluation.	Unauthorized tool action denied on each host; AC-16
FR-F10	Must	Host capability declaration. Each host declares its tested surfaces and versions (see E8), its scheduling mechanism for heartbeats, its subagent and hook support, restrictions, and optional features. Only tested host and target combinations are advertised.	Published compatibility table

Group G: System of Record access

ID	Priority	Requirement	Evidence
FR-G1	Must	Read the System of Record over MCP with version pinning. Minimum tool surface: list_spec_versions(), get_spec(version), resolve_citation(anchor, version).	MCP conformance test
FR-G2	Must	Never read "latest" implicitly. A project's af.lock pins the System of Record release, every package version with its integrity hash, every adapter version, the approved spec hash, and the approved build configuration hash. Missing dependencies are reported before implementation begins.	Lock inspection on ref-core
FR-G3	Must	Evidence availability. When the System of Record is unreachable and no verified local snapshot covers the pinned release, any decision that needs a citation pauses and is marked unresolved. Other work continues. No citation is invented and no other version is substituted.	AC-17
FR-G4	Should	Cache the pinned release locally so that decide, spec, and compose work offline after the first fetch.	Offline run after a fetch

Group H: Records

ID	Priority	Requirement	Evidence
FR-H1	Must	Knowledge record: the pinned System of Record release and the vertical and customer package references in use.	Record file validates against its schema in CI
FR-H2	Must	Identity/Praxis record: the gate order, the gate questions, the level rules, and the explanation voice. Versioned.	Record file validates against its schema in CI
FR-H3	Must	Developer record: only facts the developer stated (default target, preferred region, naming conventions). No inferred facts.	Record file validates against its schema in CI
FR-H4	Must	Project record: gate answers with citations, the level, every spec version produced, every build configuration, every approval (hash, reviewer, decision, timestamp), both data-handling statements, build progress, every eval run with its verdict and cost.	Record file validates against its schema in CI

Group I: Fail-closed gates

Each gate emits a structured error that the host coding agent can act on: an error code, the offending field or citation, and the one action that clears it.

Code	Condition	Behavior
E-SCHEMA	Front matter or build configuration does not validate	Stop. Report the field and the schema rule.
E-GATE	A required decision is unresolved	Ask a focused question or a small related group. Block only dependent approval/build work.
E-NOT-AGENT	The problem fails the "Is This an Agent Problem?" gate	Stop agent manufacturing, cite the reason, and return the conventional-automation recommendation and implementation brief in Section 1. This routing outcome does not end useful assistance.
E-LOOSEN	A lower layer tries to loosen a control	Stop. Report the field, both layers, and the rule.
E-OVERRIDE	A lower layer replaces a default the parent did not mark overridable	Stop. Report the field and the permitting layer, if any.
E-CONFLICT	Two applicable requirements conflict	Stop. Report both identifiers and their owners.
E-CITE	A citation does not resolve in the pinned release	Stop. Report the anchor and the release.
E-EVIDENCE	The System of Record is unreachable and no verified snapshot covers the pinned release	Pause the affected decision. Mark it unresolved. Continue other work.
E-MAJOR	A cross-major package lacks a tested migration	Stop. Require the migration function, schema checks, change report, and affected approvals.
E-APPROVAL	Build requested on a spec version or build configuration that is unapproved or superseded	Stop. Report the approved versions, if any.
E-CAP	The target cannot express a spec field, a loop element, or a graph element	Stop. Report the field, the target, and the matrix state.
E-FORM	The selected form lacks required lifecycle or runtime guarantees	Stop. Report the missing capability and eligible tested alternatives.
E-PROVIDER	The build configuration's target uses a provider outside allowed_providers	Stop. Report the provider and the control.
E-RESIDENCY	A constrained data category has conflicting or unknown location evidence	Stop. Name the category, component, constraint, and missing evidence.
E-NO-EVAL	No acceptance criterion, or an irreversible tool without a trace assertion	Stop. Report the tool or the missing tier.
E-FIXTURE	A repair attempts to change a fixture, expected result, or threshold	Stop. Report the eval. Point to the spec-change path.
E-TYPES	The required Python or TypeScript static check fails	Stop. Report the diagnostics. Never suppress them.
E-PREVIEW	A preview-only capability is used without allow_preview: true	Stop. Report the capability.
E-ISOLATION	A retrieval or write crosses a project or customer boundary	Deny. Report the boundary. Log the attempt.
E-SECRET	A credential-shaped value appears in a spec, build configuration, generated source, package, or export	Stop. Report the location. Never write the file.
E-FEASIBILITY	A composed contract violates a known minimum or requires unavailable resources	Stop. Report the incompatible constraints and their owners.
E-GRAPH	A graph has invalid references, cycles, missing bindings, or inadequate approval dependencies	Stop. Report the nodes and graph rule.
E-RESOURCE	Declared parallel accesses conflict or a runtime access is undeclared	Reject the graph or deny the access. Record the resource and node.
E-SCHEDULE	Schedule expression, time zone, missed-run, overlap, or deduplication policy is missing or invalid	Stop. Name the missing or invalid trigger field.

Group J: Operations of the generated worker

ID	Priority	Requirement	Evidence
FR-J1	Must	Keep authoritative business state outside model context and provider sessions. The loop spine stores run state and references business records. Both may share a database with separate logical ownership and access controls. Provider sessions alone are never the authoritative transaction record.	Storage and access-control tests
FR-J2	Must	Every side-effecting operation has a stable identifier scoped by customer, worker, and logical request. Enforce uniqueness at the committing service or a durable operation ledger. A timeout with an unknown external outcome triggers reconciliation before retry. An identifier alone is not a guarantee against duplicate external effects.	AC-15; response-loss, duplicate-dispatch, and reconciliation fixtures
FR-J3	Must	A failed external call is never represented as a successful business action.	Fault suite
FR-J4	Must	Every deployment records run status, tool activity, errors, usage, and available cost. It supports cancellation, bounded retries, and task budgets. Budgets are declared in the spec, verified by the horizontal evals, and enforced at runtime by the adapter, never by model instructions. In the plugin form, enforcement uses host limits plus hooks, and the matrix says which.	Fault injection reaches the retry limit. Cancellation dispatches no new work. A budget breach halts the run.
FR-J5	Must	Transient errors are distinguished from permanent errors. Progress is persisted in a recoverable form. No workflow can loop without bound.	Fault suite
FR-J6	Must	The fault suite covers timeouts, rate limits, lost connections, malformed tool results, and process interruption. Every case ends in a recoverable state or a clear failure.	AC-15
FR-J7	Must	GIAIC/PIAIC/Panaversity knowledge MCP is a development dependency unless the approved worker specification explicitly requires runtime access.	Dependency inspection and disconnected-runtime test
FR-J8	Must	Side effects in the plugin form. Side effects on business systems go through MCP tools the plugin owns, never through the host's general shell or file tools, so that operation identifiers and approval policies apply. Side effects on a repository go through a change set keyed by the operation identifier (a branch, commit, or pull request), never a direct push to a protected branch.	Trace assertion: no business write outside owned tools. Repository test: two runs with one identifier produce one pull request.
FR-J9	Must	Enforce graph dependencies, declared resource access, and durable approvals in runtime code or an owned service. Bind an approval to the operation, input digest, spec/build version, reviewer, and expiry. Restarting a process cannot bypass it.	AC-30
FR-J13	Must, support pilot and any public inbound channel	Declare and enforce inbound-volume and cost limits per customer, per conversation, and per day for workers reachable on public channels, separately from the per-run budget in FR-J4. Exceeding a limit produces a clear, non-answering hold or escalation, never silent drops or unbounded spend.	P02 flood fixture (defined on the First Pilot page); budget report per channel

FR-J10 and FR-J11 are defined in the inbound-trigger subsection of Group D above and apply here with the same priority and evidence. FR-J12 is a support-pilot requirement defined on the First Pilot page.

Group K: Governance, approval, isolation, and data handling

ID	Priority	Requirement	Evidence
FR-K1	Must	A resolved spec version is approved by its designated reviewers before any build. The Project record stores the spec hash, the reviewer identity, the decision, and the timestamp. For a project without a customer layer, the developer is the reviewer.	AC-19
FR-K2	Must	A material change to the spec (business behavior, a control, a tool with side effects, the level, the loop or graph block) invalidates the affected spec approval and requires reapproval. Unrelated edits do not reopen previous decisions.	AC-19
FR-K3	Must	Change impact. A proposed update to any layer shows the changed requirements, the affected code and tests, the deployment implications, and the approvals that need renewal. Deployed versions stay pinned until an authorized upgrade.	Updating the horizontal package creates a change proposal and does not alter the running pilot
FR-K4	Must	Isolation. Retrieval and storage are restricted by project and customer authorization. Reusing a vertical or customer package never copies customer records, secrets, or private configuration into another project or a shared package.	AC-16
FR-K5	Must	Runtime data-handling statement. For every build configuration, the adapter generates a statement of what data reaches each provider, where business records reside, retention and deletion behavior, and customer restrictions. In the plugin form the statement names the host provider and the host's cloud or CI where a heartbeat runs. A self-hosted sandbox is never described as fully local model processing.	Statement present in the handover. A deletion exercise verifies application-controlled records and documents provider limits.
FR-K6	Must	Routine authorized implementation and repair continue without repeated confirmation. Operations outside existing authorization require the designated review.	Authorization policy and workflow tests
FR-K7	Must	Approve each build configuration before use. The technical reviewer checks target evidence and operating settings. The customer reviews changed data flows. Promotion preserves spec approval only while behavior and controls remain unchanged and the destination passes its required checks. For personal projects the developer fills both review roles.	AC-19
FR-K8	Must	Before accepting customer material, disclose the development host, model providers, and the categories that may be transmitted or retained during intake, retrieval, generation, and evaluation. The customer approves this statement before the relevant transfer. Enforce project boundaries and exclude customer material from shared packages and knowledge stores. Personal projects use developer approval.	AC-23
FR-K9	Must	Evaluate data-location constraints separately for execution, business storage, session records, memory stores, and logs, with inference-location restrictions when required. Record provider evidence and unknowns. A self-hosted sandbox is not blanket residency evidence.	AC-25

Group L: Handover and export

ID	Priority	Requirement	Evidence
FR-L1	Must	The handover contains: a readable introduction and the approved resolved spec with linked sources and versions, the approved build configuration, both data-handling statements, the decision record with the level, the tool and data contracts, the customer configuration schema, the worker in its form (plugin package, source with lockfiles, or managed configuration) with environment templates that contain no secrets, every surface, the tests, fixtures, rubrics, and traceability report, the eval evidence per target, and the deployment, heartbeat, secret setup, monitoring, budget, recovery, and rollback instructions.	Handover checklist on the pilot
FR-L2	Must	Export specs, build configurations, plugin packages, source, schemas, tests, and instructions in documented formats. Portable contracts must not depend on provider session identifiers. Operational evidence may retain such identifiers as labeled, access-controlled diagnostic metadata, with redaction on normal exports.	Export inspection and clean-target reconstruction
FR-L3	Must	A reviewer can reproduce the pilot evaluation from the handover alone and identify the exact source revision and build configuration proposed for deployment.	AC-18
FR-L4	Must	The traceability report lists every mandatory requirement as covered, failing, or unverified. A mandatory requirement without evidence blocks release.	Release report

FR-L6 (work-environment handover ownership) is defined in Group D above. FR-L5 (support-pilot channels) is defined on the First Pilot page.

E6 Non-functional requirements

ID	Priority	Requirement
NFR-1 Portability	Must	In 1.0, ref-core passes common business fixtures in interactive, CI, and qualified Routines plugin profiles, built from both development hosts. This proves host/profile compatibility, not cross-vendor runtime portability. In 1.1 repeat on Claude Managed Agents; in 1.2 repeat on OpenAI Agents SDK. Preserve business contracts and require each target’s own operational evidence.
NFR-2 Determinism	Must	Composition, eval compilation, and template-driven scaffolding are deterministic given af.lock. Model-generated output is explainable through its recorded inputs (FR-D6).
NFR-3 Security	Must	Generated workers start from least privilege: a closed tool allowlist and deny by default for anything outside it. Generated source, packages, logs, and exports pass a secrets scan. Permission and approval checks are enforced by the host, the application, or the service, never by prompt text alone.
NFR-4 Residency and providers	Must	Data-location controls apply per category in E2 and E6. The build inventory includes all components that execute, store, process, or receive constrained data. Self-hosted tool execution does not establish where vendor session records, memory, or logs reside. Unknown evidence cannot satisfy a constrained category. allowed_providers controls inference vendors separately from location.
NFR-5 Cost transparency	Must	Report provider usage, host access or subscription costs, hosting, and integration costs separately. A local learner deployment must not require a GIAIC/PIAIC/Panaversity hosting fee. Do not promise token-only total cost. Publish prerequisites and measured usage for the supported path.
NFR-6 Managed-tier isolation	Must, 1.1	Isolate managed API calls in versioned adapters. Pin required headers and supported resource versions. Nightly live contract tests exercise ref-core and ref-preview for each applicable managed target. Drift blocks new adapter releases and alerts operators of affected deployments. This does not prevent vendor changes from affecting live services.
NFR-7 Observability	Must	Every scaffold emits trace events in the normalized trace format, including checkpoint and stop-rule events. The format has an exporter to OpenTelemetry.
NFR-8 Readability	Must	Developer-facing explanations use clear American English suitable for ESL readers. Explain technical terms when first used and keep domain reviewers out of unnecessary implementation detail. Evaluate comprehension through usability tests rather than punctuation rules alone.
NFR-9 Usability	Must	At least eight of ten learners complete decide, spec, build, and eval on host-plugin/claude-code in two hours after access setup, without assistance beyond product guidance. Report outcomes for all ten, including assistance, failures, and setup time. At least four of five consultants finish intake and identify the approval boundary within 30 minutes.
NFR-10 Performance and cost evidence	Must	Use at least 20 fixed pilot attempts per advertised execution target. Report successful-run median and p95 duration and cost, success rate over all attempts, total cost divided by successful completions, and failed-attempt costs separately. No successful completions means cost per success is undefined. Record workload and environment. Investigate provisional goals of five minutes to resolved spec excluding human response time, and three minutes for scaffolding.
NFR-11 Runtime portability	Must	Test every advertised language/runtime profile independently. Python workers use pinned interpreter and dependency versions. Qualified TypeScript profiles test Node.js and Bun as advertised. Shared business fixtures apply across profiles; deployment, serialization, decimal handling, lifecycle, filesystem, and networking require profile-specific evidence. Node.js compatibility alone is not Cloudflare Workers support.
NFR-12 Licensing	Should	The horizontal schema, the composer, and the adapters are open source. The license, customer ownership rights, and support responsibilities are open decisions (see Section 5 decision record and Section 9 remaining decisions). The book's content license is unchanged.
NFR-13 Telemetry	Must	The plugin sends nothing to GIAIC/PIAIC/Panaversity by default. Usage telemetry is opt-in per project, declared in the build configuration, limited to documented fields, and never includes customer material, spec content, or secrets. Generated workers and surfaces send nothing to GIAIC/PIAIC/Panaversity unless the approved spec declares it.

E7 Capability evidence matrix

The following is a verification plan, not a claim of validated support. Each implemented cell records implementation state (native/adapter/unsupported) separately from evidence state (unverified/documented/tested), version, source, maturity, and test run. A source says a vendor capability exists. A passing integration test says the Zia mapping works. Unknown is never treated as supported.

Contract	Claude Code plugin target	OpenAI Agents SDK Python profile	Managed targets
Business/tool schemas	Verify owned MCP mapping and external validation	Verify adapter mapping	Verify custom-tool and MCP mapping
Approvals and runtime controls	Verify enforcement before first protected operation. For Routines, use owned enforcement until exact-version hook activation is proven; deny bypass paths.	Verify approval/service and durable-record mapping	Verify platform policies plus owned durable records
Graph/resources	Verify deterministic runner and enforced resource access	Verify runner/bindings/access controls	Verify capability-by-capability
Scheduling	Prefer qualified Claude Code Routines; CI is an alternative. Verify loading, scheduler behavior, durable claims, and deduplication.	External scheduler plus durable claim	Verify schedule API and semantics
Run state and recovery	Owned store and operation ledger	Owned store and operation ledger	Owned business/run records; do not rely solely on sessions
Budgets/cancellation	Verify host limits plus enforcement services	Verify adapter controls	Verify actual platform limits and in-flight behavior
Data categories	Record managed/self-hosted Routines route; assess execution, inference, session, logs, tools, and stores separately	Assess every model/tool/store component	Self-hosted execution is not blanket residency evidence
Autonomous-service support	Outside 1.x plugin baseline	Required where advertised and tested	Conditional on verified lifecycle support

TypeScript SDK profiles require separate columns and evidence when qualified. A Python feature or test pass does not establish TypeScript feature parity, or vice versa.

Each unsupported mandatory capability fails with E-CAP. Pin all actually supported protocol and product versions at the relevant milestone. Generated Codex and OpenCode plugin targets are unscheduled and enter this matrix only after qualification. The OpenAI managed target remains entirely conditional. No unsupported host feature may be simulated by a prompt and represented as an enforced control.

Evidence matrix for added plugin destinations

Capability	Claude Cowork	ChatGPT Work
Plugin packaging	Documented ecosystem; generated package not yet tested	Documented ecosystem; generated package not yet tested
Interactive skills/tools	Qualify actual package, connectors, permissions, and account	Qualify actual package, MCP/apps, permissions, and account
Scheduling	Documented plugin use in Cowork scheduled tasks; integration untested	Scheduled plugins and skills documented for Work web and desktop [38]; Zia integration untested
Loop/graph controls	Verify owned runner/service or native binding per control	Verify owned runner/service or native binding per control
Durable state and approvals	Record store and enforce authenticated operation-bound decisions	Record store and enforce authenticated operation-bound decisions
Data and isolation	Assess selected local/remote profile and all connected services	Assess selected Work environment and all connected services

All cells remain untested for Zia until Q-CW/Q-W evidence exists. Desktop and web profiles are not interchangeable by assumption. Qualification may release interactive use while keeping unattended use unavailable.

E8 Development-host declarations

Host	Release	Initial surface	Required evidence
Claude Code	1.0	CLI	Installation, skills/MCP, permissions, review/build/resume/eval/handover for the Claude Code plugin target
Codex	1.0	CLI	Same mandatory flow, including authorized Claude destination-host execution; OpenAI-only path follows in 1.2
OpenCode	Unscheduled	CLI	Same contracts for every advertised combination; verify installation and host capabilities independently

Desktop and IDE surfaces require their own compatibility evidence. Do not infer scheduler, subagent, hook, manifest, or path-expansion parity across hosts. Package shared skills and knowledge with thin host overlays. Test relative bundled paths and remote MCP endpoints instead of relying on another host's path variables.

E9 Versioning, locks, and approval integrity

Use semantic versions for schemas and packages, exact versions and content hashes in af.lock, and stable requirement IDs. Record each language profile, interpreter/runtime version, static checker, validator version, and dependency lock. Python environments and TypeScript environments have separate reproducible installation instructions. The lock includes the composer/schema/eval compiler, all source packages, adapters, artifact references, instruction/fixture/rubric files, scheduler profiles, and approved resolved-spec/build hashes. Record generation prompts and model configuration with secret and customer-data protections. Recorded inputs make generation explainable, not byte-deterministic.

The resolved-spec content hash excludes runtime results, approval records, and evaluation evidence to avoid circular hashes. Evidence references the approved hash from a separate Project record. Source composition is deterministic. Different build configurations can reference one unchanged approved contract. Deployment is pinned and never silently updated to latest.

Source citations resolve within immutable pinned releases. Redirects are versioned. A new horizontal version does not alter existing deployments. Cross-major migrations need tested transforms, readable changes, and renewed affected approvals. Exports include portable contracts and reproducible setup, with optional access-controlled diagnostics separated from required business state.

E10 Reference workers

ref-core is synthetic and owned by GIAIC/PIAIC/Panaversity. It is a rostered worker: a Mode 2 workflow with a scheduled heartbeat, a loop block, a graph with one parallel group, one irreversible tool behind a human checkpoint, and no preview-dependent business requirement. Its non-preview execution baseline uses a qualified CI heartbeat. A separate Routines build configuration explicitly sets allow_preview: true while Routines remains in preview; the business fixtures stay unchanged. It exists to exercise the non-preview cells of the capability matrix, the loop and graph assertions (FR-E12), the portability gate (NFR-1) across the released profiles and targets in NFR-1, and the contract tests (NFR-6).

ref-preview (1.1) adds delegation to named workers and any other capability that is preview-only on a managed target, with allow_preview: true. It exists to exercise the preview cells while ref-core retains target-specific preview declarations where required.

The GIAIC/PIAIC/Panaversity support pilot, Zia Khan — GIAIC/PIAIC/Panaversity AI Support, is the first customer-facing worker. Its approved scope, identity, channel staging, M0 exit criteria, and pilot tests P01 to P11 are defined on the First Pilot page. Production operation requires its own approved rollout. Synthetic fixtures remain separate from production records.

ref-core uses a synthetic education-support case: parallel reads of course facts and admissions policy, an independently checked answer, a durable human checkpoint, and a protected send to a test destination. Its heartbeat checks pending cases. The illustrative accounting schemas elsewhere remain examples for later numerical conformance, not the first pilot or an accounting release commitment.

Accounting remains a later reference case, with release assignment pending. Retain exact decimal handling, independent numerical checks, and accounting examples as reusable engineering contracts; do not require a deployed accounting pilot to release this support worker.

E11 Release acceptance

Version 1.0 is done when every criterion below passes.

ID	Criterion
AC-1	Zia Developer AI's own agent.spec.md (an assistant-level plugin) validates against horizontal schema 1.0.0, composes without error, builds through host-plugin/claude-code, and the plugin passes every acceptance criterion in its own spec.
AC-4	Composition rejects child loosening, unauthorized replacement, incompatible limits, empty required provider sets, and contradictory identified obligations. It accepts inherited required fields and a permitted new field. An arbitrary prose rewrite is routed to the versioned change process.
AC-5	A spec that cites a non-existent anchor fails composition with E-CITE.
AC-6	An underspecified request produces a focused question or up to three related questions with consequences. Unrelated drafting continues. Resuming retains answers. A complete brief triggers no redundant gate questions.
AC-7	A fixed-rule calculation or scheduled export routes to E-NOT-AGENT with a citation, produces a conventional-automation recommendation and implementation brief, and generates no agent scaffold. Ambiguous business rules remain explicit questions rather than invented policy.
AC-9	The plugin installs on Claude Code with one command, and the core skills pass agentskills.io validation.
AC-10	At least eight of ten learners finish the default Claude Code plugin workflow in two hours after prerequisite setup without assistance beyond product guidance. Report completion, assistance, setup effort, and failures for all ten.
AC-11	The education-support vertical package validates (FR-B10), composes on top of horizontal 1.0.0, and adds at least three domain evals that the horizontal tier does not cover.
AC-14	A consultant completes the pilot intake from the supplied business material, and the plugin produces a structured brief that lists assumptions and missing information. At least four of five consultants finish within 30 minutes.
AC-15	Operations: interrupting and resuming the pilot preserves task status and produces no duplicate persistent result for the same operation identifier. Fault injection reaches the configured retry limit. Cancellation dispatches no new work. A budget breach halts the run. Every fault suite case ends in a recoverable state or a clear failure.
AC-16	Security and isolation: an unauthorized write is rejected, an injected instruction in source material is rejected, a cross-customer retrieval is denied, and no seeded secret appears in specs, build configurations, generated source, plugin packages, logs, or exports.
AC-17	With the System of Record unreachable and no snapshot, a decision that needs a citation pauses with E-EVIDENCE, no citation is invented, and unrelated work continues.
AC-18	A clean environment deploys the plugin pilot in every 1.0 deployment profile, passes the smoke test, and reports source, spec, and build versions. A reviewer reproduces its evaluation from the handover alone. Repeat on later targets when released.
AC-19	Record spec and build approval hashes, roles, identities, and timestamps. Material behavior/control changes reopen affected spec approval. New deployment settings require build approval and changed data flows require customer review. A promotion that cannot preserve behavior cannot reuse spec approval. Personal projects record the developer as the relevant reviewer.
AC-20	Numerical correctness: the synthetic numerical fixtures on ref-core and the language-profile checks pass the approved rounding and reconciliation cases, reject incompatible currencies, and distinguish unknown values from zero. This evidences FR-B8 without requiring a deployed accounting pilot; the accounting reference case remains release-unassigned.
AC-21	Report time and cost over at least 20 fixed attempts per execution target, using the separate success, failure, and cost-per-success definitions in NFR-10. A release cannot omit failed attempts from success rates or total-cost accounting.
AC-22	A Mode 1 case produces a cited playbook without a new service scaffold. A Mode 2 interactive assistant builds as a reusable plugin in 1.0. Both remain assistant level; repeat SDK form coverage in 1.2. The on-demand variance example must not be labeled a Digital FTE solely because it uses tools, a graph, or reusable packaging. The recurring reconciliation example requires the rostered-worker controls; scheduling a fixed export alone does not justify that classification.
AC-23	The development-time data-handling statement exists, names the host provider, and was approved before intake. The intake transcript for the pilot contains no request for production records.
AC-24	A package with a loosening, unresolved citation, or acceptance criterion without an owner fails validation. Approved education-support package evals run against an independent sample implementation. This execution requirement is mandatory for the released support package.
AC-25	Reject an unapproved inference provider, disallowed business-store location, unknown constrained session location, and a self-hosted execution configuration whose vendor memory location lacks required evidence. Accept an unconstrained category explicitly recorded as such.
AC-28	ref-core builds as host-plugin/claude-code, installs from a marketplace with one command, and passes every present eval tier with a qualified CI heartbeat for the non-preview baseline, and with a qualified Claude Code Routine under a separately approved preview-enabled build configuration. Both use the same business fixtures; Routines is the preferred deployment when customer preview policy permits it.
AC-29	Classify mode, level, triggers, and capabilities independently. Permit a Mode 2 interactive assistant on the plugin target; repeat SDK coverage in 1.2. Reject an autonomous service on a 1.x plugin execution target and a rostered plugin without a heartbeat binding. Reject missing loop and schedule fields for rostered workers.
AC-30	On every 1.0 target: reject cycles and conflicting declared parallel resources; deny undeclared runtime writes; allow duplicate execution attempts but prevent duplicate committed business effects per logical period; apply missed-run and overlap policies; stop a no-progress run; prevent checker edits; survive restart at a human checkpoint; reject wrong-operation or stale approvals; keep concurrent run state consistent; and prevent irreversible work before operation-bound approval.
AC-13	Version 1.0: Claude Code and Codex CLI each complete the flow for host-plugin/claude-code: two mandatory host/target combinations. Both cover interactive and qualified scheduled profiles using authorized destination-host access. Repeat the flow for each target as it is added in 1.1 and 1.2.
AC-26	Version 1.0: Zia installs on Codex CLI from shared source with documented prerequisites and permission checks. OpenCode acceptance is reserved for an unscheduled extension.

Version 1.1 is done when every criterion below passes.

ID	Criterion
AC-3	Promote ref-core through a new approved build configuration to claude-managed-agents when its capabilities and data evidence qualify. Preserve business contracts and fixtures, rerun common and target-specific suites, and fail promotion if required guarantees are unavailable.
AC-8	The nightly contract test for each managed target exists, runs in CI, and has failed at least once on purpose (a deliberate break) to prove it detects drift.
AC-27	ref-preview scaffolds and passes its evals on claude-managed-agents with allow_preview: true, and fails with E-PREVIEW without it.
AC-31	The support pilot's Claude Code surface installs, exposes the worker's tools and skills with the worker's approval policies, and contains no duplicated worker logic.

Version 1.2 additionally requires:

ID	Criterion
AC-2	Version 1.2: ref-core scaffolds and passes every present eval tier on the Python openai-agents-sdk profile. Claude Agent SDK is not required.
AC-12	Version 1.2: on Codex CLI, decide, spec, build, and eval complete for openai-agents-sdk without Anthropic credentials. Published economy configurations pass the same gates.

Unscheduled extension acceptance:

ID	Criterion
AC-32	ref-core builds as host-plugin/codex and as host-plugin/opencode, installs on each host, and passes every present eval tier with each host's declared heartbeat mechanism. Every "verify" cell in the host-plugin column is resolved for both hosts.

AC-26 retains an unscheduled OpenCode extension obligation. All mandatory requirements in E5 and E6 need evidence even when they have no dedicated AC row. The schema and example checks in E2, composition fixtures in E3, and release regression gate FR-E11 are mandatory.

Language-profile acceptance added in v0.8

For 1.0, run these checks on generated Python business tools where present. In 1.2, apply all SDK acceptance criteria and pilot cases to the Python OpenAI SDK profile. Demonstrate strict type-check failure on an intentionally incompatible call, runtime rejection of malformed tool/model output, exact decimal serialization without a floating-point round trip, and reconstruction from the interpreter/dependency lock. Monetary amounts crossing JSON boundaries use decimal strings plus currency and rounding metadata, or an explicitly agreed scaled-integer contract. Never infer monetary correctness from the language or validator alone.

Before a TypeScript worker profile is advertised, repeat common business/security suites on that profile, compare JSON Schema validation fixtures with the Python profile, and pass its own deployment/recovery checks. Reuse approved specifications and expected results, not necessarily source code. Model provider, development host, SDK framework, and implementation language remain independently selected and recorded.

Routines-profile acceptance added in v0.9

These checks are mandatory for the 1.0 Routines profile and supplement AC-28 to AC-30:

1. Load the pinned generated plugin in a clean routine environment and demonstrate invocation of its required skill and tools; fail clearly for unavailable dependencies or plugin sources.
2. Run the support fixture through both interactive plugin execution and Routines. Compare independent business expectations, not exact model prose, and record the plugin/spec/build versions.
3. Exercise the advertised trigger types. Confirm logical period/timezone handling and the chosen missed-run/overlap policy. Duplicate triggers must not duplicate business effects.
4. Demonstrate secret exclusion, denied unauthorized operations, interruption/recovery, durable approval checks, and a clear failure when an essential control is unavailable.
5. Validate business outputs and surface task failure even when the host reports a successful session. Provide run inspection, disablement, recovery, update, and rollback instructions.
6. Reject a 15-minute recurring schedule and an aggregate account workload above approved capacity. Test quota exhaustion and missed-run handling. Verify first-operation enforcement after fresh installation, restart, and update, including attempted bypass.
7. Record account prerequisites, preview acceptance, deployment data flows, measured setup/run costs, and current service limits. Do not claim capability parity for Codex plugins or other schedulers without their own evidence.

Cowork and ChatGPT Work acceptance

ID	Criterion
AC-33	For each destination, both development hosts generate the package; installation on the real destination loads required skills and tools. Run the common support fixtures and compare approved business outcomes. Record account, host/profile version, installation route, and any manual steps.
AC-34	Exercise sequential dependencies, parallel reads, malformed inputs, checker failure, premature publication, duplicate attempts, and restart at a pending approval. Reject expired, wrong-operation, or agent-fabricated approvals. Mandatory controls must operate before the first protected action with bypass paths denied.
AC-35	Before advertising scheduling, run the plugin through that host’s actual scheduler. Verify tool authorization, activation, persistent state, permitted file access, quotas, cancellation, and missed/overlapping runs. Cowork uses its own scheduling profile. Work platform support is documented [38], but Zia integration remains untested until this criterion passes. Explicitly invoke the selected skill, verify web-accessible inputs and cross-run state, and test missing/revoked access. Qualify local-file desktop prerequisites separately. Never inherit Claude Code Routines evidence.
AC-36	A reviewer reconstructs the deployment and identifies every component’s location, operator, costs, credentials, durable records, and failure/recovery owner. Where a backing service is used, disconnect it and confirm a clear failure rather than false completion. Assess all constrained data categories and provider policies for the full chain.

Inbound-trigger acceptance

These checks apply to each advertised API or MCP inbound-trigger profile; Q-WA does not add an unconditional 1.0 gate.

ID	Criterion
AC-37	Authenticate a valid caller and reject missing, invalid, expired/revoked, or unauthorized credentials as applicable to the profile. Validate inputs and customer scope. Trigger the real worker and record the actual response semantics. Verify account eligibility and the configured skills/tools. Unsupported Cowork or ordinary Work endpoints are never offered as available.
AC-38	Complete an operation through its actual graph and loop, including a human checkpoint where required. Retrieve the business result through the declared mechanism. Test duplicate submission, timeout with uncertain acceptance, missing completion callback, unauthorized callback, wrong-customer/operation IDs, and replay. No accepted response is reported as completed work; no duplicate committed effects occur.
AC-39	On each advertised MCP client/server and backing-runtime profile, discover the tool and invoke the actual worker. Validate input/output schemas, unauthorized submission and result access, scoped duplicate submission, conflicting inputs, disconnect after acceptance, crash during dispatch, and recovery of status/results. Verify pending work is never reported complete and graph/loop/approval controls remain effective. For an API bridge, also pass AC-37 and AC-38 against the real destination; an unavailable plugin trigger must remain unavailable.

Support identity and channel acceptance

AC-40 to AC-42 are the support pilot's identity, coordination, and channel acceptance criteria. They are defined on the First Pilot page and are required for M0 and M4 as stated there.

E12 Source register

Source register carried forward from v0.6, with targeted checks during the v0.7 review on September 12, 2026. Original verification labels below describe the earlier draft, not a claim that this revision rechecked every page. References [23] to [30] record sources consulted during the language review. The Python adoption statistic is not an agent-developer market share. A citation to a platform capability does not establish that the planned integration is implemented or tested. The verification column records the depth of the check: fetched means the page was retrieved and read in full, located means the page was found through a search and its summary read, located (SoR) means the passage was retrieved through the System of Record's own search, carried over means the entry comes from the Astra draft and was not re-checked for this version.

Ref	Source	Used for	Verification
[1]	Zia Developer AI product page	Positioning, hosts, fail-closed promise, System of Record	fetched
[2]	Claude Managed Agents overview	Agents, environments, sessions, vaults, beta status, self-hosted sandboxes	located
[3]	Claude self-hosted sandboxes	The boundary between customer-hosted execution and provider-managed orchestration	carried over
[4]	Claude Agent SDK overview	Query options, permissions, hooks, custom tools, subagents, sessions	located
[5]	OpenAI agent runtimes comparison	The separate roles of the Agents API, the Agents SDK, and the Responses API	located
[6]	OpenAI Agents API overview	The managed runtime's agent concept, sandboxes, subagents, billing	located
[7]	OpenAI Agents SDK for TypeScript	Primitives, Zod v4 requirement, MCP, human-in-the-loop, provider adapters	located
[8]	Agent Skills	The open skill format	carried over
[9]	Codex skills	Skills build on the open standard. Invocation and surfaces.	located
[10]	Codex plugins	Plugin marketplaces, bundled skills and MCP servers, host sandbox and approval policy	located
[11]	Bun joins Anthropic	Ownership and the MIT license commitment	located
[12]	Bun file types and TypeScript	Bun removes type syntax and does not type-check	carried over
[13]	TypeScript for Java and C# programmers	Structural typing and type erasure	carried over
[14]	JavaScript Number reference	Floating-point limits behind the monetary-value rule	carried over
[15]	Model Context Protocol architecture	Tools, resources, transports, negotiated capabilities	carried over
[16]	Loop Engineering: A Crash Course	The definition of loop engineering, the loop parts (heartbeat, spine, maker and checker, stop rules, isolation, re-runnable orchestration, portable runtime), and the loop block	located (SoR)
[17]	Graph Engineering: A Crash Course	The three meanings of graph engineering, the execution graph taught in full, the memory graph, multi-loop wiring, and the graph block	located (SoR)
[18]	Digital FTE Crash Course	The Digital FTE method behind the level ladder	located (SoR)
[19]	Agent Factory glossary	The Digital FTE definition: continuous work, hired, assigned, rostered, retired	located (SoR)
[20]	Codex product page	Scheduled Codex tasks as a heartbeat mechanism	located
[21]	ChatGPT and Codex skills and plugins	Plugins bundle skills and MCP servers and can include lifecycle hooks for the Codex runtime	located
[22]	Cloudflare Workers Node.js compatibility	Partial Node.js API support and nonfunctional stubs. Requires environment-specific compatibility tests.	targeted primary-source check in v0.7
[23]	Stack Overflow Developer Survey 2025: Technology	Python adoption rose seven percentage points. Broad developer usage, not an agent-specific language-share measurement.	read during language review
[24]	OpenAI Agents SDK for Python	Python SDK availability and documented agent capabilities. No parity claim with TypeScript.	read during language review
[25]	Python typing	Type annotations and their static-checking role. Python does not enforce annotations automatically at runtime.	read during language review
[26]	Pyright configuration	Strict static checking and configuration.	read during language review
[27]	Pydantic strict mode	Runtime validation and coercion controls. Test JSON/Python input behavior against the published contract.	read during language review
[28]	Claude Agent SDK overview	Python and TypeScript SDK availability. Required capabilities still need per-profile verification.	read during language review
[29]	Python Decimal	Decimal arithmetic with explicit precision and rounding. Domain correctness still requires approved rules and tests.	read during language review
[30]	Pandas overview	Data manipulation and analysis facilities supporting the domain-fit assessment.	read during language review
[31]	Introducing Routines	Launch rationale and cloud triggers	Targeted read in v0.9
[32]	Routines documentation	Current execution and operational behavior	Targeted read in v0.9
[33]	Plugin installation	Cloud plugin configuration	Targeted read in v0.9
[34]	Catch security issues as Claude writes code	Project settings versus local installation	Direct page and cloud-settings section checked in v0.10
[35]	Schedule recurring tasks in Claude Cowork	Installed plugin use in scheduled tasks; qualify local/remote dependencies separately	Read September 13, 2026
[36]	Skills & Plugins	Work plugin skills, MCP and runtime hooks	Read September 13, 2026
[37]	Build plugins	Custom package creation and distribution; supported-surface qualification	Read September 13, 2026
[38]	Scheduled tasks	Explicit Work web/desktop plugin and skill support; source access and local execution prerequisites	Official page read September 13, 2026; no live Zia run
[39]	Trigger a routine through the API	Claude Code Routines inbound trigger, separate from Cowork	Official page read September 13, 2026; integration untested
[40]	Trigger workspace agent runs	Workspace Agent API channel; asynchronous acceptance and result limitations	Official page retrieved September 13, 2026; details also checked in [41]
[41]	ChatGPT Workspace Agents for Enterprise and Business	Eligibility, skills/custom MCPs, API setup, 202 response without run ID or API result retrieval	Official page read September 13, 2026; integration untested
[42]	MCP Tools specification, 2026-07-28	Tool discovery, invocation, schemas, and client/server direction; basis for proposed worker interface	Official tool-definition and invocation passages read September 13, 2026; Zia implementation and host compatibility untested

Before advertising a capability, read the relevant current primary documentation and pass the corresponding integration tests. Sources alone do not prove target support. Sources [3] and [16] were read for the targeted residency and checker corrections in this review. Other historical labels are retained as a research ledger.

---

E13 Traceability record

M0 is an explicitly limited implementation milestone and does not waive the 1.0 release requirements. The table maps each review finding to its resolution and the requirements that evidence it.

Review finding	Resolution	Main evidence
Contradictory hook vocabulary and acceptance metadata	Neutral runtime_control enforcement and separate invariant/test records	FR-B5, FR-B7, E2.2, E2.7
Unenforceable graph promises	Explicit resources, action/role bindings, staged checks, runtime access enforcement	FR-B13, FR-D16, FR-J9, AC-30
Missing schedule and approval semantics	Typed schedules, durable claims, scoped idempotency, input-bound approvals	FR-B12, FR-J2, FR-J9, E2.3
Oversimplified residency	Category policies and complete evidence inventory	FR-K9, NFR-4, AC-25
Tightening confused with feasibility	Typed merge operations and known feasibility checks	FR-C2, FR-C3, FR-C5, FR-C6, FR-C9, AC-4
Assistant form/mode conflation	Independent decisions and explicit plugin lifecycle boundary	FR-A9, FR-A11, AC-22, AC-29
Rigid clarification and checker rules	Focused question grouping and independent verification, risk-based diversity	FR-A2, FR-E6, AC-6, AC-30
Optional regression protection	Mandatory release revalidation, separate optional local automation	FR-E11
Roadmap drift	Codex host restored to 1.0, generated Codex target kept separate, plugin-first policy supersedes SDK-first proposal; managed release timing remains explicit	Product RD-01 to RD-05, FR-D2, FR-F7, AC-12, AC-13, AC-26
Oversized first delivery	Product M0 followed by bounded evidence milestones	First Pilot and Product Section 8
Node compatibility overclaim	Environment-specific deployment tests	FR-D5, NFR-11, reference [22]
Worker language default	Typed Python for generated workers; TypeScript for Zia tooling; separate qualified language profiles	RD-06, RD-07, FR-B2, FR-D2, FR-D5, FR-D11, NFR-11, references [23] to [30]