Internet Engineering Task Force (IETF) Y. Wang Internet-Draft HJS Foundation Intended status: Standards Track April 2026 Expires: October 20, 2026 Cognition-Oriented Emergence (COE): A Cognitive Interaction Protocol for Shared World Models draft-wang-coe-00 Abstract This document defines the Cognition-Oriented Emergence (COE) protocol, a lightweight, minimalist, narrow-waist cognitive interaction protocol. COE provides a unified "cognitive interaction layer" for the fragmented ecosystem of world models. Through four core primitives -- Judge (J), Delegate (D), Terminate (T), and Verify (V) -- COE enables heterogeneous world models and AI agents to reach verifiable consensus on shared world states within a traceable, auditable, and evolvable framework. Unlike JEP, which focuses on "accountability tracing" (post-hoc audit), COE focuses on "cognitive consensus" (ex-ante / in-situ collaboration). COE does not depend on any specific world model implementation; instead, it serves as a common "trust operating system" and "collaboration grammar" for them. JEP answers "who is responsible," and COE answers "what the world is" -- both share the J/D/T/V primitive gene, forming a complete "cognition‑accountability" dual-loop architecture. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 20, 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 1.1. Problem Statement 1.2. Relationship with JEP 1.3. Design Philosophy 1.4. Terminology 1.5. Requirements Language 2. Protocol Model 2.1. Core Cognitive Primitives 2.2. Narrow Waist Architecture 3. COE Event Format 3.1. General Event Structure 3.2. Field Description 3.3. Semantic Namespace and Context Isolation 3.4. Event Examples 4. Consensus Emergence Engine 4.1. Consensus Engine Overview 4.2. Consensus Policies 4.2.1. Simple Majority Policy 4.2.2. Weighted Trust Policy 4.2.3. Byzantine Fault Tolerance Policy 4.3. Consensus State Output 5. Versioned Audit Chain 5.1. Audit Chain Structure 5.2. Version Anchoring 5.3. Timestamp Anchoring 6. Security Considerations 6.1. Threat Model 6.2. Integrity Protection 6.3. Sybil Attack Defense 6.4. Replay Attack Defense 6.5. Consensus Blocking Attack 6.6. Privacy Protection 7. IANA Considerations 7.1. COE Primitive Registry 7.2. COE Consensus Policy Registry 8. Implementation Guide and Reference Implementation 8.1. Minimal Viable Implementation (COE-Lite) 8.2. Verification Scenario 8.3. Integration with Existing Standards 9. References 9.1. Normative References 9.2. Informative References Appendix A. Complete Verification Workflow Example Author's Address 1. Introduction 1.1. Problem Statement The world model field is flourishing with diverse technical approaches (e.g., JEPA, Dreamer, World Labs, Cosmos). However, these models are isolated from each other in architecture, data format, and interaction style, creating a severe fragmentation problem. When multiple agents (including humans and AIs) need to collaboratively perceive and understand the same physical space, three core problems become unavoidable: - Conflict Resolution: Observations from different world models may contradict each other; no uniform mechanism exists to reconcile them. - Consensus Formation: No trusted way exists to agree on "what the world state is at this moment" across multiple observers. - Traceable Verification: The process by which consensus is reached cannot be traced or audited, eroding the trust foundation. COE is designed as a standardized cognitive interaction layer to address these three problems. 1.2. Relationship with JEP COE and JEP share the same J/D/T/V primitives but serve different protocol layers: - JEP (Judgment Event Protocol): Focuses on accountability tracing (post-hoc audit), answering "who decided what, under whose authority, and who verified it" -- i.e., "who is responsible." JEP follows the philosophy of "minimal intrusion, maximum compatibility." - COE (Cognition-Oriented Emergence): Focuses on cognitive consensus (ex-ante / in-situ collaboration), answering "how do we collectively know what the world is" -- i.e., "what is the state." Together they form a complete "cognition‑accountability" dual-loop system: COE establishes a shared understanding of the world; JEP traces accountability for decisions made upon that consensus. COE events may be referenced by JEP as evidence. 1.3. Design Philosophy COE follows the "minimal intrusion, maximum compatibility" philosophy and adopts a classic "narrow waist" architecture: - Minimal core: Only J/D/T/V semantics plus lightweight consensus mechanisms. - Decoupled layers: Heterogeneous world models produce COE events via adapters; upper-layer applications rely only on the stable cognitive interaction grammar. - Verifiability: All events carry digital signatures and hash linking; the consensus process is fully auditable. 1.4. Terminology This document uses the following terms: - Cognitive Unit (CU): Any entity capable of initiating, receiving, or processing COE events (e.g., human user, AI agent, software service). Each CU has a unique identifier (e.g., DID). - World Model (WM): A model or framework that understands and predicts physical world states. COE does not prescribe its internal implementation. - Shared World State (SWS): An agreed-upon description of a physical or logical world state reached by multiple CUs via the COE consensus mechanism at a specific point in time. - COE Event: A digitally signed JSON object initiated by a CU, describing exactly one atomic operation (J/D/T/V) related to a world state. - COE Adapter: Lightweight software that translates a world model's internal outputs into standard COE event format. - Consensus Engine: Core component of a COE implementation that collects J/V events, resolves conflicts according to a policy, and produces the current Shared World State. - Audit Chain: A tamper-evident chain of COE events linked by cryptographic hashes in chronological order. 1.5. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Protocol Model 2.1. Core Cognitive Primitives COE inherits the four-primitive model from JEP and HJS, extending it into the "world observation" context: - J (Judge): Initiates an observation assertion about a world state. A CU declares "I observe X at this time." J events are the starting point of cognitive interaction and the base input for subsequent consensus. - D (Delegate): Delegates observation or confirmation authority to another CU. This transfers cognitive load, stating "I request / authorize you to observe or confirm X." D events can dynamically adjust the set of consensus participants. - T (Terminate): Declares that a previously initiated observation assertion (and its associated state) is no longer valid or should be terminated. This closes the lifecycle of a state. - V (Verify): Cross-validates or confirms one or more observation assertions from other CUs. This is the critical action for consensus emergence, stating "I confirm / verify that observation." V events provide credibility weighting for the consensus engine. These four primitives form a complete cognitive interaction algebra: any complex multi-agent collaboration scenario can be decomposed into an ordered combination of these four atomic operations. No fifth primitive is required. 2.2. Narrow Waist Architecture COE adopts a classic "narrow waist" architecture: ┌─────────────────────────────────────────────────────────────┐ │ Upper Layer: Diverse Multi-Agent Collaboration Scenarios │ │ (robot collaboration, AR/VR co-presence, distributed sci- │ │ entific consensus, cognitive economy transactions, etc.) │ └─────────────────────────────────────────────────────────────┘ │ │ COE Events (J/D/T/V) ▼ ┌─────────────────────────────────────────────────────────────┐ │ COE Core (Narrow Waist) — Standardized Only Here │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────┐ │ │ │ J/D/T/V │ │ Lightweight │ │ Versioned Audit │ │ │ │ Primitives │ │ Consensus │ │ Chain (Git-like │ │ │ │ (cognition │ │ Engine │ │ version control) │ │ │ │ grammar) │ │ (conflict │ │ │ │ │ │ │ │ resolution) │ │ │ │ │ └─────────────┘ └─────────────┘ └─────────────────────┘ │ └─────────────────────────────────────────────────────────────┘ │ │ COE Adapters ▼ ┌─────────────────────────────────────────────────────────────┐ │ Lower Layer: Heterogeneous World Model Implementations │ │ (JEPA, Dreamer, World Labs, Cosmos, game engines, physics │ │ simulators, etc.) │ └─────────────────────────────────────────────────────────────┘ Key advantages of the narrow waist: - Independent evolution: Lower-layer world models can evolve from JEPA to quantum physics engines without changing the COE core; upper-layer applications can evolve from simple collaboration to global cognitive economy networks while the core protocol remains stable. - Interoperability: Any world model capable of emitting J/D/T/V events can join the COE network. - Minimized trust base: The COE core is sufficiently small (reference implementation ~2000-3000 lines of code), making it easy to audit and formally verify. 3. COE Event Format 3.1. General Event Structure A COE event is a JSON object. All implementations MUST support the following fields: { // Required Fields "event_id": "", "protocol": "COE", "primitive": "J" | "D" | "T" | "V", "issuer": "", "timestamp": "", // World Model Context Fields "target": "", // J Primitive Fields (REQUIRED when primitive="J") "assertion": { "subject": "", "predicate": "", "value": "", "confidence": <0.0-1.0> // OPTIONAL }, // D Primitive Fields (REQUIRED when primitive="D") "delegate_to": "", "delegation_scope": "", // OPTIONAL // T Primitive Fields (REQUIRED when primitive="T") "terminate_of": "", "terminate_reason": "", // V Primitive Fields (REQUIRED when primitive="V") "verify_of": ["", ...], "verification_result": "confirmed" | "rejected" | "partial", // Audit Chain Fields "prev_event_id": "", "hash": "", "signature": "" } 3.2. Field Description - event_id: Globally unique event identifier; MUST be a UUID v4 [RFC4122]. - protocol: Protocol identifier; MUST be "COE". This distinguishes COE events from JEP or other protocols sharing the primitives. - issuer: Identifier of the CU that initiated the event; SHOULD be a W3C Decentralized Identifier (DID) [DID-CORE] or other URI. - timestamp: Event creation time; MUST conform to RFC 3339. - target: Identifier of the target world model or scene; used to associate all events pertaining to the same physical space. - assertion: Observation assertion object; REQUIRED when primitive="J". - subject: Identifier of the observed object. - predicate: Name of the observed property. - value: Value of the property; can be string, number, boolean, or JSON object. - confidence: OPTIONAL; CU's confidence in the observation, 0.0 to 1.0. - delegate_to: Identifier of the delegatee CU; REQUIRED when primitive="D". - delegation_scope: OPTIONAL; describes the scope of delegation (e.g., "continuous_observation", "one_time_confirmation"). - terminate_of: event_id of the J event being terminated; REQUIRED when primitive="T". - terminate_reason: Reason for termination (e.g., "observation_expired", "state_changed"). - verify_of: Array of event IDs being verified; REQUIRED when primitive="V". - verification_result: MUST be "confirmed", "rejected", or "partial". - prev_event_id: event_id of the previous COE event in the chain; may be null for the genesis event. - hash: SHA-256 hash of the canonical JSON serialization [RFC8785] of the event excluding the signature field. - signature: Digital signature over the hash field using the issuer's private key; MUST be Ed25519 [RFC8032] or ECDSA with SHA-256. 3.3. Semantic Namespace and Context Isolation COE and JEP share the J/D/T/V primitives but with different semantics. To avoid conflicts, all COE events MUST include the protocol field with value "COE". Implementations MUST select the appropriate semantic parser based on the protocol field: - If protocol="COE", interpret according to the "world observation" semantics defined herein. - If protocol="JEP", interpret according to the "accountability tracing" semantics defined in the JEP specification. A single CU MAY process both COE and JEP events, provided they are validated within their respective semantic contexts. 3.4. Event Examples Example 1: Robot A observes that a door is open (J event) { "event_id": "550e8400-e29b-41d4-a716-446655440000", "protocol": "COE", "primitive": "J", "issuer": "did:example:robotA", "timestamp": "2026-04-19T10:30:00Z", "target": "warehouse-zone-3", "assertion": { "subject": "door_01", "predicate": "status", "value": "open", "confidence": 0.95 }, "prev_event_id": null, "hash": "sha256:...", "signature": "..." } Example 2: Robot B confirms Robot A's observation (V event) { "event_id": "660e8400-e29b-41d4-a716-446655440001", "protocol": "COE", "primitive": "V", "issuer": "did:example:robotB", "timestamp": "2026-04-19T10:30:05Z", "target": "warehouse-zone-3", "verify_of": ["550e8400-e29b-41d4-a716-446655440000"], "verification_result": "confirmed", "prev_event_id": "550e8400-e29b-41d4-a716-446655440000", "hash": "sha256:...", "signature": "..." } 4. Consensus Emergence Engine 4.1. Consensus Engine Overview The consensus engine is the core component of a COE implementation, responsible for: 1. Collection: Listening for and collecting J and V events targeting the same world model (target). 2. Conflict Resolution: When different CUs issue conflicting assertions about the same subject, resolving the conflict according to the configured consensus policy. 3. Emergence: Producing the current Shared World State (SWS) and recording its generation process. 4.2. Consensus Policies A COE consensus engine MUST support at least one of the following policies and SHOULD allow pluggable configuration. 4.2.1. Simple Majority Policy Suitable for scenarios with a small number of CUs and equal trust. - Rule: Collect V events for a given assertion; the assertion is confirmed when the number of "confirmed" V events exceeds 50% of all V events received for that assertion. - Convergence condition: Evaluation begins after receiving at least 3 V events; a configurable timeout applies. 4.2.2. Weighted Trust Policy Suitable for scenarios with heterogeneous CU capabilities and reliability. - Rule: Each CU is assigned a trust weight w in [0, 1]. For an assertion, calculate confirmed_weight = Σ(w_i * confidence_i) for all confirming V events. The assertion is confirmed when confirmed_weight > threshold. - Weight management: Weight assignments MUST be managed in an auditable manner (e.g., recorded via JEP events) to prevent centralized manipulation. 4.2.3. Byzantine Fault Tolerance Policy Suitable for high-security scenarios where malicious CUs may exist. - Rule: A lightweight BFT variant requiring at least 2f+1 V events (where f is the number of tolerable Byzantine nodes), with more than f+1 being "confirmed". - Applicability: Recommended when the total number of CUs is at least 4. 4.3. Consensus State Output Whenever the consensus engine confirms or updates an assertion, it MUST produce a Shared World State (SWS) record: { "sws_id": "", "target": "", "timestamp": "", "assertions": [ { "subject": "", "predicate": "", "value": "", "confidence": <0.0-1.0>, "based_on": ["", ...], "consensus_policy": "", "confirmations": } ], "previous_sws_id": "", "hash": "" } The consensus state output SHOULD be anchored to the audit chain (see Section 5). 5. Versioned Audit Chain 5.1. Audit Chain Structure All COE events MUST be cryptographically linked via the prev_event_id field, forming a tamper-evident event chain. Integrity verification algorithm: def verify_chain(events): for i in range(1, len(events)): assert events[i].prev_event_id == events[i-1].event_id computed_hash = sha256(canonical_json(events[i] without signature)) assert computed_hash == events[i].hash assert verify_signature(events[i].signature, events[i].hash, events[i].issuer) 5.2. Version Anchoring Whenever the consensus engine produces a new SWS (Section 4.3), the SWS and all COE events upon which it depends MUST be packaged as a "version" and anchored to the audit chain. Version record format: { "version_id": "", "sws": { ... }, // SWS from Section 4.3 "dependent_events": ["", ...], "anchor_event_id": "", // Position in the audit chain "timestamp": "", "previous_version_id": "", "hash": "" } 5.3. Timestamp Anchoring For high-security scenarios, COE implementations SHOULD support submitting version hashes to a public trusted timestamp service (e.g., RFC 3161) or a blockchain (e.g., via OpenTimestamps). Timestamp anchoring provides an independent time proof, further strengthening non-repudiation. 6. Security Considerations 6.1. Threat Model COE assumes the following threat model: - An attacker may control a subset of CUs and attempt to inject false observation assertions. - An attacker may attempt to tamper with published event records. - An attacker may attempt denial-of-service by flooding events. - An attacker may attempt to collude to manipulate consensus outcomes. COE does not assume full trust among CUs, nor does it assume infallibility of underlying world models. 6.2. Integrity Protection Each COE event contains a hash of its content and the issuer's digital signature. Any tampering with event content will invalidate the hash and thus the signature. The audit chain's hash linking ensures event order cannot be altered. Implementations MUST verify signatures and hashes upon event receipt. 6.3. Sybil Attack Defense A Sybil attacker may create many fake CU identities to manipulate consensus. Defenses: - Implementations SHOULD require CUs to undergo trusted registration (e.g., endorsement mechanisms in DID methods). - Under weighted trust policy, newly registered CUs SHOULD start with low weight, increasing only with demonstrated trustworthy behavior. - Byzantine fault tolerance policy inherently resists Sybil attacks (provided the attacker controls no more than f nodes). 6.4. Replay Attack Defense An attacker may capture valid COE events and replay them later. Defenses: - Each event contains a unique event_id and timestamp. Implementations MUST maintain a cache of processed event IDs and reject duplicates. - Implementations SHOULD reject events with timestamps deviating excessively (e.g., more than 5 minutes). 6.5. Consensus Blocking Attack Malicious CUs may deliberately withhold V events or emit contradictory V events to block consensus. Defenses: - Consensus engine MUST implement a timeout mechanism, ignoring unresponsive CUs after timeout. - For contradictory V events, the consensus engine resolves according to policy (e.g., majority or weight) and does not stall due to individual malicious CUs. 6.6. Privacy Protection The assertion field may contain sensitive information (e.g., precise location data). Implementations MAY support selective encryption of the assertion field, making it readable only to designated verifiers holding the decryption key. Hybrid encryption schemes (e.g., ECDH + AES-GCM) are recommended. Furthermore, COE's three-layer privacy architecture (consistent with JEP) allows implementations to place sensitive payloads in a private payload layer, exposing only necessary public governance information to the audit chain. 7. IANA Considerations This document may require IANA to establish the following registries: 7.1. COE Primitive Registry - Registry Name: COE Primitives - Registration Policy: Specification Required [RFC8126] - Initial Contents: J (Judge), D (Delegate), T (Terminate), V (Verify) 7.2. COE Consensus Policy Registry - Registry Name: COE Consensus Policies - Registration Policy: Expert Review [RFC8126] - Initial Contents: simple_majority, weighted_trust, bft 8. Implementation Guide and Reference Implementation 8.1. Minimal Viable Implementation (COE-Lite) To facilitate community validation and adoption, a minimal reference implementation, COE-Lite, is recommended: - Core functionality: * J/D/T/V event generation and verification (including Ed25519 signatures) * In-memory audit chain maintenance * Simple majority consensus engine * HTTP REST API interface - Code size: Approximately 2000-3000 lines (Python or Go) - Excluded: Actual world model integration, persistent storage, distributed communication COE-Lite aims to demonstrate protocol feasibility, not production- grade readiness. 8.2. Verification Scenario The following scenario verifies the correctness of COE-Lite: Scenario: Three simulated robots (A, B, C) collaboratively confirm the state of a door. 1. A issues J event: assertion={door: open, confidence: 0.9} 2. B issues V event: verify_of=[A.J], verification_result="confirmed" 3. C issues V event: verify_of=[A.J], verification_result="confirmed" 4. Consensus engine (simple majority) outputs SWS: door=open 5. A observes door closed; issues T event (terminate_of=A.J), then new J event: door=closed 6. B and C confirm the new state sequentially 7. Consensus engine updates SWS: door=closed Verification checkpoints: - Audit chain integrity (all events correctly hash-linked) - Signature verification (all signatures valid) - Consensus convergence (both state transitions correctly output) - Version traceability (complete evolution from open to closed queryable) 8.3. Integration with Existing Standards - Identity: W3C DID [DID-CORE] or OAuth 2.0 [RFC6749] RECOMMENDED for CU identity management. - Environmental Trust: RATS [RFC9334] MAY be integrated to attest that a world model runs in a trusted execution environment. - Accountability: COE events MAY be referenced as evidence in JEP events, enabling seamless linkage from cognitive consensus to accountability tracing. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005. [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, January 2017. [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020. [RFC9334] Birkholz, H., et al., "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, December 2022. 9.2. Informative References [DID-CORE] Sporny, M., et al., "Decentralized Identifiers (DIDs) v1.0", W3C Recommendation, July 2022. [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012. [JEP] Wang, Y., "JEP: A Judgment Event Protocol", draft-wang-jep-judgment-event-protocol, March 2026. [HJS] Wang, Y., "HJS: An Accountability Layer for AI Agents", draft-wang-hjs-accountability, February 2026. [AIGA] Aylward, E., "AI Governance and Accountability Protocol", draft-aylward-aiga, January 2026. [MACP] Li, X., et al., "Multi-agent Collaboration Protocol Suite", draft-li-dmsc-macp, February 2026. Appendix A. Complete Verification Workflow Example This appendix presents an end-to-end example with a complete COE verification workflow, suitable as a reference test case for proof- of-concept implementations. A.1. Initial Setup - CU-A: Robot A (JEPA world model, trust weight 0.9) - CU-B: Robot B (Dreamer world model, trust weight 0.8) - CU-C: Human supervisor (trust weight 1.0) - Target: warehouse-zone-3 - Consensus Policy: weighted_trust (threshold=1.5) A.2. Event Sequence Step 1: CU-A observes door is open Event#1 (J): A -> COE: { assertion: {subject: "door", predicate: "status", value: "open", confidence: 0.95} } Step 2: CU-B delegates continuous observation to CU-A (optional, demonstrates D primitive) Event#2 (D): B -> COE: { delegate_to: "A", delegation_scope: "continuous_observation" } Step 3: CU-B confirms A's observation Event#3 (V): B -> COE: { verify_of: [Event#1], verification_result: "confirmed" } Step 4: CU-C (human) also confirms A's observation Event#4 (V): C -> COE: { verify_of: [Event#1], verification_result: "confirmed" } Consensus calculation: - confirmed_weight = 0.8 (B) + 1.0 (C) = 1.8 > threshold 1.5 - Output SWS#1: door = "open" Step 5: CU-A observes door is closed Event#5 (T): A -> COE: { terminate_of: Event#1, terminate_reason: "state_changed" } Event#6 (J): A -> COE: { assertion: {subject: "door", predicate: "status", value: "closed", confidence: 0.95} } Step 6: CU-B confirms new state Event#7 (V): B -> COE: { verify_of: [Event#6], verification_result: "confirmed" } Step 7: CU-C confirms new state Event#8 (V): C -> COE: { verify_of: [Event#6], verification_result: "confirmed" } Consensus calculation: - confirmed_weight = 0.8 + 1.0 = 1.8 > 1.5 - Output SWS#2: door = "closed" A.3. Verification Checkpoints 1. Audit chain integrity: - Verify all prev_event_id links are correct - Verify all hash calculations - Verify all signatures are valid 2. Consensus correctness: - Verify SWS#1 is based on Event#1, confirmed by Event#3 and Event#4 - Verify SWS#2 is based on Event#6, confirmed by Event#7 and Event#8 - Verify the door state transition from open to closed is correctly recorded 3. Version traceability: - Query history for "door" should return two versions - Each version can be traced back to its dependent J/V events 4. Fault injection tests: - Inject event with invalid signature; verify rejection - Inject event breaking hash chain; verify detection - Inject contradictory V events; verify consensus resolves correctly per policy Author's Address Yuqiang Wang HJS Foundation Ltd. Email: yuqiang@humanjudgment.org