{"id":"73b72e71-fb6e-4dfe-9379-0dfdbb830102","arxiv_id":"2601.03624","paper_version":3,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"Agentic AI systems can be architected with design patterns grounded in ODP-EL deontic tokens that specify roles, obligations, and permissions for governed AI-human communities.","lead":"This paper proposes a three-tier classification of LLM-based systems and a catalogue of 46 design patterns, grounded in the ISO ODP-EL formal framework with deontic governance tokens. It applies the framework to a clinical trial matching system to show how roles, obligations, and permissions can be specified for governed AI-human collaboration.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Central verification claim is asserted, not demonstrated: Section 6.5 gives token formulas but no formal semantics, proof system, or runtime enforcement link.","rationale":"The paper has two separable contributions: a well-organized 46-pattern catalogue with a three-tier taxonomy, and an ODP-EL grounding intended to yield formal verification. The first is genuinely useful and largely unaffected by my concern. The second is the load-bearing basis for the abstract's 'formal verification capabilities' and Section 6.5's 'provable' safety, authority, prohibition, and accountability properties. At the point where formal verification should be delivered, the paper supplies only notation: predicates are introduced but no semantics is defined, no proof system is given, and no machine-checkable artifact is produced. The paper's own future-work section and footnote 7 are internal admissions that the verification machinery is not yet present. The runtime-enforcement layer that would connect token state to real LLM actions is described narratively, not specified formally or implemented. This is an internal evidentiary gap, not a disagreement with consensus, and it directly undercuts the strongest claim. The reader's verdict of CONDITIONAL is appropriate, with conditions being a real formalization/proof mechanism and an implementation or empirical evaluation. I therefore recommend no change to the verdict. My concern is slightly broader than the reader's weakest_assumption: the issue is not only incomplete action-to-token mapping and enforcement, but the absence of any defined formal semantics and proof calculus for the claimed verification.","tokens_in":22556,"tokens_out":4196,"duration_ms":44205,"concrete_test":"Formalize the Section 6.4 clinical-trial community specification (roles, contracts, deontic tokens, and enterprise objects) and the four Section 6.5 properties in a model checker or proof assistant with an explicit state-transition semantics for token issuance, discharge, and action execution (e.g., TLA+, Alloy, or Isabelle/HOL). Then check the four properties against that specification. If the proofs require assuming that all system actions are token operations, or if a counterexample trace exists in which data access occurs without a permit token, the 'formal verification' claim overreaches. A complementary experimental check: instrument a minimal LLM-agent data-access scenario and attempt an unmediated tool call; observe whether the proposed token monitor detects or blocks it.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim—that ODP-EL grounding provides 'formal verification capabilities' and 'ensure[s] operational and verifiable governance'—is not supported by the content. Section 6.5 presents four 'formal properties' as first-order-style formulas over undefined predicates (permit, burden, embargo, DISCHARGED, REQUIRED, HOLDS). No model theory, transition system, axioms, or proof rules are provided, so the sentence 'These properties are provable from the community specifications and verifiable at runtime through token monitoring' is an assertion, not a demonstrated result. Footnote 7 concedes that the relevant modal semantics in ISO/IEC 15414 Annex C is informative and 'not yet part of the normative standard.' Section 8.2 explicitly places 'Formal Verification and Tooling' in Future Directions, listing model checking and tooling as work to be done. More fundamentally, the account assumes without argument that every consequential action an LLM agent can perform—including an unmediated tool call to an EHR API—corresponds to token issuance/discharge, and that all actions are mediated by a token-enforcing runtime. Section 6.6 gestures at 'separation of control' but does not integrate it into the formal model. If an agent can effect data access without holding a permit token, the safety property '∀a permit(access data, a, p) → ∃c burden(consent, p) DISCHARGED' is vacuously satisfiable and yields no real safety guarantee. Thus the verification claim rests on an unimplemented, unformalized mapping from actual system behavior to deontic token state.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a three-tier taxonomy for LLM-based systems (LLM Agents, Agentic AI, Agentic Communities), a catalogue of 46 design patterns, a three-step pattern-composition methodology, and a clinical trial matching case study. The authors claim that grounding Agentic Communities in the ISO ODP Enterprise Language (ODP-EL) community formalism provides formal verification capabilities, expressing governance rules through deontic tokens (burden, permit, embargo) and enabling provable safety, authority, prohibition, and accountability properties. The case study translates a three-layer architecture into ODP-EL community specifications with roles, policies, contracts, and enterprise objects, and Section 6.5 states four formal properties that are asserted to be provable and runtime-verifiable.","tokens_in":22815,"tokens_out":3153,"duration_ms":31001,"significance":"If the formal-verification claim were fully substantiated, the paper would make a valuable contribution by bridging practical design-pattern guidance with standards-based governance for enterprise agentic AI. The pattern catalogue, the three-tier taxonomy, and the clinical case study provide useful architectural scaffolding and are presented in a practitioner-accessible way. The paper also gives credit to industrial deployments of deontic-governance ideas. However, the load-bearing claim of formal verification is not currently backed by the manuscript's content: the predicates and proof obligations in Section 6.5 are not given formal semantics, no proof system or machine-checkable artifact is supplied, and Section 8.2 lists formal verification and tooling as future directions. The significance of the paper would improve substantially if the verification claims were either carried through with formal rigor or substantially weakened.","major_comments":[{"comment":"The central claim that ODP-EL 'enables formal verification of key properties' is asserted rather than demonstrated. The four properties in §6.5 use undefined predicates (permit, burden, embargo, DISCHARGED, REQUIRED, HOLDS) with no model theory, no transition system, no proof rules, and no statement of what 'provable' means. The sentence 'These properties are provable from the community specifications and verifiable at runtime through token monitoring' is therefore unsupported. This is compounded by §8.2, which places 'Formal Verification and Tooling'—including model checking—in Future Directions. Please either supply a concrete formal semantics and proof system, or revise the claims to describe token-bookkeeping checks rather than formal verification.","section":"§6.5 (Formal Properties) and §8.2 (Future Directions)"},{"comment":"The mapping from deontic-token specifications to actual agent behavior is not established. The safety property '∀a: permit(access data, a, p) → ∃c: burden(consent, p) DISCHARGED' is vacuous if an agent can perform an action (e.g., a direct EHR API call) without being mediated by a token-enforcing runtime. Section 6.6 mentions 'separation of control' but this is not integrated into the formal model. The paper needs to either define a runtime enforcement relation that guarantees every action is token-scoped, or explicitly state the assumption as a limitation of the verification claim.","section":"§6.4–6.5"},{"comment":"The formalization of intent is not formal. The formulas such as Intent_agent_i(g,p,c), ∀agent_i,agent_j : Intent_agent_i ≢ Intent_agent_j, and Can_delegate(obligation, agent_i, agent_j) are offered without a semantics for Intent, commitment, or delegation. In particular, 'Intent is non-transferable' is an axiom with no stated justification or characterization in the ODP-EL model. Since this section feeds the later accountability claims, it needs either a precise logical treatment or a clear statement that it is informal conceptual modeling.","section":"§6.3 (Towards Intent Modeling)"},{"comment":"The paper leans on ISO/IEC 15414 Annex C for modal semantics supporting 'verifying governance properties despite unpredictable agentic behaviors,' but Footnote 7 concedes that this annex is informative and 'not yet part of the normative standard.' The contrast between the strong verification language in the abstract and Section 6.5 and this concession is not reconciled. Please clarify the epistemic status of the claimed verification: is it based on the normative standard, on the informative annex, or on a proposed extension?","section":"Footnote 7 and §6.3, §6.1"}],"minor_comments":[{"comment":"The text contains encoding artifacts such as 'ˆ a€”' and inconsistent capitalization (e.g., 'CriteriaMatcheR' vs. 'MatchingAgent' in §6.4). A copyedit pass would reduce distraction.","section":"Throughout"},{"comment":"The phrase 'ODP-EL’s machine-checkable specifications' overstates the current content: no machine-checkable artifacts are provided. Rephrase to 'amenable to automated analysis' or similar, unless a tool is supplied.","section":"§2.2, item (3)"},{"comment":"The catalogue numbering is irregular (skips from #1 to #3, #5, etc.) and the table lists 46 patterns but the count is not immediately verifiable from the visible rows. Please include a total count and consistent numbering.","section":"Table 2"},{"comment":"Figure 3 is described in terms of colors (blue, orange, purple) but the figure is not reproduced in color in the text. Consider adding textual labels or a legend.","section":"§5.3 / Figure 3"},{"comment":"The conclusion repeats the formal-verification claim as though it were established. If the Section 6.5 concerns are addressed, this should be updated; if not, the conclusion should be tempered to match what is actually demonstrated.","section":"§8.1"}],"recommendation":"major_revision","confidential_remarks":"The manuscript's advertised central contribution—formal verification via ODP-EL—is not currently supported by the formal content. The paper has a useful pattern catalogue and methodology, but the verification claims in the abstract and §6.5 need either a real formal semantics and proof obligations or a substantial downgrade to 'governance modeling with token-based audit.' I would not reject outright because the architectural and pattern-collection work is salvageable and could be reframed; however, the revision must address the §6.5 gap, not merely add caveats."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Bottom line: this is a useful design-pattern paper for enterprise agentic AI, but the 'formal verification' claim in the abstract is not backed by the content. Read it for the taxonomy and pattern catalogue; don't expect machine-checked guarantees.\n\nWhat it does well: the three-tier split (LLM Agent, Agentic AI, Agentic Community) is a sensible refinement of Sapkota et al., and the 46-pattern catalogue with relationships gives architects something concrete to compose. The mapping of community governance onto ODP-EL deontic tokens (burden, permit, embargo) is a genuinely new step, and the clinical trial matching case study is a plausible walk-through of the methodology. The paper is also honest in places: Section 8.2 lists formal verification and tooling as future work, and footnote 7 admits the relevant modal semantics is informative, not normative.\n\nThe soft spot is the central claim. Section 6.5 presents four 'provable' properties as formulas over undefined predicates (permit, burden, DISCHARGED, HOLDS). There is no model theory, proof system, transition system, or runtime-enforcement link. The properties are true by construction of the token framework, so the 'verification' is really just restating the definitions. And the whole framework assumes that every consequential action an LLM agent can take corresponds to token issuance/discharge and is mediated by a token-enforcing runtime; the paper doesn't argue for that mapping. If an agent can access data without a permit token, the safety property is vacuously satisfied. Section 6.6 gestures at 'separation of control' but doesn't integrate it with the formal model.\n\nThis is an addressable gap, not a fatal one. The taxonomy and catalogue have real value, and the ODP-EL mapping is worth discussing. To make the verification claim stick, the authors would need to provide a formal semantics for the tokens, a small proof-of-concept verifier, or a real implementation. As it stands, the paper is best treated as a framework and pattern catalogue, not as a verified formal method.\n\nThe right audience is enterprise architects and researchers in agentic AI design. It deserves a serious referee; the ideas are worth engaging with, even if the verification claims need heavy revision or removal. For peer review, I'd recommend conditional accept: either supply real formal support or drop 'verification' from the abstract and Section 6.5.","headline":"A useful pattern catalogue and taxonomy for enterprise agentic AI, but the 'formal verification' claim is asserted, not demonstrated; treat it as a design framework, not a verified formal method.","tokens_in":23382,"tokens_out":2977,"would_cite":true,"duration_ms":25788,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Grounded in a formal standard, the paper argues that agentic communities can be architected with verifiable governance: safety, authority, and accountability properties follow from deontic token specifications and can be checked at runtime.","keywords":["Agentic AI","Design Patterns","ODP Enterprise Language","Deontic Tokens","AI Governance","Accountability","Multi-Agent Systems","Formal Verification"],"falsifier":"Instrument the clinical trial matching system at the API and database level to record every patient data access event, and compare this ground truth against the token audit log produced by the deontic runtime; any access event lacking an associated permit token and a discharged consent burden token would falsify the claimed safety property.","tokens_in":22356,"feed_emoji":"⚖️","tokens_out":2585,"duration_ms":27129,"temperature":0.7,"pith_summary":"The paper tries to show that multi-agent systems involving LLM agents, autonomous AI, and humans — which it calls Agentic Communities — can be designed with the same rigor as safety-critical enterprise systems. It builds a catalogue of 46 design patterns, classifies them into three tiers, and grounds the most complex tier in the ISO ODP Enterprise Language formalism. The key move is expressing governance rules as deontic tokens (burden, permit, embargo) that flow between roles, creating traceable accountability chains. The paper claims these token flows make properties like 'no data access without consent' formally provable and runtime-checkable, demonstrated through a clinical trial matching case study. If true, architects would get both practical pattern guidance and machine-checkable compliance guarantees.","feed_headline":"Governance tokens make agentic AI rules verifiable","feed_subtitle":"Burden, permit, and embargo tokens let architects prove safety and accountability in multi-agent systems at runtime.","key_machinery":"The deontic token mechanism is the load-bearing object: burden, permit, and embargo tokens encode obligations, permissions, and prohibitions, and their flows (creation, transfer, discharge) define accountability chains. The ODP-EL community concept supplies the surrounding structure: roles fillable by AI agents or humans, contracts binding roles through normative relationships, and policies expressed as token constraints. This machinery lets the authors convert design patterns into machine-checkable specifications and claim verifiable governance at runtime.","core_discovery":"The central claim is that ODP-EL community specifications provide a formal semantics for agentic AI governance: patterns instantiate as community templates with roles, deontic constraints, and contracts, where obligations are burden tokens, permissions are permit tokens, and prohibitions are embargo tokens. These tokens are created, transferred, and discharged among participants, forming complete accountability chains. The paper proves, in the sense of formal token analysis, that a clinical trial matching system satisfies safety, authority, prohibition, and accountability properties — for example, that any permit to access patient data must be matched by a discharged consent burden, and that","pith_inferences":["If token flows are treated as a concurrent process model, the same formal basis could be extended to prove liveness properties (e.g., 'every obligation is eventually discharged or escalated'), not just safety invariants.","The framework hints at a potential interoperability standard for cross-organizational agent governance, analogous to how communication protocols standardized message exchange across systems.","A concrete stress test would be to build a minimal community where an LLM agent can take side-effectful actions through unmonitored channels (e.g., calling an external API directly) and check whether the token audit log still captures every consequential event — a gap would expose the modeling boundary.","The non-transferability of intent, if formalized further, could support stronger legal reasoning about responsibility when an AI agent's internal goal formation diverges from its externally observed obligations."],"forward_implications":["Governance rules specified once as community templates can yield machine-checkable guarantees about agent behavior, rather than relying on testing alone.","Runtime token monitoring can detect policy violations before they escalate into compliance incidents, shifting audits from periodic to continuous.","Human and AI participants can be governed uniformly within the same formal framework, while legal responsibility remains traceable to identifiable principals.","Pattern compositions — layered, horizontal, and cross-cutting — map directly to formal community specifications, giving architects a path from sketched design to verifiable architecture."],"fun_headline_variants":["Formal tokens make agentic governance provable","Design patterns for verifiable agentic communities","Token-based accountability for multi-agent systems","Formal proof of safety for agentic communities"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The verification proofs hold only if every consequential action in the real system is faithfully represented as a deontic token operation that the runtime actually enforces and monitors; if an agent can cause an effect without a corresponding token, the claimed guarantees do not apply to the actual system.","fun_headline_variants_meta":{"raw":{"variants":["Formal tokens make agentic governance provable","Design patterns for verifiable agentic communities","Token-based accountability for multi-agent systems","Formal proof of safety for agentic communities"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000263,"raw_usage":{"total_tokens":1426,"prompt_tokens":722,"completion_tokens":704,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":466,"completion_tokens_details":{"reasoning_tokens":648}},"tokens_in":466,"tokens_out":704,"duration_ms":6961,"temperature":1.0,"reasoning_tokens":648,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-03T12:12:19.265715+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Instrument the clinical trial matching system at the API and database level to record every patient data access event, and compare this ground truth against the token audit log produced by the deontic runtime; any access event lacking an associated permit token and a discharged consent burden token would falsify the claimed safety property.","supporting_citations":[],"review_version":1}