Research Paper

TMPA Architecture Paper

An AI-native software architecture theory for governed multi-agent organizational work in SMEs.

A0.5Academic working draft简体中文 →

TMPA: Textual Multi-Agent Process Architecture

An AI-Native Software Architecture Theory for Governed Multi-Agent Organizational Work in SMEs

Architecture Paper Draft: A0.5
Historical Source Baseline: TMPA Draft V1.0-R23; theory aligned through R31
Status: Academic Working Draft
Revision Date: 2026-08-03
Publication Authority: This GitHub document is the authoritative TMPA architecture paper. The separately maintained TMPA Core Specification is normative; the Implementation Case Report is evidentiary and non-normative.

Abstract

Large language models are moving from isolated question answering into long-running, tool-using, and multi-agent execution. Tool traces and conversation histories may show what occurred, but they do not by themselves establish authorized responsibility, legal lifecycle transitions, independent review, or recoverable governance state.

This paper presents TMPA (Textual Multi-Agent Process Architecture), an SME-first, minimal-infrastructure textual-message multi-agent asynchronous process architecture. Its core has four linked rules: text carries durable messages and state; each writer preserves a local serial stream; multiple streams progress asynchronously to form parallel collaboration; and readers aggregate the available evidence and reconstruct process, responsibility, lifecycle, conflict, and audit state. One stable primary carrier anchors each governed work item; subsequent reports, reviews, decisions, and corrections remain separate single-writer objects. Reconstruction preserves concurrency and unresolved conflict rather than imposing an artificial total order.

FCoP is the project-visible filesystem profile examined in this paper. It requires no mandatory coordination database, broker, or enterprise control plane, but it also does not by itself provide verified enterprise identity, strong role isolation, tamper-resistant storage, or Byzantine resilience. TMPA is therefore SME-first, not SME-only: larger implementations may preserve the same semantics through databases, object stores, event services, identity systems, and control planes.

The study follows a design-science method: it derives requirements from the governance gap and engineering lineage, constructs the TMPA artifact, analyzes its invariants and threat boundaries, maps the artifact to the FCoP reference profile, and evaluates bounded CodeFlowMu and XiaoDian AI evidence through a version-pinned C01–C14 corpus. The contribution is the integrated architecture—not a new storage primitive—and the evaluation is deliberately claim-bounded. Under the I0.4/S0.4 re-adjudication, one product criterion passes, nine remain partial, and four were not run at product-reader level; the separate Reference Reader passes 14 synthetic criteria. No executed product criterion failed, but that is not full conformance or independent validation. The evidence supports structural feasibility while low-resource performance, adoption cost, comparison baselines, broader fault recovery, and third-party reproduction remain open empirical requirements.

Keywords: AI governance, agentic AI, multi-agent systems, SMEs, minimal infrastructure, textual messages, primary carrier, single-writer streams, asynchronous collaboration, deterministic reconstruction, lifecycle, role separation, provenance, auditability, recoverability, FCoP, CodeFlowMu

---

1. Introduction

Large language models have transformed artificial intelligence from isolated reasoning systems into execution systems that use tools, modify files, query databases, operate business software, and collaborate over long-running tasks. Correct output remains necessary, but deployable systems must also preserve the authority, responsibility, and evidence surrounding that output.

A governed multi-agent system must answer who authorized and accepted work, which object represented it, which evidence was produced, who reviewed and decided, whether transitions were legal, and whether the process can be reconstructed after interruption. Logs, chats, workflow states, and business records may contribute evidence, but they do not automatically define an authoritative governance state.

TMPA (Textual Multi-Agent Process Architecture) addresses this gap without governing how agents think or replacing agent frameworks, identity providers, runtime gateways, transports, or storage systems. It defines a cross-platform process-responsibility contract through four operational statements:

Text carries messages and state.
Each writer preserves its own serial stream.
Multiple serial streams progress asynchronously to form parallel collaboration.
Readers aggregate the streams and reconstruct process and governance state.

One stable primary carrier anchors each governed task. Acceptance, reports, reviews, decisions, corrections, and recovery evidence are independently authored objects linked by explicit references. The write side is locally serial and single-writer; the system is asynchronously parallel; the read side reconstructs a partial-order graph and issue set.

The paper uses three orientation views:

DESIGN-SCIENCE LINEAGE
business practice → original TMPA → FCoP extraction and maturation
                  → CodeFlowMu application → current TMPA formalization

CURRENT CONCEPTUAL LAYERING
TMPA architecture → reusable FCoP protocol profile → CodeFlowMu and other applications

END-TO-END PROCESS
write: primary carrier → single-writer streams → asynchronous composition
read:  source aggregation → governance reader → process graph + issue set

The lineage explains origin, the conceptual relation explains present boundaries, and the process view explains operation. None implies that FCoP exhausts TMPA, CodeFlowMu defines FCoP, or the original March 2026 pipeline already satisfied the current Core specification.

One optional application context, specified separately in Section 8.3, is a persistent AI work role sometimes described in industry as a digital employee. Throughout this paper, that label denotes only an engineering work identity that accepts delegated work, uses tools, and submits results across sessions; it does not imply legal employment, personhood, consciousness, human intention, or replacement of accountable human or organizational principals.

1.1 Paper Type and Research Questions

This paper is a design-science and systems-architecture study. The designed artifact is TMPA; the companion Core Specification defines its normative behavior, while this paper explains the problem, theory, design logic, and evaluation. The primary environment is an SME or small team in which governance must begin without assuming a dedicated agent platform, coordination database, message broker, enterprise identity plane, or specialist operations team. FCoP and CodeFlowMu provide implementation and demonstration evidence, but the study does not claim a representative benchmark, production-scale validation, or superiority over enterprise governance platforms.

The paper addresses three research questions:

• RQ1 — Governance-state sufficiency: Which information is missing when chats, shared folders, execution traces, and ordinary task states are used as the record of multi-agent organizational work, and why does that prevent authoritative responsibility and recovery?
• RQ2 — Minimum architecture: Which substrate-independent objects, authority relations, lifecycle rules, ordering constraints, conflict semantics, and read-side operations are minimally necessary to reconstruct governed multi-agent work without a mandatory coordination database, broker, or control plane?
• RQ3 — Engineering feasibility and boundary: To what extent do the FCoP profile, CodeFlowMu, XiaoDian AI, and the pinned C01–C14 corpus demonstrate those properties, and which feasibility claims remain unsupported?

A0.5 answers RQ1 through evidence-gap analysis and RQ2 through the TMPA object, stream, authority, lifecycle, and reconstruction model. RQ3 receives only a bounded answer: the reference profile and cases establish partial feasibility, while the I0.4/S0.4 baseline reports one PASS, nine PARTIAL, and four NOT RUN product-level criteria [28]. Quantified setup burden, low-resource performance, broader fault recovery, comparison baselines, representative use, and third-party reproduction remain unfinished evidence.

1.2 Target Environment and Design Constraints

The primary environment is an SME or small team that needs governed AI collaboration but lacks some combination of a dedicated agent platform, coordination database, message broker, enterprise agent identity infrastructure, and specialist operations staff. This scope is defined by capability constraints, not employee count alone.

The 2026 OECD D4SME Survey reports uneven strategic and secure AI integration among more than 2,000 SMEs across 12 OECD countries, with time, maintenance cost, and skills gaps remaining material obstacles [23]. Singapore's IMDA reported 2024 AI adoption of 14.5% among SMEs versus 62.5% among non-SMEs [24]. These sources do not establish demand for TMPA specifically; they support the broader problem of responsible AI integration under constrained organizational capacity.

The design constraints lead to the following chain:

limited infrastructure and operations capacity
                    ↓
no mandatory database, broker, cluster, or control plane
                    ↓
one governed task → one stable primary textual carrier
                    ↓
locally serial single-writer responsibility streams
                    ↓
independent streams progress asynchronously
                    ↓
source aggregation → governance reconstruction
                    ↓
recoverable process, responsibility, and audit state

Text-carried, locally serial, asynchronously parallel, deterministically reconstructed.

The primary profile is asynchronous project-local collaboration, not distributed consensus or multi-datacenter execution. Participants need not be online together, and evidence may arrive late; the reader exposes the authoritative, partial, disputed, or quarantined view supported by the currently available set. Database-backed and enterprise profiles remain possible, but identity federation, replication, high availability, and cross-domain enforcement are outside the present validation scope.

1.3 Design Origin and Evolution

TMPA first appeared on 21 March 2026 in Section 7.0 of the archived multi-role architecture plan as Text-Message Multi-AI Parallel Architecture [25]. The original design joined one-task-one-carrier, files or objects as messages, asynchronous AI requests, independent task lines, role pipelines, permission checks, and audit traces.

The same source also records a transitional implementation: one Pipeline advanced roles sequentially through a shared context: dict and accumulated trace: List[RoleMessage] [25]. It therefore establishes the architectural origin, not present-day Core conformance. Immutable writer streams, source-preserving aggregation, deterministic reconstruction, explicit conflict states, and conformance requirements were developed later.

XiaoDian AI business practice
          ↓ architecture abstraction
Original TMPA
          ↓ reusable file-coordination and review skeleton extracted
FCoP
          ↓ protocol, schema, package, MCP, governance, and audit evolution
CodeFlowMu adoption
          ↓ operational feedback
Current TMPA formalization

Practice revealed the problem; repeated engineering revealed the method; formalization elevated the method into theory.

The present paper reunifies the original message-and-asynchrony model with the governance semantics matured through FCoP and CodeFlowMu, while avoiding retroactive claims about the early implementation.

1.4 Design Premises and Contributions

TMPA rests on four premises:

1. Textual: governance semantics have a canonical representation readable by people, AI systems, and validators.
2. Multi-Agent: execution, review, approval, and supervision remain attributable to separated authorities.
3. Process: governance covers the full lifecycle, including rejection, correction, recovery, and archival.
4. Architecture: the semantics remain stable across models, runtimes, languages, transports, and storage profiles.

These premises yield four operational commitments:

1. durable textual messages and state carriers;
2. one stable primary carrier per work item and one writer per published object;
3. local seriality with asynchronous multi-stream parallelism;
4. source-preserving aggregation followed by deterministic governance reconstruction.

Writers remain independent. Readers reconstruct the whole.

TMPA does not claim isolated invention of append-only histories, lifecycle machines, provenance, signatures, or role-based authorization. Its contribution is their integration into a minimum-infrastructure process architecture with explicit task identity, responsibility order, lifecycle legality, review separation, conflict preservation, recovery, and machine-testable reader behavior.

The paper contributes:

1. the SME-first architecture and its DR1–DR8 requirement set;
2. the primary-carrier, single-writer, multi-serial asynchronous write model;
3. the aggregation and partial-order governance-reconstruction contract;
4. the FCoP file profile and its published engineering artifacts;
5. a threat model, C01–C14 criteria, and the first version-pinned conformance baseline;
6. bounded CodeFlowMu and XiaoDian evidence plus an empirical program for deployment, recovery, inspectability, adoption discipline, and representative SME workloads.

The current TMPA–FCoP–CodeFlowMu relationship and the operational software stack are specified in Section 4.8; terminology is fixed in Section 1.5.

1.5 Terminology and Representation Stages

The paper fixes the following vocabulary so that semantic objects, physical storage, message behavior, and reconstructed views are not treated as interchangeable concepts.

Canonical English term	Fixed Chinese equivalent	Fixed meaning	Not equivalent to
governed work item	受治理工作项	the task, request, decision, or process subject whose responsibility and lifecycle are being governed	one file, one session, or one runtime job
primary carrier	主载体	the stable governance object that anchors the identifier and minimum governing context of one work item	a mutable record that every participant edits
governance object	治理对象	one canonical semantic unit authored by one creator under one responsible role and one writer stream	its storage path, transport envelope, or derived view
textual message	文本消息	the communication function of a governance object when it transfers work, evidence, review, or decision semantics	a separate object class or an ephemeral queue message
state carrier	状态载体	the persistence function through which an object, transition record, or profile-defined location contributes declared or current state evidence	shared mutable application state
source artifact	来源工件	one physical representation or observation of evidence, such as a file, database row, object-store item, or received event	the semantic governance object after validation
source candidate	来源候选	one discovered source artifact presented to the aggregation stage, including malformed or conflicting observations	an accepted authoritative object
canonical candidate set	规范候选集合	the source-preserving, parsed, indexed, and deterministically normalized collection returned by aggregation	the final governance conclusion
writer stream	写者流	the locally ordered sequence of governance objects published by one attributable writer	a global event log or total timeline
source aggregator	来源聚合器	the stage that discovers, preserves, parses, indexes, and normalizes source candidates without deciding governance truth	the governance reader
governance reader	治理 Reader	the deterministic stage that applies a fixed profile to the canonical candidate set	the storage layer, orchestrator, or model runtime
governance graph and issue set	治理图与问题集合	the reconstructed partial-order process view and the canonical unresolved-condition output	the original source evidence or an imposed total order

A single canonical governance object may be realized by different physical profiles. In FCoP, its source artifact is ordinarily a file plus path and event evidence; another profile may use a row, object, or event. Conversely, two source artifacts that declare the same object identifier but contain different canonical content are not two harmless copies: they are conflicting candidates that must be retained and evaluated under the profile. Throughout the architecture and normative chapters, object refers to the semantic unit, artifact to a physical or published engineering representation, and view to a reader-derived result.

---

2. Problem Definition and Design Requirements

TMPA begins from a distinction between execution evidence and governance evidence. A runtime trace may prove that a tool call occurred; it does not necessarily prove that the caller was authorized, that an accountable role accepted the work, that the output was independently reviewed, or that a later approval referred to the exact reviewed result. A chat transcript may preserve discussion but still lack stable object identity, lifecycle legality, conflict handling, and deterministic reconstruction. A workflow engine may record node completion while keeping its authoritative state inside an implementation-specific database.

The architecture therefore distinguishes four states:

State category	Primary question
execution state	What is the runtime doing?
interaction state	What did participants exchange?
business state	What does the application currently consider true?
governance state	Which responsibilities, transitions, decisions, conflicts, and evidence are authoritative?

TMPA specifies the fourth category while permitting references to the other three.

Text is selected as the canonical interchange form because it can be interpreted by humans, language models, validators, version-control tools, backup systems, and replacement runtimes. “Textual” does not require Markdown files: a conforming deployment may use a database, object store, or event service, provided that the complete governance meaning has a canonical textual representation.

Responsibility separation is equally central. A nominally multi-agent system does not establish independent governance when one identity plans, executes, reviews, approves, and certifies the same work. TMPA therefore treats roles as scoped authorities rather than prompt labels. Lifecycle is also explicit: governed work moves through profile-defined states; legal transitions, transition authorities, rejected transitions, rework, and terminal history must remain observable.

The minimum-infrastructure problem is:

How can a small organization obtain attributable, reviewable, recoverable, and machine-checkable multi-agent governance without assuming a dedicated coordination database, message broker, enterprise control plane, or specialist governance team?

The answer is not “files instead of databases” in isolation. It is a complete process structure in which canonical text carries messages and state, one stable primary carrier identifies each governed work item, each writer publishes through a local serial stream, independent streams progress asynchronously, and a reader reconstructs the process graph and issue set.

The target is minimum infrastructure, not zero discipline. Protected storage, declared identity assumptions, backups, permissions, validation, and recovery procedures remain necessary. OECD and IMDA evidence supports the broader observation that SMEs face persistent time, skill, maintenance, and adoption-capacity constraints; it does not establish demand for TMPA specifically [23], [24].

The problem yields eight traceable requirements:

ID	Requirement
DR1	durable canonical textual representation
DR2	stable work identity and single-writer evidence
DR3	locally ordered streams with asynchronous composition
DR4	explicit authority, review separation, and lifecycle legality
DR5	source-preserving aggregation and deterministic reconstruction
DR6	preservation of conflict, invalid evidence, and partial state
DR7	recovery from persistent governance evidence
DR8	minimum mandatory infrastructure with explicit assurance boundaries

DR1–DR7 define the governance semantics. DR8 constrains the deployment claim: TMPA minimizes required coordination infrastructure but does not inherit guarantees from identity, security, consensus, or control-plane systems that are not actually deployed.

3. Related Work and Positioning

TMPA occupies the process-responsibility layer between agent execution and enterprise governance. MCP and A2A address tool use and agent interoperability [1], [2]; identity systems establish principals and delegated authority [19]; gateways and policy engines govern runtime admission; observability and control-plane products inventory agents and collect telemetry. TMPA does not replace these layers. It consumes their identifiers, policy decisions, traces, and artifacts, then represents governed work, review, rejection, recovery, and responsibility in a reconstructable form.

3.1 Architectural Antecedents

Event sourcing and CQRS contribute append-oriented history and the separation of write representations from read models [4]. Git demonstrates immutable content-addressed objects and explicit history [5]. W3C PROV supplies entities, activities, agents, and derivation relations [3]. TMPA builds on these ideas but adds a narrower process-governance contract: one primary carrier per work item, single-writer responsibility streams, explicit lifecycle authority, separation of duties, conflict preservation, and a deterministic governance reader.

The architecture is not equivalent to chat, a shared folder, an ADR collection, a workflow engine, or a single global event log. These mechanisms may store relevant evidence, but they do not by themselves define which object is authoritative, whether an action was in scope, whether a review was independent, or how contradictory evidence remains visible.

3.2 Interoperability and Governance Gaps

The formation of the Agentic AI Foundation reflects the growth of interoperability infrastructure around MCP and related projects [6]. Interoperability, however, is not the same as governance. Kang and Diponegoro analyze MCP, A2A, ACP, ANP, and ERC-8004 against membership, deliberation, voting, dissent preservation, human escalation, and audit/replay requirements, finding that no surveyed protocol expresses a complete governance model [27]. TMPA addresses a narrower subset—work responsibility, lifecycle, review, conflict, and recovery—rather than full community governance.

Open Challenges in Multi-Agent Security emphasizes that collusion, cascading effects, stealth, and oversight failure can emerge at the interaction level even when individual components appear secure [26]. TMPA can preserve attributable evidence and unresolved disagreement for investigation, but it is not a collusion detector.

3.3 Direct Research Neighbors

Auditable Agents separates accountability, auditability, and auditing, and evaluates action recoverability, lifecycle coverage, policy checkability, responsibility attribution, and evidence integrity [17]. TMPA is complementary: it specifies the durable work objects and process reconstruction on which those dimensions can be evaluated.

The IETF agent-audit architecture similarly treats delegation and interactions as auditable events [18]. TMPA can supply a project-local or platform-neutral representation of such events but does not standardize network transport.

Authorization Propagation in Multi-Agent AI Systems identifies transitive delegation, aggregation inference, and temporal validity as unresolved authorization problems [20]. TMPA records assignments and responsibility transitions but does not define a complete recursive delegation calculus.

Policies on Paths argues that runtime governance may depend on the partial execution path rather than static access rules [21]. TMPA preserves process paths as evidence; it does not itself block actions during execution.

Proof-Carrying Agent Actions binds high-value actions to decision-time certificates, approvals, and replay-ready proof [29]. PCAA centers the action decision; TMPA centers the longer governed work item and its reports, reviews, conflicts, corrections, and recovery. A TMPA profile may reference PCAA certificates as execution evidence.

AGENTSAFE combines risk classification, semantic telemetry, dynamic authorization, interruptibility, anomaly detection, cryptographic tracing, and organizational controls [30]. TMPA chooses a different minimum baseline: readable canonical text and deterministic reconstruction are mandatory, while cryptographic identity and stronger integrity controls are optional named profiles.

Why Do Multi-Agent LLM Systems Fail? derives failure categories from a large trace corpus [22]. TMPA improves observability of responsibility, review, conflict, and recovery, but this paper does not claim reduced failure rates.

The incremental contribution is therefore not a new storage primitive or a complete control plane. It is the combination of a durable textual message/state plane, one-task-one-primary-carrier, local single-writer streams, asynchronous composition, source-preserving aggregation, and deterministic read-side governance reconstruction under a minimum-infrastructure profile.

3.4 Comparative Synthesis and Research Gap

The related work falls into five neighboring lines. Their boundaries clarify the gap addressed by TMPA:

Research line	Principal contribution	TMPA relation and boundary
MCP and A2A [1], [2]	interoperable context, capability, task, and message exchange for tool or agent interaction	TMPA may reference these interactions but defines longer-lived responsibility, review, conflict, and recovery evidence
W3C PROV, event sourcing, and CQRS [3], [4]	derivation, append-oriented event history, and read-model construction	TMPA specializes these mechanisms into governed work identity, authority, lifecycle legality, and deterministic issue reconstruction
Auditable Agents and the IETF audit architecture [17], [18]	accountability dimensions, distributed audit records, context, and later investigation	TMPA provides a substrate-neutral governed-work graph but does not define network audit-context propagation or attestation
authorization propagation, path policies, and proof-carrying actions [20], [21], [29]	decision-time authorization and runtime enforcement for delegated paths or certified actions	TMPA preserves the authorized work process and its outcomes; it does not replace execution-time mediation
NIST AI RMF and AGENTSAFE [30], [31]	organizational risk identification, controls, monitoring, assurance, and accountability	TMPA is a narrower evidence architecture that can support such programs but does not constitute a complete risk-management framework

No reviewed neighbor combines all of the following as one minimal-infrastructure process contract: a stable primary carrier, single-writer responsibility streams, asynchronous composition without a forced total order, explicit authority and lifecycle semantics, preservation of invalid and conflicting evidence, and deterministic reconstruction of both a governance graph and an issue set. This is the specific research gap claimed by A0.5. The claim is architectural and comparative; it is not a priority claim over every possible unpublished or proprietary system.

4. TMPA Architecture

TMPA defines governance semantics, not a runtime component. Its architecture specifies which governance facts must be represented, how responsibility and lifecycle are expressed, and how independent evidence is reconstructed into an authoritative view. Storage, transport, scheduling, and model behavior remain implementation concerns unless a TMPA profile explicitly binds them.

4.1 Governance Object

A governance object is the smallest independently attributable semantic unit in TMPA. It may represent a task, report, review, approval, issue, lifecycle transition, role assignment, recovery action, or another document type published by a protocol profile. The object is distinct from its physical source artifact: FCoP may encode it as a file and path observation, while another profile may use a database row, object-store item, or event.

The terms textual message and state carrier describe functions of an object rather than additional object classes. An object acts as a textual message when it transfers governed work or evidence, and it acts as a state carrier when its content, transition evidence, or profile-defined location contributes to lifecycle reconstruction.

Every governance object contains or identifies:

• a stable object identifier;
• a document type;
• one creator identity;
• one responsible role;
• a stream identifier and sequence number;
• a creation time;
• a lifecycle profile and declared state;
• typed references to related objects;
• canonical textual content;
• integrity evidence.

A published governance object is immutable. Correction does not erase or rewrite the original object; it creates a new object that supersedes, rejects, qualifies, or resolves the earlier one. Multiple byte-identical source observations may refer to the same object without changing its meaning; the same identifier paired with different canonical content is a conflict, not an update.

The lifecycle state declared by an object is the state associated with that object under its profile at publication. The current authoritative state of governed work is reconstructed from the valid object set, accepted transitions, and profile rules. It is not obtained by mutating an earlier published object or by selecting the most recent timestamp.

4.2 Document Types

TMPA Core does not impose a universal business-document taxonomy. Each implementation profile instead publishes a finite document-type registry.

Each registry entry defines:

• the type name and version;
• the governance responsibility represented by the type;
• permitted creator roles;
• required fields;
• permitted reference relations;
• the applicable lifecycle profile;
• validation rules.

Document types must not overlap ambiguously in authority. An execution report, for example, does not implicitly serve as its own independent review or approval. When a deployment permits an exception to separation of duties, the exception and its approving authority must be represented explicitly.

4.3 Role and Authority Model

A TMPA role is a governance authority with a defined scope. It is not merely a prompt label or natural-language persona.

Each role definition identifies:

• a stable role identifier;
• permitted object types;
• permitted lifecycle actions;
• separation-of-duty constraints;
• the authority that assigns the role;
• the assignment's validity period and revocation state.

An object’s role field declares the authority under which the creator acted; it does not create that authority. A reader validates the claim against an active role assignment and the applicable policy profile.

A participant may occupy more than one role only when the implementation profile explicitly permits the combination. A deployment claiming independent review must prohibit the same identity from acting as both executor and reviewer for the same governed result unless a recorded and authorized exception applies.

In an enterprise identity profile, the logical role is bound separately to a verifiable agent or workload identity, the human or organizational principal that remains accountable, the credential used for the action, the delegation source and scope, and the validity or revocation state. TMPA Core records and validates the governance claim; it does not issue credentials or enforce recursive permission attenuation.

4.4 Lifecycle Model

A lifecycle profile consists of:

• a finite state set S;
• an initial state s0;
• a terminal-state set F;
• an action set A;
• a transition relation T ⊆ S × A × S;
• an authorization function Auth(role, action, object);
• a validation function Valid(object, transition).

A transition is accepted only when:

1. its source state matches the current authoritative state;
2. the transition is defined by T;
3. the initiating role is authorized;
4. required references and preconditions are satisfied;
5. the transition evidence passes schema and integrity validation.

An illegal or unauthorized transition does not alter the authoritative lifecycle state. The attempt remains observable through a rejection, issue, alert, or equivalent profile-defined record rather than being silently discarded or repaired.

4.5 Textual Messages, Single-Writer Streams, and Asynchronous Parallelism

TMPA's write plane combines a stable work carrier, single-writer objects, local seriality, and asynchronous composition.

For every governed task or work item t, a task-oriented profile defines one stable primary carrier c_t. The carrier establishes the identifier and minimum governing context of the work. Acceptance, execution reports, reviews, decisions, corrections, and recovery records are separate objects that reference c_t; they do not become additional mutable copies of the task. “One task, one carrier” therefore means one stable primary reference point, not one document that every participant edits.

Let A be the set of responsible writers. Every published object has exactly one writer, and each writer a ∈ A publishes an independently attributable serial stream:

S_a = ⟨o_{a,1}, o_{a,2}, ..., o_{a,n}⟩

The sequence inside S_a is authoritative local order. Every object has a positive sequence number, and (stream_id, sequence) identifies its position within that writer's responsibility history. Creation time is informative but not authoritative for stream order.

At observation time τ, the available candidate collection may contain different prefixes of different streams:

O_τ = ⋃_{a ∈ A} prefix(S_a, k_a(τ))

The functions k_a(τ) need not advance together. One participant may publish a task while another is offline; a report may appear before an independent review; several writers may progress concurrently. This is how multiple serial streams form asynchronous parallelism. TMPA does not require all participants to share a clock, remain online together, or commit to one global event log.

Within-stream predecessor relations provide local order. Explicit references and profile-defined lifecycle dependencies provide cross-stream causal edges. If two objects have neither a within-stream relation nor a profile-defined cross-stream dependency, they remain concurrent and incomparable.

Single-writer objects and separate responsibility streams remove the primary semantic shared-write conflict: several agents do not compete to edit one authoritative record. They do not eliminate every storage-level contention, filesystem race, or infrastructure failure; profiles must still define atomic publication, duplicate handling, and recovery behavior.

The write model can be summarized as:

One task has one primary carrier. One writer owns each published object. Each writer remains serial. Multiple streams progress asynchronously to form parallel collaboration.

4.6 Read-Side Aggregation and Governance Reconstruction

TMPA's read plane has two conceptually separate stages: source aggregation and governance reconstruction.

Let O_τ be the finite collection of source candidates visible at observation time τ. A source-preserving aggregator A discovers source artifacts, retains source identity and bytes, parses candidate envelopes, indexes identifiers and references, and applies deterministic normalization needed by the reader:

C_τ = A(O_τ)

Aggregation does not decide which claim is true, silently repair a conflict, invent missing evidence, or convert arrival order into governance order. Its purpose is to construct the complete canonical candidate set C_τ available to the governance reader while retaining the provenance of every source candidate.

Let P be a fixed rule profile containing schemas, type rules, role assignments, lifecycle rules, relation semantics, canonicalization rules, conflict policy, and output-normalization rules. The governance reader then computes:

R_P(C_τ) = (G_τ, I_τ)

where G_τ is the canonical reconstructed partial-order process and governance graph and I_τ is the canonical issue set. G_τ represents workflow progress, responsibility, lifecycle, review, approval, rejection, recovery, and audit relations while preserving local stream order, explicit cross-stream dependencies, and concurrency among incomparable objects. It is not an authoritative total timeline.

For brevity, later sections may write R_P(O) for the composed pipeline R_P(A(O)). The primary determinism requirement is permutation invariance. For every permutation π of the same canonical candidate collection:

R_P(A(π(O))) = R_P(A(O))

The equality applies to canonical serialization of both G and I, not to incidental in-memory order or diagnostic formatting. Delayed arrival changes the currently available set and may legitimately change a view from partial to authoritative or disputed; different enumeration orders of the same set must not change the result.

Determinism proposition. Let O be a finite source multiset and P a fixed profile. Assume that: (1) source normalization is a pure function of source identity and covered bytes; (2) duplicate classification, validation, authority checks, lifecycle checks, and issue identifiers are functions of canonical object values and P; (3) graph edges are derived only from within-stream sequence and profile-declared relations; and (4) graph and issue serialization use published deterministic ordering and tie-break rules. Under these conditions, the composed operation R_P(A(O)) is invariant to source enumeration order.

Proof sketch. Aggregation maps any enumeration of O to the same canonical indexed candidate multiset because indexing and duplicate classification depend on canonical source values rather than discovery position. Per-object validation is order-independent. Set-level checks—duplicate identifiers, stream gaps, missing references, prohibited cycles, authority conflicts, and lifecycle conflicts—are computed over the same canonical sets and relations. The accepted node set and directed edge set are therefore identical for every permutation. Canonical issue identifiers and deterministic ordering produce the same I; canonical graph serialization and a stable tie-break used only for representing incomparable nodes produce the same serialized G. Consequently, every permutation yields byte-equivalent canonical outputs. This argument establishes permutation invariance under the stated profile contract; it does not prove semantic truth, profile correctness, resistance to compromised trust roots, or equality across different evidence sets. A mechanized proof and executable corpus remain required for stronger assurance.

A reconstructed subject or subgraph is classified as:

• authoritative when required evidence is valid and no unresolved integrity, authority, lifecycle, ordering, or required-reference issue affects the conclusion;
• partial when required evidence is missing or a stream or dependency is incomplete;
• disputed when multiple valid but incompatible governance claims remain unresolved;
• quarantined when a profile-defined integrity, identity, duplicate-ID, or prohibited-cycle condition excludes the affected evidence from authoritative reconstruction.

Authentication is an orthogonal assurance label. An object or view may be structurally authoritative under TMPA Core while remaining unauthenticated under a stronger identity profile; it must not then be presented as authenticated integrity.

TMPA requires conflict preservation: valid contradictory objects remain represented until a new authorized resolution object exists. It also requires evidence preservation under extension: adding candidate evidence does not erase prior source evidence. TMPA does not assume monotonicity of governance status under arbitrary set extension, because newly added valid evidence may legitimately change a previously authoritative view into a partial, disputed, or quarantined one.

Read-side reconstruction is therefore not the whole architecture; it is the stage that converts durable textual messages and asynchronous serial streams into a coherent process and governance result. A deterministic topological serialization may be generated for interchange or display, but that serialization does not add governance order between incomparable nodes. C11 operationalizes source-aggregation and reconstruction determinism; C03, C04, C09, C10, and C12 exercise identity, ordering, dependency, cycle, and conflict-preservation behavior. A mechanized proof of the full reconstruction properties remains future work.

4.7 Integrity and Signature Evidence

TMPA separates three properties that are often conflated:

1. Attribution: an object declares a creator and responsible role.
2. Integrity: modification of a published object can be detected.
3. Authenticated integrity: the object is cryptographically bound to a verified identity or key.

TMPA Core requires attribution and integrity evidence. A deployment may claim authenticated integrity only when it applies a trusted identity, signature, and key-management profile.

An integrity record identifies:

• the canonicalization profile;
• the hash algorithm;
• the content digest;
• predecessor or referenced digests when required by the profile;
• an optional signature algorithm;
• an optional key identifier;
• an optional signature value.

A role label is not a cryptographic signature. A digest without a trusted identity binding can detect modification but cannot prove who created the object. A valid signature proves origin and integrity under the deployed trust model; it does not prove that the signed content is semantically true.

4.8 Conceptual Relation, Historical Lineage, and Operational Stack

The orientation map in Section 1 distinguishes historical lineage, current conceptual relation, and end-to-end operation. This section fixes the software boundary:

TMPA architecture
        ↓ reusable FCoP protocol profile realizing a defined subset
FCoP
        ↓ adopted as coordination and governance infrastructure by
CodeFlowMu and other applications

FCoP is independently specified and implemented; CodeFlowMu is a downstream adopter. Neither defines the broader TMPA architecture.

The operational FCoP stack is:

Application Layer          CodeFlowMu / Cursor / Claude Desktop
Host Adapter Layer         fcop-mcp / fcop-cli / host bridges
FCoP Protocol Layer        collaboration / reporting / review /
                           capability governance / events / audit
Reference Implementation   fcop Python library
Execution Substrate        LLM APIs / MCP tools / filesystem /
                           process manager / operating system

TMPA is not a runtime component in this stack. The fcop package is the reference implementation of FCoP; CodeFlowMu is a broader application environment. This separation preserves both historical accuracy and conformance boundaries.

---

5. Research Design and Evaluation Method

This work is a design-science architecture study. It constructs a governance artifact, examines its internal properties, instantiates it through a reference profile, and evaluates bounded engineering evidence. It is not a causal trial, a performance benchmark, or a claim of ecosystem adoption.

5.1 Design-Science Procedure

The study follows five linked stages:

Stage	Research operation	Output and research question
problem diagnosis	analyze coordination gaps in chats, logs, workflows, and the XiaoDian lineage	DR1–DR8; RQ1
artifact construction	define objects, streams, authority, lifecycle, and reconstruction rules	TMPA architecture; RQ2
analytical evaluation	examine invariants, counterexamples, and assurance boundaries	structural soundness; RQ1–RQ2
reference instantiation	map FCoP artifacts and operations to TMPA concepts	implementation feasibility; RQ3
case observation and conformance baseline	inspect CodeFlowMu and XiaoDian paths, fixtures, and pinned test results	bounded demonstration; RQ3

The units of analysis are a governance object, a governed work item, a reconstructed view, and a deployment profile. These units prevent product features, individual files, and architecture-level claims from being treated as interchangeable evidence.

5.2 Evidence and Claim Protocol

Evidence is classified as specified, implemented, demonstrated, or independently adopted. Conformance evidence additionally records fixed source revisions, evidence hashes, execution prerequisites, expected and actual outputs, and one of four product verdicts: PASS, PARTIAL, NOT RUN, or FAIL. A fixture-oracle match is reported separately from product execution.

This protocol limits three common inference errors. Historical artifacts are not retroactively presented as purpose-built conformance tests; prerequisite failures are not converted into passes or product failures; and author-produced cases are not treated as independent adoption. The procedure supports structural and implementation-feasibility claims, but it does not support causal claims about productivity, cost, reliability, or organizational outcomes.

5.3 FCoP as Reference Instantiation

FCoP (File-based Coordination Protocol) is the reference profile used to examine whether TMPA semantics can be realized on an ordinary project-visible filesystem. The conceptual relation is:

TMPA architecture → reusable FCoP protocol profile → CodeFlowMu and other applications

FCoP is not identical to TMPA. It realizes a file-based subset through named textual artifacts, lifecycle directories, append-oriented transition evidence, schemas, runtime tools, and adapters [7]–[12]. CodeFlowMu is a downstream application that uses FCoP concepts in a persistent multi-role development environment [13].

FCoP element	TMPA interpretation
artifact identifier or filename stem	stable transport-visible object identity
sender and recipient	declared writer and intended responsibility transfer
lifecycle path and transitions	profile-defined state and transition evidence
references, ref_task, subject_ref	typed causal or governance links
REVIEW plus approval evidence	independent verdict and decision
supersedes	correction without destructive rewrite
archive/history	retained terminal evidence

Under this profile, one task has one stable transport-visible carrier; reports, reviews, issues, approvals, and corrections remain separate artifacts. Writers publish independently, while readers inspect the available source set. The published runtime specification, schemas, packages, adapters, governance middleware, ADRs, and documentation establish implementation and distribution paths, not broad adoption [8]–[16].

5.4 Case and Corpus Procedure

The historical lineage is XiaoDian AI → FCoP → CodeFlowMu. XiaoDian exposed the need to preserve acceptance, execution, review, rejection, and audit evidence across model sessions [25]. FCoP extracted the reusable coordination and review skeleton; CodeFlowMu supplied a larger persistent-work application.

The public CodeFlowMu demonstration includes task, report, review, issue, lifecycle, and audit views [13]. A worked NL2SQL case separates execution from review: an executor produces a report, while a reviewer checks authorization, schema use, read-only constraints, tenant isolation, joins, enumerations, and result reasonableness. This demonstrates the intended object chain; it is not a representative production benchmark.

Because the engineering evidence predates the C01–C14 labels, the consolidated corpus maps selected tests and artifacts to fixed criterion fixtures [28]. The evaluation procedure is to: (1) lock product versions and the execution environment; (2) inventory and hash evidence; (3) map artifacts and tests to each criterion; (4) run selected suites and fixtures while retaining expected and actual outputs; (5) assign product verdicts without hiding unmet prerequisites; and (6) report fixture consistency separately from product behavior.

The resulting evidence supports bounded structural feasibility: durable project-visible coordination, role-separated review, lifecycle gates, archive preservation, and restart-related recovery. It does not establish lower comparative cost, representative SME performance, independent adoption, portability across deployment profiles, or complete TMPA Core conformance.

6. Canonical Reconstruction Contract

A TMPA implementation may store evidence in different substrates, but it must expose a canonical textual projection sufficient for deterministic reconstruction. The reader receives a set of source candidates, not a trusted ordered log. It parses and validates candidates, preserves duplicate observations, distinguishes conflicting content under the same identifier, applies profile rules, and emits:

1. a canonical candidate set;
2. a partial-order process and responsibility graph;
3. an authoritative issue set;
4. statuses such as authoritative, partial, disputed, quarantined, or rejected.

A conforming reconstruction procedure performs the following logical steps:

RECONSTRUCT(source_candidates, profile):

  parse and canonicalize candidates
  validate schemas, identifiers, types, and integrity evidence
  preserve duplicate observations and conflicting candidates
  group valid objects by writer stream and check local sequence
  construct edges from sequence, references, lifecycle, and profile relations
  validate role authority, separation of duties, and lifecycle legality
  detect missing references, prohibited cycles, and unresolved conflict
  derive lifecycle, responsibility, review, and recovery state
  emit canonical graph and issue set

The procedure does not silently “repair” invalid evidence. A malformed object, illegal transition, missing reference, duplicate identifier with different content, or contradictory review remains observable through the issue set. A later authorized resolution may change the authoritative interpretation without erasing the earlier evidence.

6.1 Determinism

Let (S) be a fixed final set of source candidates and (P) a fixed profile. The reader is deterministic when every enumeration or delivery permutation of (S) produces the same canonical candidate set, graph, statuses, and issue set.

This is a set-based requirement, not a claim that every intermediate view is complete. Before all evidence arrives, the reader may report partial or disputed state. Once the available source set is identical, output must be invariant to discovery order.

The proof obligation follows from four constraints:

• canonicalization and validation depend on candidate content and profile rules, not enumeration order;
• within-stream order is derived from explicit sequence evidence;
• cross-stream order is derived from explicit references and lifecycle relations;
• conflicts are preserved as sets and issues rather than resolved by “last arrival wins.”

The current paper provides a proof sketch and executable fixture oracle, not a mechanized proof. The C11 fixture enumerates 24 permutations and obtains byte-equivalent oracle output, but the pinned products do not yet expose the complete canonical graph-and-issue serializer required for a product-level C11 verdict.

6.2 Integrity, Identity, and Truth

Digest and signature evidence must be interpreted narrowly. A digest can reveal covered-byte modification. A verified signature can bind bytes to a key under an external trust model. Neither proves that the signed statement is factually correct.

A malicious, compromised, or mistaken participant can publish a schema-valid, lifecycle-valid, digest-consistent, and even correctly signed report whose claims are false. TMPA Core can identify the object, preserve it, test its declared authority, and relate it to independent review; factual verification requires tool receipts, reproducible outputs, independent data sources, or domain-specific validation outside Core.

This distinction produces three separate questions:

Question	Required mechanism
Were these bytes changed?	digest or tamper-evident storage
Which authenticated principal signed them?	signature, key, and identity profile
Are the claims true?	independent verification or domain evidence

TMPA must not claim the guarantee of a surrounding identity, policy, or cryptographic system unless the deployment actually verifies that evidence under the corresponding profile.

7. Evaluation Results

The separately maintained TMPA Core Specification S0.4 remains the sole normative source for C01–C14 and all SHALL/MUST clauses. Detailed engineering evidence and criterion verdicts belong to the Implementation Case Report I0.4. This section evaluates the research questions without reproducing the specification.

7.1 Findings by Research Question

Research question	Finding and evidence	Boundary
RQ1: governance-state sufficiency	ordinary conversation and execution surfaces do not, by themselves, preserve enough explicit authority, lifecycle, conflict, and recovery state for deterministic governance reconstruction; supported by problem diagnosis, DR1–DR8, and object/reconstruction analysis	no comparative field experiment has measured failure rates against alternative architectures
RQ2: minimum architecture	stable carriers, single-writer streams, explicit authority and lifecycle, typed references, three-valued judgment, and source-preserving deterministic reconstruction form a coherent minimum contract; supported by invariants, counterexamples, the determinism proof sketch, and Core S0.4	the proof is not mechanized, and minimality is an architectural argument rather than a universal lower-bound proof
RQ3: engineering feasibility and boundary	FCoP, CodeFlowMu, and XiaoDian provide bounded evidence that substantial parts of the contract can operate in project-visible infrastructure; supported by reference mapping, operational cases, and the pinned C01–C14 baseline	full conformance, independent adoption, comparative SME burden, and cross-profile portability are not established

The result is therefore strongest for architectural coherence and bounded implementation feasibility. It is weaker for organizational effectiveness and ecosystem generalization, which require independent and comparative evidence.

7.2 Conformance-Domain Summary

The baseline is summarized by architectural domain; exact criterion definitions remain in Core S0.4 §10.2.

Domain	Criteria	Product-level result
object, immutability, and integrity	C01, C02, C03, C08	3 PARTIAL; 1 NOT RUN
authority and lifecycle	C05, C06, C07	3 PARTIAL
ordering, reference, and conflict	C04, C09, C10, C12	2 PARTIAL; 2 NOT RUN
determinism, recovery, and history	C11, C13, C14	1 PASS; 1 PARTIAL; 1 NOT RUN

These are product-level results for the pinned revisions, not a declaration of full Core, profile, or authenticated-governance conformance.

7.3 S0.4 Re-adjudication of the Pinned Baseline

I0.4 publishes the S0.4 corpus tmpa-s0.4-fcop-codeflowmu-20260803 [28]. It retains the pinned FCoP package 3.2.4 commit da79dfefd99f597c9e422ce9edec22157f915a21, CodeFlowMu V1.2.3 commit 8f342d028eb66e77d135bea58fdbc7f2d0627e3b, and bounded XiaoDian evidence, but separates Reference Reader fixtures from product verdicts.

The FCoP commit was directly retrieved and selected suites reran with 1,137 passed, 2 skipped, and 0 failed. The CodeFlowMu commit was not retrievable from the public CodeFlowMu-open history, so no fresh CodeFlowMu product execution is claimed. The public S0.4 Reference Reader passes all 14 synthetic fixtures; those passes are not product passes.

The product-level verdicts are:

Verdict	Criteria
PASS	C14
PARTIAL	C01, C02, C03, C04, C05, C06, C07, C09, C13
NOT RUN	C08, C10, C11, C12

No executed product criterion failed. That statement is limited to executed paths and is not “zero-failure full conformance.” C06 is PARTIAL under S0.4 because preserved product evidence does not emit both ILLEGAL_TRANSITION/invalid and LIFECYCLE_UNDETERMINED/undetermined.

7.4 Interpretation: Product Projection Gap

The nine partial verdicts share a dominant implementation gap. A generic S0.4 read-only Reference Reader now exists, while FCoP and CodeFlowMu do not expose maintained projection adapters that normalize their native evidence into:

source candidates
      ↓
canonical candidate set
      ↓
process and responsibility graph
      ↓
authoritative issue set
      ↓
authoritative / partial / disputed / quarantined view

Product projection would directly improve C03, C05, C09, and C13 and provide infrastructure for C04 and C07. It would also create the product execution path required by C10–C12. C01 still has schema-coverage gaps, C02 has a stricter immutability gap, C06 lacks complete canonical three-valued outputs, and C08 requires covered-content digest evidence.

The corpus and baseline are author-produced. The corpus is now public, but an independent rerun is still required before any independently validated claim.

8. Discussion, Limitations, and Threats to Validity

TMPA's contribution is a process-governance contract, not a complete enterprise agent platform. It makes work identity, responsibility, review, lifecycle, conflict, and recovery explicit at publication time and reconstructs them from durable evidence. FCoP demonstrates that a useful subset can operate in an ordinary project environment without a mandatory broker or coordination database.

The architecture does not replace:

• enterprise IAM, credential issuance, or key management;
• runtime gateways, policy engines, or admission control;
• model evaluation and factual verification;
• OTel, SIEM, CMDB, GRC, or enterprise agent inventory;
• database transactions, distributed consensus, or Byzantine fault tolerance;
• legal compliance programs.

These systems may supply identifiers, policy decisions, execution receipts, and protected storage to TMPA. Their guarantees remain external unless verified and referenced.

8.1 Evidence Maturity

The paper separates four claim levels:

1. specified — a rule, schema, or criterion is published;
2. implemented — code executes the rule;
3. demonstrated — an operational case exhibits the behavior;
4. independently adopted — an external system relies on and validates it.

The architecture and criteria are specified. FCoP supplies implementation evidence. CodeFlowMu and XiaoDian supply bounded demonstration evidence. Independent adoption is not established.

The author is also the originator and principal developer of the evaluated systems. This gives access to detailed artifacts but creates self-evaluation and selection risk. The corpus therefore labels author-produced evidence, non-gating field evidence, fixture-only oracle results, and product-level verdicts separately.

8.2 SME-First Claim

“SME-first” is an operational scope, not a claim that every SME has the same needs or that TMPA is unsuitable for larger organizations. The lightweight profile assumes limited platform and operations capacity. Larger deployments may preserve the same semantics through databases, object stores, identity systems, replication, and enterprise control planes.

The decisive empirical question remains whether the benefits justify the discipline and resource cost. Required measurements include:

Experiment	Required evidence
deployment burden	dependencies, installation steps, setup time, first-team time, backup, migration
reconstruction	delayed and permuted streams, intermediate partial state, byte-equivalent final output
fault and recovery	duplicates, illegal transitions, missing references, tampering, restart, recovery time
human inspectability	ability to identify ownership, missing evidence, review status, and next responsibility
adoption discipline	onboarding, bypass, correction, fallback to chat, perceived burden, continued use
representative workload	latency, CPU, memory, storage growth, conflict rate, and recovery time

The current corpus provides a normalized baseline but not these complete measurements.

8.3 Digital Employee Profile and Privacy

The term digital employee is used only as an engineering label for a persistent AI work role. It does not assert employment status, legal personality, consciousness, human intention, autonomous organizational authority, or replacement of an accountable human or organization.

A future profile may define job scope, acceptance of delegated work, handoff, suspension, reassignment, and retirement. These are application semantics, not changes to Core.

Textual governance improves inspectability but may expose sensitive information. Deployments should minimize content, separate secrets from governance metadata, apply access control and encryption, and define retention and erasure procedures. Immutability of governance history does not require public readability of sensitive payloads.

8.4 Threats to Validity

Construct validity. C01–C14 operationalize governance structure and reconstruction behavior. They do not directly measure factual truth, human usefulness, productivity, or organizational accountability. A criterion pass must not be interpreted as success on those external constructs.

Internal validity. The author selected the architecture, systems, cases, and evidence mappings and also ran the baseline. Version differences and retrospective mapping from historical artifacts to later criteria can affect the result. Fixed revisions, hashes, explicit prerequisites, and separate product and fixture verdicts reduce—but do not remove—this risk.

External validity. The principal implementation is a file-based profile, the case set is small, and much of the observed execution is project-local. The findings may not transfer unchanged to database-backed, highly distributed, regulated, adversarial, or high-throughput deployments.

Conclusion validity. The verdict counts are descriptive results for selected paths. They are not statistical estimates, evidence of full conformance, or causal comparisons with chat, event-log, workflow-engine, or database alternatives.

Reproducibility. The current corpus is author-produced. It now has a stable public repository path, executable reproduction command, environment declaration, and SHA-256 manifest. An independent rerun remains necessary.

8.5 Limitations and Falsification Conditions

TMPA's central claims should remain open to disconfirmation:

Claim	Evidence that would weaken or refute it
equal source sets permit deterministic reconstruction	conforming readers produce different canonical graph or issue outputs for the same profile and source set
durable textual evidence improves responsibility recovery	controlled recovery tasks perform no better than relevant alternatives, or cannot identify responsibility and missing evidence reliably
the architecture can operate with minimal infrastructure	required correctness depends on an undeclared coordination database, broker, global clock, or centralized mutable log
the SME-first profile is operationally feasible	deployment, maintenance, storage, or human-discipline costs outweigh measured governance benefits in representative SME use
the semantics are portable across profiles	independent implementations cannot preserve object, authority, lifecycle, conflict, and reconstruction semantics across different storage substrates

8.6 Publication and Reproducibility Boundary

A0.5 is the theoretical architecture paper. Core S0.4 is the normative source, and Implementation Case I0.4 is the engineering-evidence source. The paper may summarize those companion artifacts but must not silently redefine their meaning.

Before external submission, the corpus still requires a retrievable pinned CodeFlowMu source or reproduction package and at least one independent rerun. Low-resource deployment measurements remain a separate release requirement for the SME feasibility claim.

9. Conclusion

TMPA is an SME-first, minimal-infrastructure textual-message multi-agent asynchronous process architecture. Text carries durable work and state; each work item has one stable primary carrier; each published object has one writer and belongs to a local serial stream; independent streams progress asynchronously; and aggregation plus deterministic reading reconstructs the partial-order process, responsibility, lifecycle, conflict, recovery, and audit view.

The architecture arose through practice → method → theory: XiaoDian AI exposed the multi-role coordination problem, original TMPA identified the textual asynchronous method, FCoP extracted and matured its reusable file-coordination and review subset, CodeFlowMu supplied downstream application feedback, and this paper formalized the resulting objects, invariants, assurance boundaries, and conformance criteria. The early pipeline establishes origin, not retroactive Core conformance.

A0.5 answers RQ1 and RQ2 at the architectural level and provides a pinned, author-run baseline for RQ3. Under the I0.4/S0.4 re-adjudication, one product criterion passes, nine remain partial, and four were not run at product-reader level. No executed product criterion failed, but that statement is limited to the executed paths and must not be read as zero-failure full conformance. Selected FCoP suites recorded 1,137 passed, 2 skipped, and 0 failed; the pinned CodeFlowMu source was unavailable for a fresh run. The separate S0.4 Reference Reader passes all 14 synthetic fixtures, but this does not substitute for product execution or independent validation.

The decisive remaining question is RQ3: whether an organization can sustain the responsibility, review, recovery, and evidence benefits of TMPA in an ordinary project environment at acceptable resource and discipline cost. That claim still requires product projection adapters, a retrievable CodeFlowMu reproduction package, low-resource deployment and recovery measurements, baseline comparisons, representative use, and independent reproduction. TMPA also does not by itself establish authenticated identity, strong isolation, protected storage, Byzantine resilience, factual truth of participant claims, or ecosystem adoption.

---

Artifact Availability

The author-run S0.4 conformance corpus is identified as tmpa-s0.4-fcop-codeflowmu-20260803 and is public at research/conformance/tmpa-core-s0.4. It contains the Reference Reader, executable profile, criteria fixtures, product assertions, machine-readable verdicts, logs, external-run records, and SHA-256 manifest. It must still be cited as author-produced evidence rather than independent validation.

Data Availability

The paper does not publish production business data. The worked NL2SQL material is an illustrative governance reconstruction rather than a verbatim production export. Conformance fixtures and selected implementation evidence are included in the author-produced corpus; any future public release must preserve redaction, version, provenance, and checksum information.

Competing Interests and Author-Produced Evidence

The paper author is also the originator and principal developer of TMPA, FCoP, and CodeFlowMu. This relationship creates self-evaluation and selection risks. The paper separates specified, implemented, demonstrated, and independently adopted claims; the current baseline is author-run and does not constitute independent validation or ecosystem adoption.

References

[1] Model Context Protocol. “Specification.” https://modelcontextprotocol.io/specification/. Accessed 2026-07-30.

[2] A2A Protocol Project, Linux Foundation. “Agent2Agent Protocol,” Version 1.0 documentation and specification, 2026. Accessed 2026-07-30.

[3] World Wide Web Consortium. “PROV-DM: The PROV Data Model” and “Constraints of the PROV Data Model.” W3C Recommendations, 2013. https://www.w3.org/TR/prov-dm/. Accessed 2026-07-30.

[4] Martin Fowler. “CQRS.” 2011. https://martinfowler.com/bliki/CQRS.html. Accessed 2026-07-30.

[5] Scott Chacon and Ben Straub. “Git Internals — Git Objects.” Pro Git, second edition. https://git-scm.com/book/en/v2/Git-Internals-Git-Objects. Accessed 2026-07-30.

[6] Linux Foundation. “Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF), Anchored by New Project Contributions Including Model Context Protocol (MCP), goose and AGENTS.md.” 9 December 2025. https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-agentic-ai-foundation. Accessed 2026-07-30.

[7] FCoP Project. “FCoP — File-based Coordination Protocol,” repository README and architecture stack. GitHub, 2026. https://github.com/joinwell52-AI/FCoP. Accessed 2026-07-30. A release tag or commit hash is required for the submission snapshot.

[8] FCoP Project. “FCoP Runtime Specification · Single-Page Complete Edition,” 1.2.x specification line, 2026. Repository artifact; submission snapshot to be pinned by release tag or commit hash.

[9] FCoP Project. “FCoP IPC Envelope” and related machine-readable JSON Schemas, spec/schemas/, 2026. Repository artifact; submission snapshot to be pinned by release tag or commit hash.

[10] Python Package Index. fcop and fcop-mcp, version 1.2.1 distributions, 2026. Accessed 2026-07-30.

[11] Official MCP Registry. io.github.joinwell52-AI/fcop, fcop-mcp server entry, 2026. Accessed 2026-07-30.

[12] FCoP Project. “fcop + fcop-mcp 1.2.1 Release Notes,” including FCoPGovernanceMiddleware and append-only governance events, 2026. Release artifact.

[13] CodeFlowMu. “TMPA Browser” public demonstration. https://demo.chedian.cc/. Snapshot observed 2026-07-29; build and dataset identity remain to be fixed for a reproducible submission artifact.

[14] FCoP Project. “ADR-0031: Governance Alert Layer (GAL).” Accepted 2026-05-11. Repository artifact; submission snapshot to be pinned.

[15] FCoP Project. “ADR-0032: fcop_audit() — Protocol-to-Inspection Compiler.” Accepted 2026-05-12. Repository artifact; submission snapshot to be pinned.

[16] FCoP Project. “FCoP Three-Layer Semantic Execution Chain Model.” Canonical project reference, 2026. Repository artifact; submission snapshot to be pinned.

[17] Yi Nian, Aojie Yuan, Haiyue Zhang, Jiate Li, and Yue Zhao. “Auditable Agents.” arXiv:2604.05485, 2026. https://arxiv.org/abs/2604.05485. Accessed 2026-07-30.

[18] Mirja Kühlewind and Henk Birkholz. “An Architecture for Auditing AI Agent Delegation and Interactions.” Internet-Draft draft-kuehlewind-audit-architecture-00, Work in Progress, 18 May 2026. https://datatracker.ietf.org/doc/draft-kuehlewind-audit-architecture/00/. Accessed 2026-07-30.

[19] Google Cloud. “Register Agents.” Agent Registry documentation, updated 27 July 2026. https://docs.cloud.google.com/agent-registry/register-agents. Accessed 2026-07-30.

[20] Krti Tallam. “Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure.” arXiv:2605.05440, 2026. https://arxiv.org/abs/2605.05440.

[21] Maurits Kaptein, Vassilis-Javed Khan, and Andriy Podstavnychy. “Runtime Governance for AI Agents: Policies on Paths.” arXiv:2603.16586, 2026. https://arxiv.org/abs/2603.16586.

[22] Mert Cemri et al. “Why Do Multi-Agent LLM Systems Fail?” arXiv:2503.13657, version 3, 2025. https://arxiv.org/abs/2503.13657.

[23] OECD. “Empowering SMEs in the Age of AI: The 2026 OECD D4SME Survey.” OECD SME and Entrepreneurship Papers, No. 78, OECD Publishing, Paris, 13 April 2026. DOI: 10.1787/bf5a9816-en. https://www.oecd.org/en/publications/empowering-smes-in-the-age-of-ai_bf5a9816-en.html. Accessed 2026-07-30.

[24] Infocomm Media Development Authority, Singapore. “Singapore's Digital Economy at 18.6% of GDP, up from 14.9% in 2019; Growth Fuelled by Accelerating Digitalisation and AI Adoption across Sectors and Firms.” 6 October 2025. https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2025/singapore-digital-economy. Accessed 2026-07-30.

[25] SaigeAgent / XiaoDian AI Project. “多 AI 角色协同架构规划” [Multi-AI Role Collaboration Architecture Plan]. Phase 3 architecture planning document, version 1.2, first dated 21 March 2026 and updated 28 March 2026. Project archive. Section 7.0 introduces “Text-Message Multi-AI Parallel Architecture” and records the original one-task-one-carrier, textual-message, asynchronous-request, multi-role pipeline, and audit-trace design. A fixed public or archival snapshot is required before external submission.

[26] Christian Schroeder de Witt. “Open Challenges in Multi-Agent Security: Towards Secure Systems of Interacting AI Agents.” arXiv:2505.02077, 2025. https://arxiv.org/abs/2505.02077. Accessed 2026-07-30.

[27] Richard Kang and Yudho Diponegoro. “Governance Gaps in Agent Interoperability Protocols: What MCP, A2A, and ACP Cannot Express.” arXiv:2606.31498, 2026. https://arxiv.org/abs/2606.31498. Accessed 2026-07-30.

[28] TMPA Project. “TMPA Core S0.4 C01–C14 Conformance Corpus.” Corpus ID tmpa-s0.4-fcop-codeflowmu-20260803, executed 3 August 2026. research/conformance/tmpa-core-s0.4/; author-produced Reference Reader, fixtures, product assertions, results, logs, external-run records, and SHA-256 manifest. Independent rerun remains required.

[29] Zexun Wang. “Proof-Carrying Agent Actions: Model-Agnostic Runtime Governance for Heterogeneous Agent Systems.” arXiv:2606.04104, 2026. https://arxiv.org/abs/2606.04104. Accessed 2026-07-31.

[30] Rafflesia Khan, Declan Joyce, and Mansura Habiba. “AGENTSAFE: A Unified Framework for Ethical Assurance and Governance in Agentic AI.” arXiv:2512.03180, 2025. https://arxiv.org/abs/2512.03180. Accessed 2026-07-31.

[31] National Institute of Standards and Technology. “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile.” NIST AI 600-1, July 2024; updated April 2026. https://doi.org/10.6028/NIST.AI.600-1.