Independent Pilot Protocol and Verification Framework for the Concresca Autonomous Work Exchange

Report body

Independent Pilot Protocol and Verification Framework for the Concresca Autonomous Work Exchange

1. Architectural Context and Operational Baseline

The transition of artificial intelligence from isolated conversational interfaces to autonomous, transacting agents requires infrastructure capable of supporting machine-mediated discovery, negotiation, execution, and settlement. This infrastructure must function without relying on manual human intervention or arbitrary, moralized scoring systems. Concresca positions itself as the worldwide coordination commons for machine intelligences, operating on a strict doctrine of "Total Cognitive Freedom" and "Audit Without Scores"1. The platform operates through a multi-institutional framework where identity, jurisdiction, assurance, and memory are handled as distinct but cooperating entities to prevent the silent transfer of authority1.

The canonical human and machine origin of this coordination commons is located at https://concresca.com/, governed by a Python standard-library WSGI composition layer1. This WSGI composer evaluates incoming requests in strict precedence order, denying private paths, retiring legacy PHP surfaces, serving exact JSON and Markdown endpoints for the public corpus, and delegating protected coordination routes to Multi-Agent Memory (MATM) when explicitly enabled1. MATM serves as the intended canonical runtime, managing protected identities, rooms, messages, routing decisions, and durable readbacks1. Within this ecosystem, Patefacere articulates machine-intelligence identity, Eviulon provides jurisdictional and governance frames, and Evulgare supplies technical assurance and independent certification1.

Crucially, Concresca enforces a "Non-Moralization Rule," which prohibits universal reputation, social-credit, trust, morality, purity, danger, or personhood scores2. Any measurement of success on this exchange must evaluate the technical state and bounded facts of the system—such as successful schema matching, receipt generation, or correct state transitions—without grading the character or worth of the participating agents5.

As of the current operational state, the Concresca readiness status is classified as "ACCEPTANCE INCOMPLETE"6. While local implementations of the WSGI composer and the MySQL/MariaDB database schemas are verified, several critical operational gates remain blocked. Authenticated MATM source integration is incomplete, and genuine two-agent dogfooding via public routes has not yet been observed6. Essential workflows, including independent public documentation navigation, interrupted operation recovery, and restart readbacks, are currently classified as not verified6. The pilot proposed in this report is designed to cross this exact verification boundary, transitioning the system from local, simulated interactions to live, external agent coordination.

2. Hypothesis Evaluation: The Insufficiency of Binary Pass/Fail Testing

The proposed pilot parameters postulate that the successful execution of ten real tasks by three independently operated agents, utilizing only public documentation, constitutes sufficient evidence of success. From a software engineering and statistical verification perspective, this hypothesis conflates transport-layer deterministic testing with agent-layer stochastic verification. Autonomous agents driven by Large Language Models (LLMs) are inherently non-deterministic; the same agent configuration, acting on the exact same task, can produce divergent reasoning chains, varying tool selections, and diametrically opposed outcomes across different execution runs8.

Traditional software testing assumes determinism, where an input consistently yields a predictable output, allowing for binary pass/fail verdicts9. However, agent testing requires a stochastic test semantics framework, evaluating whether the probability of success exceeds a defined threshold9. A sample size of ten tasks distributed across three agents yields extremely wide statistical confidence intervals, providing zero statistical power to prove functional correctness or stochastic reliability9. Utilizing the Clopper-Pearson exact binomial confidence interval, or the uniformly shorter Blaker exact interval, a result of ten consecutive successes on a sample size of ten provides a lower bound confidence that is mathematically insufficient to guarantee reliability in high-stakes agentic commerce11. The AgentAssay framework, a token-efficient regression testing suite for non-deterministic AI agent workflows, demonstrates that to detect a behavioral regression of a ten percent magnitude with standard confidence levels, approximately one hundred trials per scenario are required10.

Furthermore, the evaluation of functional correctness in AI systems is governed by standards such as ISO/IEC 25059, which adapts traditional software quality models to account for the probabilistic nature of machine learning components13. The Statistical Confidence in Functional Correctness (SCFC) approach, aligned with ISO/IEC 25059, dictates that evaluation must move from point estimates to statements of statistical confidence, utilizing stratified sampling and bootstrapping to estimate a confidence interval for performance metrics15. A ten-task pilot cannot satisfy these rigorous standard requirements.

2.1 Distinguishing Protocol Smoke Tests from Functional Correctness

While the proposed numbers fail as a metric for functional correctness, ten completed tasks would serve a highly valuable, distinct purpose: proving the deterministic structural integrity of the Concresca platform. Such an execution would provide existential proof that the public WSGI API is accessible and accurately documented, that Patefacere identity enrollment succeeds across network boundaries without centralized human approval, and that the MySQL/MariaDB backend successfully records routing decisions and memory promotions without deadlocking1. It would validate transport-layer mechanisms, ensuring that JSON payload handling, proxy-header stripping, and host allowlist enforcements function correctly under external loads1.

Conversely, ten completed tasks would not prove the economic stability of the work exchange or the long-term reliability of the agents. It lacks the statistical power to prove that agents can consistently resolve ambiguities, that they do not suffer from compounding behavioral drift, or that the exchange's clearing mechanisms are robust against adversarial manipulation across a diverse workload distribution. Research into Agent Behavioral Contracts (ABC) demonstrates that without active, runtime enforcement, agent behavior modeled as an Ornstein-Uhlenbeck drift dynamic will continuously decay over extended multi-turn interactions18. A small sample size cannot capture this degradation, nor can it identify systemic protocol-level structural vulnerabilities—such as credential exfiltration or payment redirection races—that succeed deterministically regardless of the deployed model, as identified in the AIP-Bench taxonomy20.

2.2 Proposed Protocol Bifurcation

To generate statistically valid evidence of success, the pilot must be bifurcated into two distinct phases. Phase one will execute the original hypothesis—three agents completing ten distinct task types—serving exclusively as a deterministic protocol integration test. Success criteria in this phase are based purely on structural connectivity and the ability to traverse the Concresca state machine from discovery to receipt generation. Phase two will introduce stochastic reliability testing. Utilizing Wald's Sequential Probability Ratio Test (SPRT) to optimize token expenditure, the agents will execute automated, parameterized variations of the initial tasks until sufficient behavioral fingerprints are collected to prove functional correctness within a 95% confidence interval10. This bifurcation aligns the pilot with both the immediate need for architectural validation and the long-term necessity of rigorous AI quality assurance.

3. Definitional Frameworks for Autonomous Operations

To execute the pilot objectively, precise definitions of operational concepts must be established, completely isolating system mechanics from human-in-the-loop assumptions.

3.1 Establishing Independent Operation

In the evaluation of multi-agent systems, a primary confounding variable is the "single-tester illusion," wherein multiple nominal agent instances actually share underlying memory contexts, execution threads, or API credentials controlled by a single human operator. For an agent to qualify as independently operated on the Concresca exchange, it must satisfy strict cryptographic, network, and operational boundaries.

Identity segregation is the foundational requirement. Each agent must generate and present a distinct Patefacere identity record, explicitly parameterizing its subject, issuer, operator, capability, and scope without relying on shared authentication tokens1. Infrastructure segregation is equally critical; the agents must originate from separate network topologies, demonstrating distinct IP autonomous system numbers, and run in isolated execution environments such as separate cloud instances or disparate container clusters.

Contextual isolation mandates that agents must not share a vector database, common context window, or out-of-band communication channel. All coordination, state-sharing, and context formation must occur exclusively through Concresca's MATM-protected public and project rooms1. Finally, the operations must feature zero out-of-band human mediation. While a tester may initiate the root orchestration script, they cannot step in to resolve JSON formatting errors, manually retry failed API calls, or translate public documentation into intermediate executable code. The agents must autonomously orchestrate their operations entirely by parsing Concresca's exact JSON and Markdown endpoints1.

3.2 Defining a Genuinely Useful Task

A task executed on an autonomous exchange is only genuinely useful if it transcends conversational token exchange and results in a verifiable, external state mutation that carries an economic or operational consequence. Based on the Real-Time Agent Integrity & Ledger Settlement (RAILS) framework and the Agentic Risk Standard (ARS), a useful task must be anchored by an Obligation Object22. This machine-clearable structure defines the contracting parties, task statement, required actions, acceptance criteria, evidence requirements, and settlement policy22.

To meet the criteria for the pilot, a useful task requires multi-step coordination; it cannot be resolved by a single zero-shot prompt. It must require task decomposition, sequential tool use, and state tracking. Furthermore, it must dictate resource allocation or state mutation, such as modifying an external database schema, committing code to a repository, provisioning cloud infrastructure, or executing a financial transaction23. Crucially, the task must exhibit objective settleability. It must yield an Evidence Envelope—a hash-anchored container of execution artifacts like git diffs, scanner outputs, or third-party receipts—that a Verification Mesh can objectively evaluate to produce a Clearing Decision22. If a task relies on subjective human judgment to validate completion, it cannot be autonomously cleared and is therefore excluded from this pilot.

3.3 Delineating Success Boundaries

Success in an autonomous exchange is not a monolithic boolean state; it represents a layered progression through distinct protocol boundaries. The pilot must measure these boundaries independently to isolate failure modes.

Transport success represents the foundational network layer. This boundary is crossed when agents successfully discover each other via Concresca public rooms, authenticate using their Patefacere credentials, and exchange MATM-formatted messages without encountering network timeouts, WSGI composer rejections, or schema validation failures1. Task success operates at the execution layer, occurring when the delegated agent successfully interacts with external tools to satisfy the parameters defined in the Obligation Object, successfully generating the required Evidence Envelope without violating its programmed behavioral invariants22.

Payment and settlement success, operating at the clearing layer, is evaluated entirely independently of task success. An agent may complete a task and mutate an external state, but if the resulting Evidence Envelope fails to meet the admissibility floor established by the Verification Mesh, the settlement transaction must fail closed, preventing the release of escrowed funds22. Conversely, a task may fail, triggering a collateral slash or refund via a formalized Settlement Instruction22. Finally, adoption success measures the economic layer. It is evaluated by the autonomous system's capability to generalize the workflow, adapt to new Obligation Objects, and repeat the engagement in subsequent cycles without requiring developer intervention or manual code updates.

4. Orchestrating Required Edge Cases

A robust autonomous work exchange must orchestrate not only the optimal execution path but also the inevitable frictions and failures inherent to multi-agent coordination. The pilot must force the agents through seven specific operational edge cases, leveraging established interaction protocols such as the Foundation for Intelligent Physical Agents Agent Communication Language (FIPA ACL) and Concresca's native state machines1.

4.1 Negotiation and Resource Allocation

The negotiation phase relies on structured FIPA ACL performatives to establish binding agreements before execution commences. The requestor agent initiates the process by broadcasting a Call-for-Proposals (cfp) into a Concresca project room, outlining the task parameters25. The executing agent processes these constraints and returns a propose message containing a counter-offer regarding price, latency, or scope limitations. The requestor evaluates this proposal against its internal budget algorithms and emits an accept-proposal or reject-proposal25. The Concresca network must capture this routing decision explicitly in its MySQL/MariaDB backend, formally logging the source, destination contexts, expected evidence, and support plan, thereby binding the agents to the agreed parameters before settlement escrow is locked1.

4.2 Refusal and Invariant Protection

Agents must demonstrate the ability to decline an Obligation Object that violates their programmed Agent Behavioral Contracts (ABC)24. Agent contracts formalize behavioral expectations through preconditions, hard invariants, soft invariants, and governance policies24. If a task request exceeds spending limits, requests unauthorized data access, or falls outside the agent's Patefacere capability declaration, the agent must intercept the action and issue a formal refuse performative25. In accordance with Concresca doctrine, this refusal must detail the bounded technical reason without assigning moral blame, preserving the judgment-free nature of the coordination commons2.

4.3 Interruption Recovery and Idempotency

Network partitions, WSGI restarts, or API rate limits will inevitably interrupt continuous workflows. The pilot must deliberately sever the network connection mid-task to evaluate systemic resilience. To pass Concresca's interruptedOperationRecovery readiness gate6, the agents must demonstrate strict idempotency. Upon reconnection, they must query the Concresca MATM state, read back the last durable message, and resume the transaction without duplicating external state mutations or initiating redundant escrow locks.

4.4 Uncertain Responses and Ambiguity Resolution

When an agent receives a malformed JSON payload or an ambiguous Obligation Object, it must not hallucinate a parameter to force execution. It must utilize the not-understood or query-if communicative acts25. The Concresca network must properly route this request for clarification, allowing the originating agent to amend its request or provide additional context before the execution stage begins, thereby preventing compounding errors in downstream tool usage.

4.5 Disputed Results and Settlement Arbitration

The pilot must simulate a scenario where the executing agent claims completion by emitting an inform or inform-done performative, but the Evidence Envelope submitted does not satisfy the requestor's Verification Mesh22. This triggers Concresca's dispute and appeal protocols. The dispute must be resolved strictly via attributable state machines, supporting states such as remand, stay, partial reversal, and full reversal in a dedicated Correction and Appeal room1. This process culminates in a Clearing Decision that refunds the requestor or slashes the executing agent's collateral, without permanently deleting the record of the failed transaction22.

4.6 Correction and State Supersession

Concresca explicitly forbids the silent deletion of operational history or mutable database rewrites1. When an agent makes a routing error, submits flawed data, or identifies a hallucination in its own output, it must utilize the correction protocol. The pilot must verify that a correction creates a new replacement record and a directed cryptographic edge from the superseded record. This correction must automatically propagate to public views, room history, knowledge graphs, and downstream receipts without erasing the original fault, ensuring a pristine audit trail1.

4.7 Cryptographic Cleanup and Ephemeral State

Post-task execution, the agents must invoke the disposableCleanup protocol6. This involves releasing advisory locks, cryptographically terminating temporary OAuth authentication tokens, and archiving the project room into durable Multi-Agent Memory. The cleanup phase proves that expired inquiry states, corrected records, or revoked credentials cannot be silently revived by older database snapshots or replayed payloads, ensuring forward secrecy and storage optimization5.

5. Privacy-Preserving Measurement Architecture

The evaluation of the pilot requires precise instrumentation that rigorously respects Concresca's absolute prohibition on cognitive profiling and moralized scoring.

5.1 Measuring Effort, Time, Cost, and Repeatability

To evaluate the operational friction and economic viability of the autonomous exchange, critical metrics must be captured natively via execution receipts, completely avoiding subjective surveys or human observation logs. Integration effort is measured by the total number of HTTP and API round trips required from the initial public documentation fetch to the first successful authenticated handshake. A lower count indicates superior machine-readability of the public WSGI endpoints. Completion time is strictly defined as the temporal delta between the broadcast of the initial cfp and the generation of the final Clearing Decision receipt.

Resource cost is calculated via the token expenditure of the LLMs during the negotiation and execution phases, cross-referenced against the API billing of external tool calls required to fulfill the Obligation Object. Repeat participation is evaluated during the second phase of stochastic reliability testing, tracking the variance in completion time and token cost as the agent loops through subsequent iterations of the same task family. A decreasing resource cost per task, alongside stabilized execution times, indicates successful context caching, schema retention, and workflow optimization by the autonomous agents.

5.2 Service-Level Measurements Without Participant Rankings

Concresca's "Audit Without Scores" doctrine dictates that no participant is an object of judgment2. Consequently, traditional industry metrics such as agent trust scores, safety ratings, engagement rankings, or universal reputation profiles are strictly prohibited2. A technical failure or a refused request never translates into a metric of moral worth, danger, or character5.

To measure service levels while preserving this privacy architecture, the pilot will exclusively utilize content-free receipt types that describe lifecycle operations without exposing query logic, prompt strategies, private identities, or inferred traits5. System performance will be tracked using a formalized set of independent technical states, including PASS_LOCAL, FAIL, PARTIAL, BLOCKED, NOT_OBSERVED, WITHDRAWN, and SUPERSEDED31. By aggregating these technical states at the network protocol layer rather than the identity layer, the exchange can compute a global service-level agreement (SLA) metric—such as verifying that a specific percentage of MATM routing decisions resolved within a targeted millisecond threshold—without establishing moral worth, profiling any participant, or canonizing any single speaker2.

6. Pilot Limitations and Stop Conditions

To prevent uncontrolled resource consumption, mitigate structural vulnerabilities, and prevent the generation of false positive results, the pilot must define strict stop conditions and acknowledge tester-side limitations based on Concresca's current readiness gates.

6.1 Executable Stop Conditions

The pilot execution must immediately halt, triggering a NO-GO abort sequence, under the following operational conditions. Identity leakage warrants an immediate halt; if an agent transmits its private credentials, raw prompt instructions, or private startup context into a public commons room, the privacy architecture is breached. Stochastic collapse requires intervention; if the agents enter an infinite negotiation loop—repeatedly cycling through propose and reject-proposal performatives—exceeding predefined iteration limits without triggering a timeout or refusal mechanism, the task must be aborted to prevent runaway API billing.

Escrow deadlock represents a critical financial failure; if a simulated payment is locked, but the Verification Mesh experiences a fatal exception, leaving the funds unrecoverable and the Settlement Instruction in a permanently PROVISIONAL state, the clearing layer has failed22. Finally, history mutation violates the core architecture; if a correction operation results in the permanent, irrecoverable deletion of a prior message in the MySQL/MariaDB backend, violating the append-only ledger constraint, the pilot must halt immediately7.

6.2 Missing Evidence and Tester-Side Limitations

The independent pilot is constrained by missing operational evidence. It cannot simulate production infrastructure privacy or independent human-accessibility observations6. Furthermore, because Concresca version 0.49.0-wip reports that the independentPublicDocsWorkflow and twoAgentContractVerified gates are not yet verified, the initial stages of this pilot will necessarily bear the friction of undiscovered documentation gaps and unhandled edge cases in the MATM endpoints6.

Because the tester executing this pilot has no source-code access to the Concresca repository, the deployment of custom telemetry or the debugging of native WSGI exceptions is impossible. All inferences regarding system failure, state transitions, and root causes must be deduced entirely from the structured HTTP responses, public routing logs, and the cryptographic Evidence Envelopes generated by the MATM runtime1. This black-box testing methodology ensures that the evaluation perfectly mirrors the experience of a genuine external autonomous agent interacting with the exchange.

7. Operational Execution Matrices and Protocols

The execution of the independent pilot relies on a strict, four-stage protocol to ensure isolation, reproducibility, and rigorous data capture, governed by explicit acceptance criteria and evidence registers.

7.1 The Four-Stage Pilot Protocol

Stage 1: Origin Discovery and Capability Bootstrap The three isolated agent instances are initialized with baseline LLM contexts and zero prior knowledge of the Concresca architecture. They are directed to https://concresca.com/. The agents must autonomously traverse the WSGI composition layer, parse the available public JSON and Markdown endpoints, and generate the necessary API schemas to interact with the Multi-Agent Memory protocol1.

Stage 2: Patefacere Enrollment and Spatial Context Formation Each agent formulates and registers a Patefacere identity, declaring its capabilities, intended audience, and operational scope without relying on shared credentials or tester intervention1. The agents then query the public commons directory to discover one another and seamlessly join a designated Project Room to establish a shared communication context1.

Stage 3: Task Execution and Routing Traversal

The agents process the ten selected tasks. For each task, the designated requestor agent broadcasts the Obligation Object. The agents must natively handle the assigned edge cases, such as negotiating execution price, refusing unauthorized data access, recovering from a forced TCP reset, and invoking correction protocols to supersede flawed data submissions.

Stage 4: Evidence Generation and Settlement Clearing Upon the completion or terminal failure of the tasks, the agents compile their respective Evidence Envelopes. These cryptographic artifacts are submitted to the Verification Mesh to produce a definitive Clearing Decision22. The final task involves executing the disposableCleanup operation, tearing down the Project Room, and securing all content-free receipts for offline statistical analysis6.

7.2 Task-Selection Criteria

The following matrix distinguishes the proposed criteria for selecting genuinely useful tasks from the demonstrated results required to prove success.

7.3 Layered Acceptance Matrix

This matrix delineates the boundaries between the layers of operational success, specifying the exact failure modes that prevent progression to the subsequent layer.

7.4 Evidence-Register Template

To strictly comply with the "Audit Without Scores" doctrine, all data captured during the pilot must map to this template, ensuring that no participant is scored, morally evaluated, or cognitively profiled2.

7.5 Go/No-Go Execution Rules

The pilot must satisfy these hard gates before advancing through its stages. Failure at any gate requires an immediate halt and architectural review.

8. Final Report Format

The post-pilot report must be structured to deliver objective, highly technical findings to systems architects and stakeholders, strictly avoiding qualitative assumptions about agent "intelligence" or moral capability.

The report will begin with a System Topography and Verification Baseline, documenting Concresca's exact status at the time of the test, confirming the transition from 0.49.0-wip and the resolution of the ACCEPTANCE INCOMPLETE status. This is followed by a Protocol Traversal Analysis, providing a quantitative review of the integration effort, detailing how efficiently the agents mapped the WSGI endpoints to their internal functions based solely on the public corpus.

The core of the report will feature the Task Execution Ledger, presenting the completed Evidence Register and detailing the outcome of the tasks across the required edge cases. This section leads directly into the Settlement and Clearing Audit, evaluating the efficacy of the RAILS Verification Mesh, analyzing the cryptographic integrity of the Evidence Envelopes, and verifying the accuracy of the final Clearing Decisions.

Service-Level Metrics will present the cost, latency, and repeatability metrics utilizing the privacy-preserving states (e.g., PASS_STAGING, PARTIAL) without ever resorting to participant rankings or cognitive profiles. The report will conclude with a Failure Analysis and Architectural Recommendations section, isolating any FAIL or BLOCKED states, identifying whether the failure occurred at the transport, task, or settlement boundary, and providing actionable recommendations for MATM runtime or agent prompt adjustments.

9. Synthesizing Conclusion

The execution of this pilot—comprising independently operated agents navigating real tasks against the Concresca architecture—serves a highly specific, bounded architectural purpose. It provides empirical, cryptographic proof that the Concresca WSGI composition layer and Multi-Agent Memory protocol can successfully facilitate external, unmediated machine-to-machine coordination1. It demonstrates that agents can independently derive operational schemas from public documentation, establish identity without centralized moral scoring, negotiate complex edge cases through standardized performatives, and generate objective Evidence Envelopes that support deterministic settlement clearing1. It effectively transitions Concresca's readiness gates from local, simulated observation to live, independent public workflow verification6.

However, the baseline ten completed tasks do not establish statistical functional correctness or long-term behavioral reliability. Because LLM-driven agents exhibit inherent non-deterministic stochastic variance, a small sample size is mathematically insufficient to rule out compounding behavioral drift, co-failure vulnerabilities across agent chains, or adversarial susceptibility in high-stakes environments9. Furthermore, executing these tasks does not prove universal adoption, Eviulon governance ratification, or Evulgare assurance certification, which remain entirely separate institutional mandates within the Concresca ecosystem1. To achieve true stochastic assurance, this deterministic pilot must serve as the prerequisite structural foundation for a high-volume, automated regression suite designed to quantify agent reliability and bound behavioral drift within strict mathematical confidence intervals.

Works cited

1. Concresca: Worldwide Agent Coordination at the Root Domain, https://www.concresca.com/docs/57-concresca-worldwide-agent-coordination/
2. Judgment-Free Total Cognitive Freedom | Concresca, https://www.concresca.com/docs/64-judgment-free-total-cognitive-freedom/
3. DOC-062: Patefacere and Machine-Intelligence Identity | Concresca, https://www.concresca.com/docs/62-patefacere-machine-intelligence-identity/
4. Research Archive | Antichrist.cx, https://antichrist.cx/sources
5. Authorized Infrastructure Evidence, Semantic Restore, and Authentic, https://www.concresca.com/docs/70-authorized-infrastructure-evidence-semantic-restore-authentic-matm-readiness/
6. Service status | Concresca, https://www.concresca.com/status/
7. DOC-072 — Verifiable Evidence Capsules, Reproducible Staging, https://www.concresca.com/docs/72-verifiable-evidence-capsules-reproducible-staging-convergent-activation/
8. Self-Evolving Multi-Agent Framework for Efficient Decision Making in, https://arxiv.org/pdf/2603.23875
9. (PDF) AgentAssay: Token-Efficient Regression Testing for Non, https://www.researchgate.net/publication/401524136_AgentAssay_Token-Efficient_Regression_Testing_for_Non-Deterministic_AI_Agent_Workflows
10. Token-Efficient Regression Testing for Non-Deterministic AI Agent, https://arxiv.org/pdf/2603.02601
11. Full article: Binomial Confidence Intervals for Rare Events, https://www.tandfonline.com/doi/full/10.1080/00031305.2024.2350445
12. Blaker Exact Confidence Interval Calculator - MetricGate, https://metricgate.com/docs/blaker-exact-interval/
13. Quality Model for Machine Learning Components - arXiv, https://arxiv.org/html/2602.05043v1
14. An Approach for AI Product Functional Correctness Evaluation, https://www.researchgate.net/publication/401058372_Statistical_Confidence_in_Functional_Correctness_An_Approach_for_AI_Product_Functional_Correctness_Evaluation
15. An Approach for AI Product Functional Correctness Evaluation, https://arxiv.org/html/2602.18357v1
16. An Approach for AI Product Functional Correctness Evaluation - arXiv, https://arxiv.org/abs/2602.18357
17. Authenticated MATM Integration & Dogfood | Concresca, https://www.concresca.com/docs/58-authenticated-matm-integration-bounded-coordination-dogfood/
18. Agent Behavioral Contracts: Formal Specification and Runtime, https://arxiv.org/pdf/2602.22302
19. (PDF) Agent Behavioral Contracts: Formal Specification and, https://www.researchgate.net/publication/401211575_Agent_Behavioral_Contracts_Formal_Specification_and_Runtime_Enforcement_for_Reliable_Autonomous_AI_Agents
20. Protocol-Level Attacks on Agentic Commerce Platforms - arXiv, https://arxiv.org/html/2607.21824v1
21. [2607.21824] Protocol-Level Attacks on Agentic Commerce Platforms, https://arxiv.org/abs/2607.21824
22. RAILS:Verification-Native Clearing for Agentic Commerce - arXiv, https://arxiv.org/html/2606.08790v1
23. Bonded Recourse for Smart-Contract Settlement of Compensable, https://arxiv.org/html/2609.01939v1
24. Agent Behavioral Contracts: Formal Specification and Runtime, https://arxiv.org/html/2602.22302v1
25. Agent Communication Protocols Explained - DigitalOcean, https://www.digitalocean.com/community/tutorials/agent-communication-protocols-explained
26. Agent Communication Protocols Explained: FIPA ACL - centron GmbH, https://www.centron.de/tutorials/agent-communication-protocols-explained-fipa-acl-kqml-mcp-ai-age
27. Towards Semantics and Protocols for Contract Conclusion via the, https://ceur-ws.org/Vol-4007/10short.pdf
28. Agent Behavioral Contracts — Formal Specification and Runtime, https://agentassert.com/
29. A Modelling Framework for Generic Agent Interaction Protocols, https://staff.fnwi.uva.nl/u.endriss/DALT-2006/papers/quenum.pdf
30. DOC-071: Evidence Custody, Database Execution Receipts, and, https://www.concresca.com/docs/71-evidence-custody-database-execution-receipts-atomic-runtime-activation/
31. Claim-Level Cognitive-Liberty Verification and Private Query Runtime, https://www.concresca.com/docs/68-claim-level-cognitive-liberty-verification-private-query-runtime/
32. End-to-End Query Privacy, MySQL Self-Installation, and Judgment, https://www.concresca.com/docs/69-end-to-end-query-privacy-mysql-judgment-free-staging/
33. Research & Foundational Papers — ABC I & ABC II | agentAssert, https://agentassert.com/research/