



Network Working Group                                       O. Romanchuk
Internet-Draft                                               Independent
Intended status: Informational                             14 March 2026
Expires: 15 September 2026


    APSIX: Minimal Primitive Contract for Portable Semantic Runtimes
                        draft-romanchuk-apsix-00

Abstract

   This document proposes *APSIX* (_Agent Portable Semantic Interface
   eXtension_) as a minimal primitive contract for portable semantic
   runtimes.  The goal is not to standardize agent personalities, prompt
   formats, planner graphs, or model-specific reasoning behavior.  The
   goal is to standardize the smallest useful contract of the runtime
   environment itself.

   The design reflects runtime patterns observed in early governed
   semantic-runtime implementations.  In those implementations, the
   primary managed resource is bounded semantic territory, and spawned
   actor populations are the main source of pressure on that resource.
   APSIX defines the lower-layer contract required for such runtimes to
   become portable across implementations.

   The contract is intentionally narrow.  It standardizes logical
   objects, lifecycle primitives, membrane-mediated decisions,
   capability semantics, event and provenance requirements, replay
   obligations, and progressive compliance profiles.  It does not
   standardize model internals, scheduling strategies, storage engines,
   user interfaces, or application-specific orchestration logic.

   The document is written to stand on its own as a self-contained
   runtime specification, without dependency on unpublished external
   framing.

   This is a draft specification, not a final standard.  The current
   name is provisional; the technical target is a portable primitive
   surface for governed semantic runtimes.

   This document is intended as a *research specification*, not as an
   immediate industry standardization proposal.  Its purpose is to
   define a portability target early enough that emerging runtime
   implementations do not harden around mutually incompatible framework-
   local abstractions before a shared primitive vocabulary exists.






Romanchuk               Expires 15 September 2026               [Page 1]

Internet-Draft                    APSIX                       March 2026


Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 15 September 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.2.  Intended Use  . . . . . . . . . . . . . . . . . . . . . .   5
     1.3.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Conformance Language and Terminology  . . . . . . . . . . . .   6
     2.1.  Core Terms  . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Object Model  . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Zone  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.2.  Partition . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.3.  Actor . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.4.  Run . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.5.  Artifact  . . . . . . . . . . . . . . . . . . . . . . . .   9
     3.6.  Anchor Record . . . . . . . . . . . . . . . . . . . . . .   9
     3.7.  Membrane Decision Record  . . . . . . . . . . . . . . . .   9
     3.8.  Membrane Policy . . . . . . . . . . . . . . . . . . . . .  10
     3.9.  Event . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.10. Ledger Manifest . . . . . . . . . . . . . . . . . . . . .  11
   4.  Primitive Set . . . . . . . . . . . . . . . . . . . . . . . .  11



Romanchuk               Expires 15 September 2026               [Page 2]

Internet-Draft                    APSIX                       March 2026


     4.1.  zone(domain_spec) -> zone_id  . . . . . . . . . . . . . .  11
     4.2.  spawn(capability_set, zone_id, intent) -> actor_id |
           error . . . . . . . . . . . . . . . . . . . . . . . . . .  12
     4.3.  refine(zone_id, scope_ref, hypothesis) -> partition_set |
           error . . . . . . . . . . . . . . . . . . . . . . . . . .  12
     4.4.  execute(actor_id, target_ref, capability, input_refs) ->
           artifact | error  . . . . . . . . . . . . . . . . . . . .  13
     4.5.  anchor(artifact_ref, zone_id) -> anchor_id | error  . . .  13
     4.6.  harvest(zone_id, filter) -> artifact_set  . . . . . . . .  14
     4.7.  freeze(zone_id) -> lifecycle_state | error  . . . . . . .  14
     4.8.  observe(zone_id) -> event_stream | event_slice  . . . . .  14
   5.  Capability and Locality Model . . . . . . . . . . . . . . . .  15
     5.1.  Core Capability Set . . . . . . . . . . . . . . . . . . .  15
     5.2.  Capability Mask . . . . . . . . . . . . . . . . . . . . .  15
     5.3.  Locality Binding  . . . . . . . . . . . . . . . . . . . .  15
     5.4.  Role Derivation . . . . . . . . . . . . . . . . . . . . .  16
   6.  Membrane Semantics  . . . . . . . . . . . . . . . . . . . . .  16
     6.1.  Complete Mediation  . . . . . . . . . . . . . . . . . . .  16
     6.2.  Decision Surface  . . . . . . . . . . . . . . . . . . . .  16
     6.3.  Decision Record . . . . . . . . . . . . . . . . . . . . .  16
     6.4.  Budget Interaction  . . . . . . . . . . . . . . . . . . .  17
   7.  Artifact, Provenance, and Replay Semantics  . . . . . . . . .  17
     7.1.  Artifact Lifecycle  . . . . . . . . . . . . . . . . . . .  17
     7.2.  Provenance  . . . . . . . . . . . . . . . . . . . . . . .  17
     7.3.  Replay Contract . . . . . . . . . . . . . . . . . . . . .  18
     7.4.  No Silent Promotion . . . . . . . . . . . . . . . . . . .  19
     7.5.  Measurement Convention  . . . . . . . . . . . . . . . . .  19
   8.  Error Model . . . . . . . . . . . . . . . . . . . . . . . . .  19
   9.  Compliance Profiles . . . . . . . . . . . . . . . . . . . . .  20
     9.1.  APSIX-core  . . . . . . . . . . . . . . . . . . . . . . .  20
     9.2.  APSIX-governed  . . . . . . . . . . . . . . . . . . . . .  20
     9.3.  APSIX-replayable  . . . . . . . . . . . . . . . . . . . .  21
     9.4.  Conformance Guidance  . . . . . . . . . . . . . . . . . .  21
   10. Mapping to Concrete Runtimes  . . . . . . . . . . . . . . . .  22
   11. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . .  22
   12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . .  22
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  23
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  24
   16. Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  24










Romanchuk               Expires 15 September 2026               [Page 3]

Internet-Draft                    APSIX                       March 2026


1.  Introduction

   Agent runtimes are currently fragmented across framework-local
   abstractions.  One system centers graphs, another centers
   conversations, another centers workflow automation, and another
   centers tool loops around a planner-worker core.  This fragmentation
   weakens portability because applications depend on framework-specific
   object models rather than on a stable environment contract.

   The design intent of APSIX is analogous in spirit to the role POSIX
   played for operating systems: not to prescribe every implementation
   detail, but to standardize a small enough primitive surface that
   higher-level software can become portable across runtimes.

   The analogy to POSIX is aspirational in scope, not historical in
   maturity.  The present ecosystem is still early.  The purpose of this
   document is therefore not to claim that semantic runtimes have
   already converged enough for final standardization, but to provide a
   research-grade contract that implementations can target, compare
   against, and refine.

   The conceptual shift is:

   *  classical POSIX standardized process, file, and I/O primitives;
   *  APSIX standardizes zone, membrane, artifact, and replay primitives
      for semantic runtimes.

   The spec is derived from three commitments already stabilized in
   early governed semantic-runtime experimentation:

   1.  the runtime manages *semantic territory* rather than only tasks
       or model calls;
   2.  expansion pressure comes from *spawned actor populations*;
   3.  governability depends on *non-bypassable membrane mediation*,
       *durable artifact admission*, and *replayable authoritative
       state*.

   APSIX treats control of spawn-driven semantic epidemics as a core
   runtime concern.  This document does not yet mandate one universal
   epidemic-control algorithm for all runtimes or all partition regimes.
   Instead, APSIX standardizes the governance surface and invariants
   through which within-partition and cross-partition expansion must be
   admitted, bounded, observed, and reconstructed.  Different runtimes
   may implement this surface through single-writer regimes, bounded
   speculative swarms, hierarchical descendant spawning, merge
   selection, quarantine, culling, or other control strategies, provided
   those strategies remain membrane-governed, budget-visible, locality-
   scoped, and replayable.



Romanchuk               Expires 15 September 2026               [Page 4]

Internet-Draft                    APSIX                       March 2026


1.1.  Scope

   This document defines:

   *  a core object model for portable semantic runtimes;
   *  a minimal primitive set derived from runtime lifecycle;
   *  capability permissions and locality semantics;
   *  membrane and budget semantics;
   *  cross-boundary effect admission semantics;
   *  event, provenance, and replay requirements;
   *  compliance profiles.

   This document does not define:

   *  prompt formats or chain-of-thought conventions;
   *  agent reasoning methods;
   *  model selection and vendor APIs;
   *  storage backends;
   *  scheduling algorithms;
   *  UI conventions;
   *  planner-specific orchestration graphs.

1.2.  Intended Use

   APSIX is intended to serve as:

   *  a portability target for experimental semantic runtime
      implementations;
   *  a comparison layer across framework-local runtimes;
   *  a basis for future conformance tests around membrane, provenance,
      replay behavior, and lifecycle-trace invariants.

   It is not yet intended to serve as:

   *  a finalized industry interoperability standard;
   *  a replacement for existing agent SDK APIs;
   *  a mandate on internal scheduler or storage architecture.

1.3.  Design Goals

   The design goals are:

   1.  *Portability*: applications should rely on runtime primitives
       that survive framework changes.
   2.  *Governability*: the runtime must expose an enforcement locus for
       spawn, refinement, anchoring, and cross-boundary effects.
   3.  *Observability*: the runtime must emit stable records of semantic
       expansion and state transitions.



Romanchuk               Expires 15 September 2026               [Page 5]

Internet-Draft                    APSIX                       March 2026


   4.  *Minimality*: the primitive set should be small enough to
       implement and reason about.
   5.  *Replayability*: authoritative state must be reconstructible
       without reproducing original latent reasoning traces.
   6.  *Extensibility*: richer runtimes should be able to add features
       without breaking core semantics.
   7.  *Epidemic Control Extensibility*: the contract should support
       multiple partition-local spawn-control algorithms without losing
       governability or replay semantics.

2.  Conformance Language and Terminology

   The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this
   document are to be interpreted as described in BCP 14 [RFC2119]
   [RFC8174] when, and only when, they appear in all capitals, as shown
   here.

2.1.  Core Terms

   *Domain*: a bounded semantic representation that supports
   localization, refinement, anchoring, and harvest.

   *Zone*: the runtime embodiment of a domain, including state, policy,
   budgets, partitions, and artifacts.

   *Partition*: a bounded sub-zone scope that defines the default unit
   of locality and refinement.

   *Actor*: a spawned runtime instance operating under a capability mask
   and budget share.

   *Artifact*: a produced object that can be retained, validated,
   rejected, anchored, or harvested.

   *Anchor*: the promotion of an artifact into durable authoritative
   runtime state.

   *Membrane*: the enforcement boundary around a zone and its sensitive
   state transitions.

   *Budget*: an explicit bound on expansion, actor creation, artifact
   volume, validation cost, or other governed quantities.

   *Run*: a concrete execution attempt or recovery/harvest attempt
   associated with an actor or task scope and having a terminal outcome.





Romanchuk               Expires 15 September 2026               [Page 6]

Internet-Draft                    APSIX                       March 2026


   *Replay*: authoritative reconstruction of zone state from events,
   anchors, and checkpoints; not reproduction of token-level reasoning.

   *Harvest*: a runtime operation that returns anchored outputs from a
   zone.

   *Effect*: an external or cross-boundary action whose primary result
   is not only a local artifact, but a mutation, publication, delivery,
   or other action against another authority boundary.

   *Spawn Regime*: an implementation-defined policy governing the
   propagation dynamics of actor creation within a zone or partition,
   including concurrency limits, descendant spawning rules, competition,
   throttling, quarantine, merge, or termination behavior.

   *Ledger Manifest*: a stable description of the replay-relevant ledger
   surfaces for a zone, including schema versions, runtime profile,
   measurement convention, and record paths.

3.  Object Model

   An APSIX-compliant runtime MUST expose the following logical objects.

   These objects define logical runtime state, not a mandated storage
   substrate.  Implementations MAY represent them using graphs,
   databases, event streams, logs, or other internal structures,
   provided the normative semantics of the contract remain observable.

3.1.  Zone

   A zone MUST have at least:

   *  zone_id
   *  domain_spec
   *  lifecycle_state
   *  membrane_policy_version
   *  budget_state
   *  partition_state
   *  authoritative_state_ref

   In APSIX-governed and APSIX-replayable, a zone SHOULD additionally
   expose:

   *  output_boundary_ref or equivalent authoritative harvest target
      surface
   *  ledger_state
   *  ledger_manifest_ref, if a separate manifest object is used




Romanchuk               Expires 15 September 2026               [Page 7]

Internet-Draft                    APSIX                       March 2026


   Optional implementation fields MAY include ownership metadata,
   external bindings, topology hints, or storage references.

   authoritative_state_ref denotes the runtime's single authoritative
   execution state for the zone.  Implementations MAY expose dashboards,
   plans, manifests, or other operator-facing projections, but such
   projections MUST NOT function as independent control planes with
   authority to diverge from authoritative zone state.

3.2.  Partition

   A partition MUST have at least:

   *  partition_id
   *  zone_id
   *  scope_ref
   *  status

   The runtime MAY materialize partitions explicitly or derive them from
   a structured domain substrate, but partition identity and locality
   semantics MUST be observable.

3.3.  Actor

   An actor MUST have at least:

   *  actor_id
   *  zone_id
   *  admitted_partitions
   *  capability_mask
   *  budget_share
   *  intent
   *  status

   An actor MAY be ephemeral or persistent.

3.4.  Run

   A run MUST have at least:

   *  run_id
   *  zone_id
   *  request_id
   *  run_kind
   *  status
   *  started_at
   *  ended_at or equivalent terminal timestamp




Romanchuk               Expires 15 September 2026               [Page 8]

Internet-Draft                    APSIX                       March 2026


   If the runtime associates runs with an actor or partition-local task,
   it MUST expose that binding.

   Run kinds MUST distinguish at minimum:

   *  execution_run
   *  recovery_run, if recovery is supported
   *  harvest_run, if harvest materializes execution-like work

3.5.  Artifact

   An artifact MUST have at least:

   *  artifact_id or provisional identifier
   *  origin_actor_id
   *  zone_id
   *  artifact_type
   *  status
   *  provenance

   Artifact statuses MUST distinguish at least:

   *  generated
   *  anchored
   *  harvested
   *  rejected

3.6.  Anchor Record

   An anchored artifact MUST have an associated anchor record containing
   at least:

   *  anchor_id
   *  artifact_id
   *  zone_id
   *  policy_version
   *  decision
   *  timestamp_or_order

3.7.  Membrane Decision Record

   A membrane-mediated decision MUST have an auditable decision record
   containing at least:

   *  decision_id
   *  request_id
   *  zone_id
   *  request_type



Romanchuk               Expires 15 September 2026               [Page 9]

Internet-Draft                    APSIX                       March 2026


   *  subject_ref
   *  decision
   *  policy_version
   *  reason_code
   *  capability_basis
   *  budget_context
   *  timestamp_or_order

3.8.  Membrane Policy

   A membrane policy MUST define:

   *  spawn admissibility rules
   *  within-partition population-control rules, if multiple actors per
      partition are supported
   *  refinement admissibility rules
   *  cross-zone and cross-partition effect rules
   *  external effect admission rules
   *  artifact promotion rules
   *  escalation rules
   *  budget interaction rules
   *  epidemic-control rules such as throttling, quarantine, culling,
      merge, or equivalent growth-control behavior, if such controls are
      supported

3.9.  Event

   The runtime MUST produce an event stream or event log containing at
   least:

   *  zone creation
   *  actor admission request and decision
   *  refinement event
   *  execute completion or failure
   *  external effect request, decision, completion, or failure, if such
      effects are supported
   *  anchor decision
   *  harvest event
   *  freeze or closure event

   Each event record MUST expose at least:

   *  event_id
   *  seq_no or equivalent global authoritative order index
   *  zone_id
   *  event_type
   *  subject_ref




Romanchuk               Expires 15 September 2026              [Page 10]

Internet-Draft                    APSIX                       March 2026


   *  request_id, if the event is part of a membrane-mediated request
      chain
   *  run_id, if the event is part of a concrete execution attempt
   *  timestamp_or_order
   *  causal_ref or equivalent parent reference, if such ordering is
      supported

   If a runtime stores events, decisions, and anchors in separate
   ledgers, those ledgers MUST still preserve one authoritative cross-
   ledger ordering surface such as a shared monotonic seq_no.

3.10.  Ledger Manifest

   APSIX-replayable runtimes SHOULD expose a ledger manifest containing
   at least:

   *  zone_id
   *  schema_version
   *  runtime_profile
   *  measurement_convention, if telemetry proxies are exposed
   *  replay-relevant record paths or references
   *  record schema version or equivalent compatibility indicator

4.  Primitive Set

   APSIX-core runtimes MUST implement the lifecycle primitives in
   Sections 4.1-4.7.  Governed and replayable profiles MUST additionally
   implement the observability primitive in Section 4.8.

4.1.  zone(domain_spec) -> zone_id

   Creates a zone from a domain specification.

   Requirements:

   *  MUST initialize membrane and budget state.
   *  MUST initialize partition state.
   *  If the runtime exposes harvested outputs, MUST define an
      authoritative output boundary or equivalent harvest target surface
      for the zone.
   *  SHOULD bind or snapshot the authoritative output boundary for
      later harvest validation.
   *  MUST return a stable zone_id.
   *  MUST emit a zone creation event.







Romanchuk               Expires 15 September 2026              [Page 11]

Internet-Draft                    APSIX                       March 2026


4.2.  spawn(capability_set, zone_id, intent) -> actor_id | error

   Requests creation of an actor in a zone.

   Requirements:

   *  Each invocation of spawn() MUST admit at most one actor.  Multi-
      actor populations MUST arise through repeated or descendant
      invocations of spawn(), not through batch return of a single call.
   *  MUST assign admitted partition scope or return an explicit
      placement failure.
   *  MUST assign a capability mask and budget share.
   *  MUST fail deterministically when policy or budget denies creation.
   *  MUST emit both request and decision events.
   *  In APSIX-governed and APSIX-replayable, spawn request and decision
      surfaces MUST be correlated by a stable request_id.
   *  If actor execution later materializes, the runtime MUST expose a
      run_id or equivalent execution identifier for that concrete
      attempt.
   *  A spawned actor operating within an admitted partition MAY decline
      further expansion, request refinement, or request descendant spawn
      under an implementation-defined Spawn Regime.
   *  If the runtime supports multiple actors within one partition or
      descendant spawning from within a partition, spawn decisions MUST
      remain locality-scoped and auditable at that finer-grained
      population boundary.
   *  Descendant spawn, if supported, MUST remain lineage-visible,
      locality-scoped, budget-visible, and membrane-mediated.
   *  A runtime MUST NOT place an actor or execution into a live running
      state unless spawn admission has already succeeded for that actor
      or execution.
   *  A runtime MUST NOT treat queued or budget-deferred spawn as
      equivalent to live running execution.
   *  In APSIX-governed and APSIX-replayable, MUST be membrane-mediated.

4.3.  refine(zone_id, scope_ref, hypothesis) -> partition_set | error

   Requests semantic decomposition or restructuring within a zone.

   Requirements:

   *  MUST be recorded as a replayable event.
   *  MUST preserve lineage from prior scope.
   *  MUST NOT silently enlarge zone scope without explicit membrane
      approval.
   *  SHOULD preserve stable partition identity where possible.
   *  In APSIX-governed and APSIX-replayable, policy-sensitive
      refinement MUST be membrane-mediated.



Romanchuk               Expires 15 September 2026              [Page 12]

Internet-Draft                    APSIX                       March 2026


4.4.  execute(actor_id, target_ref, capability, input_refs) ->
      artifact | error

   Applies a capability to a zone target or artifact target.

   Requirements:

   *  MUST verify actor authorization for the requested capability.
   *  MUST verify target locality against admitted partitions or
      membrane-approved boundary crossing.
   *  MUST return an artifact or structured failure.
   *  MUST record provenance links to input references.
   *  MUST distinguish artifact-producing executions from effectful
      requests that attempt to mutate or publish across another
      authority boundary.
   *  An execution MAY produce artifacts representing further runtime
      requests such as refinement requests or spawn requests rather than
      final outputs.
   *  If the runtime materializes partition-local candidate outputs
      prior to harvest, it MUST keep those candidate outputs distinct
      from harvested authoritative outputs.
   *  If an execution is cancelled, aborted, or force-terminated by
      runtime policy, the runtime MUST expose a terminal outcome for
      that execution rather than leaving it in an ambiguous live state.
   *  Retries, recoveries, and resumed executions SHOULD be represented
      as distinct runs rather than silently overwriting prior execution
      outcomes.
   *  If the runtime supports external or cross-boundary effects, APSIX-
      governed and APSIX-replayable profiles MUST subject those effects
      to membrane mediation and auditable event records before
      completion.

4.5.  anchor(artifact_ref, zone_id) -> anchor_id | error

   Promotes an artifact into anchored state.

   Requirements:

   *  MUST create or confirm stable artifact identity.
   *  MUST create an anchor record.
   *  MUST record decision provenance sufficient for replay.
   *  MUST NOT silently promote generated artifacts to anchored state
      without an explicit anchoring transition.
   *  In APSIX-governed and APSIX-replayable, MUST be membrane-mediated.







Romanchuk               Expires 15 September 2026              [Page 13]

Internet-Draft                    APSIX                       March 2026


4.6.  harvest(zone_id, filter) -> artifact_set

   Returns anchored artifacts matching a filter or harvest profile.

   Requirements:

   *  MUST NOT implicitly anchor unanchored artifacts.
   *  SHOULD support deterministic filtering.
   *  SHOULD preserve or validate the zone's authoritative output
      boundary; if that boundary has drifted since zone creation, a
      governed runtime SHOULD deny or escalate harvest rather than
      silently reinterpreting outputs.
   *  If the runtime uses partition-local candidate surfaces, harvest
      MUST perform an explicit transition into the authoritative output
      boundary rather than treating candidate-local paths as already
      harvested final outputs.
   *  MUST emit a harvest event.

4.7.  freeze(zone_id) -> lifecycle_state | error

   Transitions a zone into a closure regime.

   Requirements:

   *  MUST deny further expansion primitives by default after success.
   *  MUST emit a freeze or closure event.
   *  SHOULD clean zone-owned ephemeral runtime resources such as
      worktrees, temporary branches, sandboxes, or equivalent execution
      residues.
   *  MUST NOT be required to re-harvest already harvested outputs in
      order to stabilize the zone.
   *  MUST NOT make previously anchored artifacts unreachable for replay
      or later harvest unless an explicit abandonment, archival, or
      retention policy is itself recorded as authoritative state.
   *  SHOULD preserve harvest and replay access.

4.8.  observe(zone_id) -> event_stream | event_slice

   Returns runtime events for the zone.

   Requirements:

   *  MUST expose membrane decisions and artifact lifecycle transitions.
   *  MUST expose external effect decisions and outcomes, if such
      effects are supported.
   *  MUST expose terminal failure, cancellation, or abort outcomes for
      actor executions when the runtime supports those outcomes.
   *  MUST preserve authoritative ordering semantics.



Romanchuk               Expires 15 September 2026              [Page 14]

Internet-Draft                    APSIX                       March 2026


   *  In APSIX-governed and APSIX-replayable, ordering SHOULD be
      reconstructible through a stable cross-ledger ordering surface
      such as seq_no, not only through wall-clock timestamps.
   *  In APSIX-replayable, request/decision/run correlation surfaces
      SHOULD be observable.
   *  Decision and event surfaces MUST be sound with respect to
      authoritative zone state: an implementation MUST NOT emit or
      retain admission, anchor, or lifecycle records that assert a zone
      state transition that did not occur in authoritative state.
   *  MAY paginate or stream.

5.  Capability and Locality Model

   Capabilities are primitive permissions in APSIX.  Roles are derived
   from them.

5.1.  Core Capability Set

   An implementation SHOULD support capability names equivalent to:

   *  refine
   *  spawn
   *  execute
   *  anchor
   *  harvest

   Equivalent implementation-local names MAY be used if their semantics
   are documented.  Implementations MAY define richer capability
   vocabularies above this primitive substrate.

   freeze() is a zone-administrative closure primitive and need not be
   exposed as a general actor capability.

5.2.  Capability Mask

   Every actor MUST operate under a capability mask.  The runtime MUST
   reject attempts to execute a primitive that exceeds the actor's mask.

5.3.  Locality Binding

   Capability grants MUST be interpreted relative to locality.
   Authorization is incomplete unless the runtime can answer both:

   *  which operation class is permitted;
   *  over which admitted partition set it is permitted.






Romanchuk               Expires 15 September 2026              [Page 15]

Internet-Draft                    APSIX                       March 2026


5.4.  Role Derivation

   Roles are not normative objects in APSIX.  A runtime MAY expose roles
   for ergonomics, but the normative substrate MUST remain the
   capability mask plus locality binding.

6.  Membrane Semantics

   The membrane is the critical enforcement locus of APSIX.

6.1.  Complete Mediation

   The runtime MUST subject the following operations to membrane
   mediation:

   *  actor creation
   *  policy-sensitive refinement
   *  cross-partition effects
   *  cross-zone effects
   *  external effects against other authority boundaries
   *  artifact promotion
   *  budget-sensitive expansion

   If an implementation allows any of these operations to bypass
   membrane checks, it is not compliant with governed profiles.

6.2.  Decision Surface

   Membrane decisions MUST expose at least three outcomes:

   *  allow
   *  deny
   *  escalate

   escalate indicates that local runtime authority is insufficient and
   an external approval or higher-level policy decision is required.

6.3.  Decision Record

   Each membrane-mediated decision MUST make available:

   *  decision
   *  request_id
   *  policy_version
   *  reason_code
   *  budget_context
   *  capability_basis




Romanchuk               Expires 15 September 2026              [Page 16]

Internet-Draft                    APSIX                       March 2026


   An implementation SHOULD expose this through a stable
   membrane_decision_record schema rather than through framework-local
   logging formats.

6.4.  Budget Interaction

   Budget exhaustion MUST be visible to membrane decisions.  An
   exhausted zone MUST NOT continue infinite spawn or refinement as if
   the runtime had no control surface.  If an implementation supports
   effect quotas or publication limits, exhaustion of those limits MUST
   likewise be visible to membrane decisions.

   If an implementation supports multiple actors within one partition,
   budget and admission state SHOULD remain interpretable at that
   partition-local expansion boundary rather than only at whole-zone
   granularity.

   Deferral due to budget or capacity pressure MUST remain
   distinguishable from execution failure.  A runtime MUST NOT collapse
   budget_exhausted, queued, or deferred conditions into terminal actor
   failure unless an execution actually ran and failed.

7.  Artifact, Provenance, and Replay Semantics

   APSIX is not only about actor lifecycle.  It is also about stable
   artifact handling and authoritative replay.

7.1.  Artifact Lifecycle

   An implementation MUST support a lifecycle in which artifacts are at
   minimum:

   1.  generated
   2.  optionally anchored
   3.  optionally harvested

   If an implementation distinguishes between partition-local candidate
   outputs and authoritative final outputs, that distinction SHOULD
   remain explicit in artifact type, lifecycle state, or equivalent
   durable metadata.

7.2.  Provenance

   Anchored artifacts MUST preserve enough provenance to answer:

   *  which actor produced this artifact;
   *  in which zone;
   *  over which partition scope;



Romanchuk               Expires 15 September 2026              [Page 17]

Internet-Draft                    APSIX                       March 2026


   *  under which capability;
   *  from which input references;
   *  under which membrane decision context.

   At minimum, an anchored artifact SHOULD be portable together with:

   *  its anchor_record;
   *  the originating membrane_decision_record;
   *  referenced input artifacts or scope identifiers.

   If an anchored artifact is the basis for an external effect, the
   runtime SHOULD preserve a portable reference to the effect decision
   and effect outcome record as well.

7.3.  Replay Contract

   An implementation MUST support authoritative reconstruction of zone
   state from:

   *  ordered events;
   *  membrane decision records;
   *  anchored artifacts;
   *  run records, if runs are exposed separately from actors;
   *  policy version history;
   *  budget and lifecycle checkpoints, if such checkpoints are used.

   Replay MUST reconstruct authoritative runtime state.  It MUST NOT be
   interpreted as a requirement to reproduce original latent reasoning
   traces.

   For portability, replay-relevant records MUST be serializable through
   stable schemas rather than through implementation-specific debug logs
   alone.

   If replay-relevant data is split across multiple ledgers, replay MUST
   reconstruct a single authoritative order across them.

   When actor executions are cancelled, aborted, or otherwise force-
   terminated, replay MUST reconstruct those executions as terminal
   outcomes rather than as still-live runtime activity.

   When execution is interrupted by runtime restart, process
   disappearance, or other loss of live actor state, a governed or
   replayable runtime SHOULD normalize the affected execution into a
   terminal, recovered, or requeued state rather than leaving
   authoritative state ambiguous.





Romanchuk               Expires 15 September 2026              [Page 18]

Internet-Draft                    APSIX                       March 2026


   If an implementation supports within-partition actor populations,
   replay SHOULD also reconstruct the effective spawn regime and lineage
   context sufficiently to distinguish bounded exploration from
   uncontrolled epidemic expansion.

   If an implementation exposes operator-facing projections or planning
   views in addition to authoritative zone state, replay MUST treat
   those views as derived artifacts rather than as independent
   authoritative inputs.

7.4.  No Silent Promotion

   An implementation MUST NOT treat generated output as anchored by
   default unless generation and anchoring are explicitly collapsed into
   one documented primitive.

7.5.  Measurement Convention

   If an implementation exposes runtime telemetry, proxy metrics, or
   derived analytical surfaces in addition to the core APSIX objects, it
   SHOULD expose a stable measurement convention describing:

   *  which records or state surfaces are treated as measurement inputs;
   *  whether metrics are direct runtime variables or deployment-
      specific proxies;
   *  what aggregation horizon or windowing assumptions apply;
   *  what runtime profile or workload regime the measurements are valid
      for.

   Implementations MAY expose population metrics describing actor
   population size, spawn rate, partition-local population distribution,
   or other indicators useful for detecting uncontrolled expansion
   regimes.

   If such metrics are used to support replayable analysis, comparison
   across zones, or theory-mapping claims, APSIX-replayable
   implementations SHOULD make that measurement convention visible
   through a stable manifest, report schema, or equivalent replay-
   relevant surface.

8.  Error Model

   Primitive failures SHOULD be structured rather than opaque.

   Recommended error classes:

   *  policy_denied
   *  budget_exhausted



Romanchuk               Expires 15 September 2026              [Page 19]

Internet-Draft                    APSIX                       March 2026


   *  unknown_zone
   *  unknown_actor
   *  unknown_artifact
   *  unknown_partition
   *  capability_denied
   *  invalid_transition
   *  effect_denied
   *  requires_escalation
   *  replay_unavailable
   *  aborted
   *  cancelled

   When observe(zone_id) is implemented, the runtime SHOULD make these
   errors observable through it.  APSIX-governed and APSIX-replayable
   profiles MUST do so.

9.  Compliance Profiles

   This document defines three progressive profiles.

9.1.  APSIX-core

   Requires:

   *  zone
   *  refine
   *  spawn
   *  execute
   *  anchor
   *  harvest
   *  freeze

   This profile is the minimal portable primitive surface.

9.2.  APSIX-governed

   Requires all APSIX-core primitives plus:

   *  observe
   *  membrane-mediated spawn
   *  membrane-mediated refine for policy-sensitive scope changes
   *  membrane-mediated external or cross-boundary effects, if the
      runtime supports them
   *  membrane-mediated anchor
   *  explicit budget handling
   *  decision records with reason codes
   *  stable membrane decision records




Romanchuk               Expires 15 September 2026              [Page 20]

Internet-Draft                    APSIX                       March 2026


   *  stable request correlation across membrane-mediated lifecycle
      transitions

   This profile is the minimum useful profile for real spawn governance.

9.3.  APSIX-replayable

   Requires all APSIX-governed features plus:

   *  partition-visible locality semantics
   *  artifact provenance
   *  explicit run records or equivalent execution-attempt visibility
   *  stable anchor records
   *  ordered event exposure
   *  stable event records
   *  stable cross-ledger ordering semantics
   *  ledger manifest or equivalent replay surface description
   *  policy version visibility
   *  authoritative replay support
   *  measurement convention visibility, if runtime telemetry proxies
      are exposed

   This profile is the recommended basis for research and auditable
   production systems.

9.4.  Conformance Guidance

   Primitive presence alone is insufficient to establish meaningful
   APSIX conformance.

   Recommended conformance evaluation SHOULD additionally check:

   *  lifecycle ordering invariants across zone, spawn, execute, anchor,
      harvest, and freeze;
   *  request/decision/run correlation integrity where those surfaces
      are exposed;
   *  preservation of authoritative cross-ledger ordering semantics;
   *  absence of silent promotion from generated to anchored state;
   *  explicit separation between candidate-local artifact surfaces and
      harvested authoritative output surfaces, when both exist;
   *  distinction between deferred/queued conditions and terminal
      execution failure;
   *  normalization of interrupted executions into terminal, recovered,
      or requeued authoritative states;
   *  preservation of locality-scoped spawn control when multiple actors
      per partition are supported;
   *  consistency between authoritative zone state and exposed event or
      decision ledgers.



Romanchuk               Expires 15 September 2026              [Page 21]

Internet-Draft                    APSIX                       March 2026


   Implementations MAY satisfy these checks through scenario traces,
   replay fixtures, or other stable lifecycle test surfaces rather than
   only through isolated primitive-level tests.

10.  Mapping to Concrete Runtimes

   APSIX does not mandate a specific implementation style.

   Examples:

   *  a content-spawn runtime could treat each source idea as one zone
      and each channel draft as a harvestable artifact family;
   *  a software runtime could treat bounded codebase areas as zones and
      patches or test reports as artifacts;
   *  a research runtime could treat a literature field as a zone and
      claim-evidence memos as anchored artifacts.

   What matters is not the domain itself, but whether the runtime
   exposes the primitives, locality semantics, membrane decisions, and
   replay obligations coherently.

11.  Non-Goals

   APSIX does not attempt to standardize:

   *  chain-of-thought formats;
   *  inter-model competition protocols;
   *  persona taxonomies;
   *  benchmark task schemas;
   *  human-interface conventions;
   *  internal scheduler algorithms;
   *  concrete effect transports or publication APIs;
   *  storage and graph-engine implementations.

   Those may exist above or below the APSIX layer, but they are not part
   of the core contract.

12.  Open Issues

   Several questions remain open for later versions:

   *  whether cross-zone merge() belongs in an extension set;
   *  whether an explicit effect() primitive should remain derived from
      execute() plus membrane policy or become standardized;
   *  what minimum provenance fields are sufficient for strong
      auditability;
   *  whether event, anchor, and membrane decision schemas should be
      versioned independently or under one runtime schema version;



Romanchuk               Expires 15 September 2026              [Page 22]

Internet-Draft                    APSIX                       March 2026


   *  how replay semantics should interact with distributed asynchronous
      runtimes;
   *  whether an explicit checkpoint() primitive should remain derived
      or become standardized;
   *  whether Run should remain a logical object or become a first-class
      primitive argument surface;
   *  whether output-boundary drift detection should become mandatory in
      governed profiles or remain a replayable-profile recommendation.

13.  Security Considerations

   APSIX defines a governance surface for spawn-capable semantic
   runtimes.  As a result, security and governance failures in an APSIX
   implementation are not limited to data exposure; they can also alter
   population growth, artifact promotion, and cross-boundary effects.

   Improper membrane policy configuration, incomplete mediation, or weak
   audit surfaces may lead to:

   *  uncontrolled actor population expansion;
   *  artifact promotion of unverified or policy-incompatible outputs;
   *  cross-boundary effect escalation without sufficient auditability;
   *  replay gaps that prevent authoritative reconstruction of sensitive
      decisions;
   *  policy drift between authoritative zone state and exposed event or
      decision records.

   Implementations SHOULD ensure that membrane policies enforce:

   *  strict admission control for actor creation and policy-sensitive
      refinement;
   *  explicit artifact validation prior to anchoring;
   *  auditable decision records for cross-boundary effects;
   *  protection of authoritative ordering and replay-relevant ledgers
      against silent tampering or divergence;
   *  clear separation between generated, anchored, and harvested
      artifact states.

   Implementations supporting external effects SHOULD additionally
   ensure that:

   *  escalation paths are authenticated and authorization boundaries
      are explicit;
   *  effect completion is recorded as a durable auditable outcome;
   *  cancelled, aborted, or partially completed effects are not
      presented as successful state transitions.





Romanchuk               Expires 15 September 2026              [Page 23]

Internet-Draft                    APSIX                       March 2026


   Failure to enforce these constraints may result in loss of governance
   over semantic expansion within a zone and may permit unauthorized
   external actions to appear compliant in operator-facing views.

14.  IANA Considerations

   This document has no IANA actions.

15.  References

15.1.  Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March
   1997.

   [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
   Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

16.  Conclusion

   APSIX is a proposal for a minimal primitive contract for portable
   semantic runtimes.  Its central claim is that the portable layer
   should standardize zone, membrane, run, artifact, locality, and
   replay operations rather than framework-local agent behaviors.

   If this direction is useful, higher-level runtimes and applications
   can target a stable substrate of zones, spawn, refinement, execution
   runs, anchoring, harvest, membrane decisions, and replayable
   authoritative state.  That would move the field one step away from ad
   hoc orchestration and one step closer to real runtime portability.




















Romanchuk               Expires 15 September 2026              [Page 24]
