अंतरसंचालनीयता

Ethereum इकोसिस्टम के साथ

A-REX Core टोकन एक ERC-1155 टोकन है। ERC-1155 को समझने वाले वॉलेट, एक्सप्लोरर, मार्केटप्लेस और इंडेक्सर बिना बदलाव के काम करते हैं: बैलेंस, बैच ट्रांसफ़र, uri(id), अनुमोदन, सेफ़-ट्रांसफ़र रिसीवर जाँच। A-REX इवेंट और व्यू जोड़ता है; कुछ हटाता नहीं।

A-REX Core टोकन एक ERC-7943 मल्टी-टोकन है। ERC-7943 को लक्षित करने वाले अनुपालन इंजन और अभिरक्षा प्लेटफ़ॉर्म (Chainlink के Automated Compliance Engine ने संगतता प्रदर्शित की है; ERC-7943 गठबंधन के जारीकरण प्लेटफ़ॉर्म इसे अपना रहे हैं) canTransfer, forcedTransfer, setFrozenTokens, canSend और canReceive को बिना अनुकूलन के पहचानते हैं।

ट्रेसेबिलिटी डेटा मानकों के साथ

GS1 EPCIS 2.0 / CBV

मानक इवेंट-दर-इवेंट एक सूचनात्मक मैपिंग प्रकाशित करता है:

मेटाडेटा स्कीमा जान-बूझकर EPCIS/CBV नामों का उपयोग करती है ताकि निर्यातक अवधारणाओं को नहीं, फ़ील्ड को मैप करे।

सेंसर रीडिंग कोर का हिस्सा नहीं हैं। डिलीवरी हुक ऑन-चेन तापमान दर्ज कर सकता है; बाकी माप (नमी, CO₂ और O₂, झटका, झुकाव, दरवाज़ा, स्थिति) ऑफ़-चेन उसी sensorElementList में अपने CBV प्रकार और Rec. 20 इकाई के साथ रहते हैं। मैपिंग उन पर प्रतिबद्धता का एक पैटर्न बताती है: हर समय-खिड़की में तापमान की सबसे खराब रीडिंग, ऐसे संदर्भ के साथ जो खिड़की की हर रीडिंग और उसके मूल संदेश पर बना रूट है, ताकि ऑडिटर किसी रीडिंग को चेन से मिलाकर जाँच सके। प्रतिबद्धता यह साबित करती है कि उस ब्लॉक पर दर्ज करने वाले के पास क्या था, यह नहीं कि उपकरण ने सही मापा। रीड पॉइंट और व्यावसायिक स्थान साइट पहचानकर्ता हैं, कभी निर्देशांक नहीं।

UN Transparency Protocol (UNTP 0.7.0)

एक सूचनात्मक मैपिंग किसी बैच, उसके इवेंट और उसके एटेस्टेशन को UNTP 0.7.0 क्रेडेंशियल में बदलती है, EPCIS मैपिंग वाले ही आइडेंटिफ़ायर के साथ, ताकि दोनों को जोड़ा जा सके:

क्रेडेंशियल W3C Verifiable Credentials Data Model 2.0 का पालन करते हैं और जारीकर्ता के did:web के अंतर्गत VC-JOSE-COSE से हस्ताक्षरित होते हैं; निरस्तीकरण के लिए Bitstring Status List का उपयोग होता है। हस्ताक्षरित क्रेडेंशियल को उसके बैच से एक एटेस्टेशन के रूप में भी एंकर किया जा सकता है, जिसका संदर्भ क्रेडेंशियल का हैश हो; एंकर कमिटमेंट को सिद्ध करता है, हस्ताक्षर सामग्री को। क्रेडेंशियल में केवल वही होता है जो टोकन या उसके मेटाडेटा में है, और जिन मानों के लिए किसी पद्धति की आवश्यकता होती है (फ़ुटप्रिंट, जोखिम स्कोर) वे केवल तब दिखते हैं जब किसी नामित पक्ष ने उन्हें घोषित किया हो। मैपिंग यह बताती है कि वह क्या कवर नहीं करती, शुरुआत EU Digital Product Passport से: ESPR खाद्य, चारा या जीवित पौधों और पशुओं पर लागू नहीं होता, और A-REX उनके लिए कोई पासपोर्ट दावा नहीं करता।

माल कहाँ पैदा हुआ, यह कोड में दिया जाता है: देश (ISO 3166-1), पहले स्तर का उपविभाग (ISO 3166-2, जैसे BR-MG), और किसी कस्बे का UN/LOCODE केवल गोदाम या बंदरगाह जैसी व्यावसायिक साइट के लिए, खेत के लिए कभी नहीं। सेंसर रीडिंग डिलीवरी के MoveEvent के sensorData में जाती हैं; पासपोर्ट में अधिक से अधिक एक सारांश होता है। मेटाडेटा स्कीमा 1.3.0 (ADR-024, प्रस्तावित) से origin.region हमेशा ऐसा ही कोड होता है।

घोषित कार्बन फ़ुटप्रिंट (PACT 3.0.3)

ADR-018 (प्रस्तावित) किसी बैच को मेटाडेटा दस्तावेज़ के extensions.pact_pcf के अंतर्गत ऐसा उत्पाद कार्बन फ़ुटप्रिंट वहन करने देता है जिसे किसी तृतीय पक्ष ने परिकलित किया हो। यह अंश WBCSD PACT Technical Specifications 3.0.3 का फ़ील्ड-दर-फ़ील्ड पालन करता है: किसने घोषित किया, घोषित इकाई और संदर्भ अवधि, बायोजेनिक अवशोषण सहित और उसके बिना फ़ुटप्रिंट, और एक अनिवार्य सत्यापन स्थिति जो फ़ुटप्रिंट सत्यापित होने पर सत्यापनकर्ता का नाम देती है। इसे कॉपी किया जाता है; कभी परिकलित नहीं किया जाता, न जोड़ा जाता है, न लॉट से बने बैच तक आगे बढ़ाया जाता है, और यह कार्बन क्रेडिट नहीं है (ADR-014)। मैपिंग PACT का एक अलग व्युत्पन्न है और PACT की कोई फ़ाइल कॉपी नहीं करती।

कमोडिटी और इकाई कोड

कमोडिटी कोड किसी भी योजना के लिए keccak256("<SCHEME>:<CODE>") है: Harmonized System (HS), राष्ट्रीय टैरिफ़ नामपद्धतियाँ (Mercosur में NCM, EU में CN और TARIC, संयुक्त राज्य अमेरिका में HTS, और अन्य), FAO, CPC, GTIN, या जारीकर्ता की अपनी योजना। मेटाडेटा स्कीमा 1.1.0 से दस्तावेज़ में भी योजना खुली है, इसलिए मेटाडेटा ऑन-चेन कोड को प्रतिबिंबित कर सकता है। इकाइयाँ UN/CEFACT Recommendation 20 के कोड (KGM, TNE, LTR) हैं, वही सूची जिसका EDI, EPCIS और सीमा शुल्क पहले से उपयोग करते हैं।

FSMA 204

प्रमुख डेटा तत्व मेटाडेटा फ़ील्ड (traceabilityLotCode, GLN, तिथियाँ, मात्राएँ) और इवेंट हैं; ट्रांसफ़ॉर्मेशन CTE BatchTransformed है; 24 घंटे का रिकॉर्ड अनुरोध एक इंडेक्सर क्वेरी है। पूर्ण मैपिंग के लिए विनियामक अध्याय देखें।

Codex, ISO 22000, GLOBALG.A.P., जैविक योजनाएँ

सभी एटेस्टेशन विषय हैं। मानक उन्हें गिनाता नहीं: keccak256("GLOBALGAP:IFA"), keccak256("AREX:CERT:ORGANIC_EU"), keccak256("CODEX:MRL") ऐसी परंपराएँ हैं जिन्हें जारीकर्ता अपने मेटाडेटा स्कीमा के साथ प्रकाशित करता है।

विधिक-दस्तावेज़ रजिस्ट्री के साथ

A-REX टोकन विधिक लिखतों को संदर्भित करते हैं; जब तक कोई क्षेत्राधिकार स्वयं टोकन को मान्यता नहीं देता, वे उनकी जगह नहीं लेते:

पहचान प्रणालियों के साथ

टोकन केवल canSend(account) / canReceive(account) पूछता है। उस प्रश्न के पीछे हो सकता है:

• जारीकर्ता द्वारा संचालित अनुमति/ब्लॉक सूची (EligibilityHook);
• दावा विषयों वाली ONCHAINID पहचान रजिस्ट्री (ERC-3643 मॉडल);
• खाते पर Ethereum Attestation Service के एटेस्टेशन;
• वेरिफ़ायबल क्रेडेंशियल जिन्हें ऑफ़-चेन सत्यापित किया जाता है और रिले करने वाले द्वारा ऑन-चेन प्रतिबिंबित किया जाता है;
• क्रेडेंशियल सत्यापनकर्ता के माध्यम से राष्ट्रीय e-ID योजना (EU में eIDAS 2.0 वॉलेट)।

इनमें से कोई भी मानक का हिस्सा नहीं है, यही कारण है कि ब्राज़ील और जर्मनी के जारीकर्ता अलग-अलग प्रदाताओं का उपयोग कर सकते हैं और फिर भी अंतरसंचालनीय बने रह सकते हैं।

नियम इंजन और प्लेटफ़ॉर्म के साथ

कोई नियम या ऐड-ऑन एक arex.module/1 डिस्क्रिप्टर प्रकाशित कर सकता है: एक JSON दस्तावेज़ जिसमें उसके पैरामीटर, सेटिंग, आवश्यक बैच फ़ील्ड, प्रमाणपत्र-श्रेणियाँ, इवेंट, अस्वीकृति कोड और यह विवरण होता है कि उसकी स्टेट नए संस्करण में कैसे आगे जाती है। डिस्क्रिप्टर पढ़ने वाला प्लेटफ़ॉर्म, वॉलेट, इंडेक्सर या ऑडिटर किसी नए नियम को बिना कस्टम कोड के एकीकृत करता है। प्रारूप सूचनात्मक और प्रस्तावित है; जब कोई दूसरा स्वतंत्र कार्यान्वयनकर्ता इसका उपयोग करे, तब यह अनुशंसित प्रारूप बन जाता है। संशोधन 1.1 एक वैकल्पिक, सूचनात्मक ops सूची जोड़ता है जिसमें वे ऑपरेशन होते हैं जिन्हें कोई नियम नियंत्रित करता है; इसका न होना अज्ञात का अर्थ है, और इसका उपयोग कभी प्रवर्तन के लिए नहीं होता। संशोधन 1.2 स्थान-प्रकार ref:site जोड़ता है (वह originRef जो उसके बैच रखते हैं, कभी कोई अवस्थिति नहीं) और बताता है कि घोषित गैस सेटिंग भरी होने पर मापी जाती है (वैकल्पिक gas.setup)। संशोधन 1.3 उन फ़ील्ड का दस्तावेज़ीकरण करता है जिन्हें इसका पहला उपभोक्ता पहले से लिखता है (कार्रवाइयाँ, अनुबंध की अपनी त्रुटियाँ, माप, प्रति डिलीवरी डेटा और घटनाओं का पूरा रूप), सभी वैकल्पिक। संशोधन 1.4 वह जोड़ता है जिसकी किसी प्लेटफ़ॉर्म को ऐड-ऑन के फ़ॉर्म बनाने के लिए ज़रूरत होती है: अधिक मान-प्रकार, खाता-बही तक क्या पहुँचता है (व्यक्तिगत डेटा कभी नहीं), हर फ़ील्ड की प्रस्तुति और जाँचें, केवल-पढ़ने वाले दृश्य, और रिकॉर्ड EPCIS और UNTP पासपोर्ट में कैसे दर्ज होता है (उसके संगठन द्वारा घोषित एक विशेषता, कभी कोई दावा नहीं)। संशोधन 1.5 हर फ़िंगरप्रिंट में सॉल्ट जोड़ता है: जो डिस्क्रिप्टर fingerprint: { "scheme": "salted-jcs/1" } घोषित करता है, वह हर मान का हैश उसके अपने 32-बाइट सॉल्ट के साथ दर्ज करता है, ताकि छोटे पाठ, संख्याएँ या खेतों की रूपरेखा अनुमान लगाकर न खोजी जा सकें। संशोधन 1.6 ऐसे माप जोड़ता है जो योग नहीं हैं (किसी संख्या फ़ील्ड का avg, min, max, जिन्हें समूहों या कंपनियों के बीच कभी जोड़ा नहीं जाता) और उन्हें समूहित करने के दो तरीके, लॉट बनाने वाले पक्ष (party) और उसकी साइट (site) के अनुसार; संदर्भ रिलीज़ 2.0.0-alpha.10 का नमी ऐड-ऑन टेम्पलेट इसे प्राप्ति पर औसत नमी के लिए उपयोग करता है। संशोधन 1.7 किसी फ़ील्ड के visibleWhen को फ़ॉर्म के अन्य फ़ील्ड पर शब्दावली डिस्क्रिप्टर का शर्त-वृक्ष (all, any, not; अधिकतम 3 स्तर और 12 पत्तियाँ) लेने देता है; संशोधन 1.4 की एकल शर्त मान्य रहती है, पर अप्रचलित है।

संगठन अपने खेत के काम के प्रकार, प्रक्रिया के प्रकार और चरणों की सूचियाँ arex.vocab/1 शब्दावली परिभाषाओं के रूप में प्रकाशित कर सकते हैं। प्रत्येक परिभाषा 26 संदर्भ चरण वर्गों में से एक (उदाहरण के लिए drying या fermenting) और एक GS1 CBV व्यावसायिक चरण से जुड़ी होती है। उनकी EPCIS घटनाओं में तीन परतें होती हैं: CBV bizStep, जिसे कोई भी EPCIS प्रणाली पढ़ती है; संदर्भ वर्ग (arex:stageClass), जिससे अलग-अलग नामों वाले दो संगठन अपने रिकॉर्ड की तुलना कर सकते हैं; और संगठन का अपना प्रकार, नाम और प्रकाशित मान। UNTP पासपोर्ट में मान विशेषताएँ हैं, कभी दावे नहीं। किसी संसाधित लॉट का मेटाडेटा उसके पीछे की प्रक्रिया का प्रकार और निष्पादन एक process ऑब्जेक्ट में बता सकता है, जिसे मेटाडेटा स्कीमा 1.4.0 के लिए नियोजित किया गया है। संशोधन 1.1 एक वैकल्पिक फ़ॉर्म लेआउट (खंड, चौड़ाई, शर्तें) जोड़ता है, जो केवल यह सीमित करता है कि फ़ील्ड क्या स्वीकार करते हैं। संशोधन 1.2 शर्तों को not का उपयोग करने, 12 पत्तियों तक के साथ 3 स्तर गहराई तक जाने, और रिकॉर्ड का संदर्भ कोड में पढ़ने देता है (फ़सल EPPO कोड के रूप में, रोपण के बाद के दिन, साइट का प्रकार, देश, उत्पाद का HS शीर्षक, नवीनतम चरण); अज्ञात संदर्भ खाली पढ़ा जाता है। संशोधन 1.3 चरण सूची का क्रम (order) जोड़ता है: strict (डिफ़ॉल्ट; आवश्यक पिछला चरण पहले दर्ज होना चाहिए) या flexible (कोई भी क्रम, कमियाँ रिपोर्टों पर छोड़ी जाती हैं)। संशोधन 1.4 कॉफ़ी प्रसंस्करण विधियाँ जोड़ता है (washed, natural, honey, pulped_natural, wet_hulled, anaerobic और अन्य), जिन्हें प्रक्रिया प्रकार अपने आउटपुट को देता है और लॉट का process मेटाडेटा रखता है: संगठन की घोषणा, प्रमाणन नहीं। संशोधन 1.5 एक बंद सूची से व्यापक वर्गों (separating, conditioning, sorting_grading, heat_treating) के उपवर्ग जोड़ता है, ताकि पाठक किसी अन्य संगठन के व्यापक वर्ग वाले चरण का मिलान केवल उसके उपवर्ग से या प्रति प्रेषक एक स्पष्ट मैपिंग से करे। संशोधन 1.6 transporting का उपवर्ग to_processor जोड़ता है: माल किसी प्रसंस्करणकर्ता को भेजा जाता है जो उसे उसके मालिक के लिए संसाधित करता है (टोल प्रसंस्करण), इसलिए कब्ज़ा बदलता है पर स्वामित्व नहीं। लेजर टैग, चरण संदर्भ और साइट विषय सॉल्ट किए जाते हैं, इसलिए लेजर से कोई प्रक्रिया प्रवाह या खेत की समयरेखा पढ़ी नहीं जा सकती, और धनराशि कभी भी लेजर पर खुले रूप में नहीं लिखी जाती। किसी लॉजिस्टिक इकाई (एक SSCC, एक कंटेनर नंबर) के साथ दर्ज पैकिंग या लोडिंग चरण EPCIS के AggregationEvent से मैप होता है। संदर्भ रिलीज़ 2.0.0-alpha.9 में CompanyFactsHook ये रिकॉर्ड लेजर पर लिखता है और RequireStageHook उन लॉट की डिलीवरी अस्वीकार करता है जिनमें आवश्यक चरण नहीं हैं; इन दोनों में से कोई भी मॉड्यूल अनिवार्य नहीं है। यह सब सूचनात्मक और प्रस्तावित है।

क्रॉस-चेन डिप्लॉयमेंट

A-REX Core एक EVM मानक है (ADR-026, प्रस्तावित): अनुरूप टोकन paris स्तर या उसके बाद के किसी भी EVM नेटवर्क पर चलता है, और मानक नेटवर्कों की कोई सूची नहीं रखता; कोई संगठन कौन-से नेटवर्क उपयोग कर सकता है, यह उसकी नीति प्रोफ़ाइल तय करती है। नेटवर्कों को CAIP-2 आईडी से नाम दिया जाता है, जैसे eip155:8453 या hedera:mainnet। व्यावहारिक पैटर्न:

• प्रति जारीकर्ता एक होम चेन (अनुशंसित): वंशावली और प्रवर्तन सुसंगत रहते हैं; अन्य चेन ERC-7802-शैली एडेप्टर या CCIP के माध्यम से रैप किए गए निरूपण रखती हैं।
• अनुमति-आधारित EVM चेन उन जारीकर्ताओं के लिए जिनका डेटा-संरक्षण प्राधिकरण या एंकर संस्था इसे अपेक्षित करती है; EDPB अनुमति-आधारित डिज़ाइनों का स्पष्ट रूप से पक्षधर है। वही बाइटकोड।
• तरलता के लिए मिरर: होम चेन पर बैच आईडी, अन्यत्र ERC-20 रैपर; रैपर के लिए होम टोकन के canTransfer का पालन करना या स्वयं को पात्र धारकों तक सीमित रखना अनिवार्य है।

वंशावली कभी चेन पार नहीं करती; संदर्भ करते हैं। एक ही चेन पर या अलग-अलग चेन पर टोकनों के बीच, किसी अन्य टोकन के बैच से बना बैच अपने मेटाडेटा की upstream सूची (स्कीमा 1.2.0) में चेन आईडी, कॉन्ट्रैक्ट और टोकन आईडी द्वारा उसका नाम देता है। ये संदर्भ जारीकर्ता के दावे हैं, जिन्हें अपस्ट्रीम टोकन से मिलाकर जाँचा जाना है। स्कीमा 1.4.0 (प्रस्तावित) से, कोई प्रविष्टि CAIP-2 नेटवर्क (network) भी दे सकती है, और ऐसे नेटवर्क पर दर्ज बैच को, जो EVM नहीं है, उसके नेटवर्क और उसके CAIP-19 एसेट से नाम दिया जाता है।

ऐसे रिकॉर्ड जिन्हें कोई भी जाँच सकता है, किसी भी नेटवर्क पर

किसी टोकन से जुड़े साक्ष्य उस टोकन के नेटवर्क पर निर्भर नहीं करते। हर अवधि में एक बार, जारीकर्ता अपने रिकॉर्ड (ऑडिट लॉग, रिपोर्ट, दस्तावेज़) के फ़िंगरप्रिंट को एक Merkle रूट में जोड़ सकता है और उन 32 बाइट को कई स्वतंत्र नेटवर्कों पर प्रकाशित कर सकता है: अपने EVM नेटवर्क पर, OpenTimestamps के माध्यम से Bitcoin पर, और Hedera Consensus Service पर। हर रिकॉर्ड को एक छोटा arex.anchor-proof/1 प्रमाण मिलता है। जिसके पास रिकॉर्ड और उसका प्रमाण है, वह A-REX की किसी सेवा के बिना जाँच सकता है कि रिकॉर्ड बिना बदलाव के, अधिकतम उस समय तक मौजूद था जब प्रत्येक नेटवर्क को रूट मिला; कोई EVM कॉन्ट्रैक्ट OpenZeppelin MerkleProof से वही प्रमाण जाँच सकता है। केवल हैश प्रकाशित होते हैं, व्यक्तिगत डेटा कभी नहीं। यह प्रारूप सूचनात्मक और प्रस्तावित है (ADR-026)। कोई जारीकर्ता किन नेटवर्कों पर एंकर करता है, यह नीति का विषय है, जिसे उसकी क्षेत्राधिकार या संगठन प्रोफ़ाइल तय करती है, और कोई प्रमाण कितनी भी रसीदों के साथ मान्य है। Hedera रसीद रूट भेजते समय अपनी ट्रांज़ैक्शन ID बताती है, और कोई सार्वजनिक मिरर नोड पुष्टि करते ही संदेश की सीक्वेंस संख्या और कंसेंसस समय पा लेती है।

हस्ताक्षरित रिपोर्ट के आँकड़े कहाँ से आते हैं

जारीकर्ता के रिकॉर्ड से गणना की गई रिपोर्ट, जैसे "अक्टूबर में एक खरीदार को 1 200 kg की डिलीवरी" या रिकॉर्ड की एक सूची, अपने स्रोत साथ रख सकती है: पढ़े गए हर रिकॉर्ड के लिए एक पंक्ति, जिसमें लिखा हो कि लेजर उस रिकॉर्ड को कहाँ रखता है और रिपोर्ट ने कौन-से मान इस्तेमाल किए। हर पंक्ति एक arex.report-sources/1 स्रोत है; उसकी लीफ़ keccak256(0x03 ‖ JCS(source)) है, और क्रमबद्ध लीफ़ को जोड़े-जोड़े में मिलाकर एक स्रोत रूट बनता है। रूट और स्रोत फ़ाइल (<report>.sources.csv) का SHA-256 रिपोर्ट के साथ मुहरबंद होते हैं, उसके हस्ताक्षरित मैनिफ़ेस्ट में या किसी PDF के हस्ताक्षर के नीचे, इसलिए बाद में कोई पंक्ति जोड़ी, हटाई या बदली नहीं जा सकती। रिपोर्ट बताती है कि उसके कितने रिकॉर्ड लेजर से जाँचे जा सकते हैं, कितने लेजर पर मौजूद फ़िंगरप्रिंट के ज़रिए (दैनिक एंकर या रीडिंग विंडो), और कितने केवल जारीकर्ता के रिकॉर्ड हैं, जो उसकी मुहर के दायरे में आते हैं। कोई स्रोत कभी भी व्यक्तिगत मान को खुले रूप में नहीं रखता। पाठक यह सब A-REX की किसी सेवा के बिना जाँचता है: verify-sources.mjs, एक स्वतंत्र जाँचकर्ता (Node.js 20, कुछ भी इंस्टॉल नहीं करना) जिसे कोई भी कार्यान्वयन साथ दे सकता है, हर लीफ़ और रूट की फिर से गणना करता है, उन्हें रिपोर्ट से मिलाता है, फिर लेजर के हर रिकॉर्ड को उसके नेटवर्क के किसी भी नोड से पढ़ता है। कई कार्ड वाली रिपोर्ट में एक ही स्रोत फ़ाइल और एक ही रूट रहता है; हर पंक्ति वैकल्पिक सदस्य section (संशोधन 1.1) में अपना कार्ड बताती है, ताकि हर कार्ड की संख्याएँ अलग-अलग जुड़ें।

node verify-sources.mjs report.csv.sources.csv --manifest report.csv.manifest.json --rpc https://<a node of the network>

यह प्रारूप सूचनात्मक और प्रस्तावित है (रिपोर्ट स्रोत संशोधन 1.1)। मानक का दस्तावेज़, जो अर्ली एक्सेस के तहत साझा किया जाता है, फ़ाइल के कॉलम, हर जाँच और एक उदाहरण वेक्टर देता है; स्कीमा एक स्रोत का वर्णन करता है।

फ़ार्म प्रबंधन और ERP प्रणालियों के साथ

इंटीग्रेशन बिंदु किसी भी ERC-1155 टोकन जैसे ही हैं, साथ में बैच व्यू:

• राइट पाथ: एक ओरिजिनेशन सेवा ISSUER_ROLE रखती है और ERP इवेंट (वेब्रिज टिकट, रसीद जारी करना) से createBatch कॉल करती है; वेयरहाउस इवेंट से setBatchStatus/setBatchMetadata; प्रोसेसिंग ऑर्डर से transform।
• रीड पाथ: एक इंडेक्सर बैच, वंशावली, एटेस्टेशन और प्रवर्तन इवेंट को ERP की ट्रेसेबिलिटी तालिकाओं में मटीरियलाइज़ करता है; साझेदारों और नियामकों के लिए EPCIS निर्यात।
• प्री-फ़्लाइट: transferCheck ERP को ट्रांज़ैक्शन सबमिट करने से पहले किसी ऑपरेटर को इनकार का कारण समझाने देता है।
• आइडेंटिफ़ायर: मेटाडेटा में GS1 कुंजियाँ मौजूदा EDI और EPCIS रिपॉज़िटरी से सेतु बनाती हैं; UN/CEFACT इकाइयाँ ERP में पहले से हैं।

संगतता मैट्रिक्स