شناسنامه سند
مجموعه قوانین بنیادین EarthCoop — جلد نهم — استانداردهای فنی EarthCoop — هویت، عضویت، گروه‌ها، رأی‌گیری، نجم‌بهار، داده، API، قرارداد هوشمند، امنیت، هوش مصنوعی، ممیزی و نسخه‌بندی سامانه‌ها
دیباچه
به نام خدای جان و خرد
استانداردهای فنی EarthCoop برای آن تدوین می‌شوند که قانون در سامانه، عدالت در داده، حق در API، اعتماد در رأی‌گیری، شفافیت در لاگ، مالکیت همگانی در نجم‌بهار، کرامت انسان در هوش مصنوعی، و پاسخ‌گویی در معماری نرم‌افزار قابل اجرا شود.
EarthCoop فقط مجموعه‌ای از اصول اخلاقی یا حقوقی نیست؛ سامانه‌ای شراکتی، چندسطحی، اقتصادی، اجتماعی و فناورانه است. بنابراین، اگر قانون آن قابل پیاده‌سازی، آزمون، ممیزی، نسخه‌بندی، مستندسازی و امنیت‌سنجی نباشد، عدالت آن نیز در عمل ناقص خواهد ماند.
این سند، زبان مشترک میان حقوق‌دانان، مدیران، بازرسان، توسعه‌دهندگان، متخصصان داده، متخصصان امنیت، اقتصاددانان، حسابرسان، داوران، اصناف، نهادهای محلی و کاربران EarthCoop است. هدف آن این است که هر اصل حقوقی، تا حد امکان، به معیار فنی، شناسه، مدل داده، رویداد، مجوز، API، وضعیت، لاگ، آزمون، گزارش و مسیر اعتراض تبدیل شود.
استانداردهای فنی، جایگزین قانون نیستند؛ ابزار اجرای دقیق، ایمن، شفاف، قابل ممیزی و سازگار قوانین‌اند. هیچ استاندارد فنی نباید به بهانه کارایی، سرعت، مقیاس‌پذیری یا امنیت، کرامت انسان، حق مشارکت، حق اعتراض، حریم خصوصی، عدالت یا سند مادر را تضعیف کند.
بخش نخست کلیات، ماهیت و اصول استانداردسازی
جایگاه و روابط اسنادی پیشنهادی: تابع منابع حقوقی و تفویض معتبر مربوط؛ استاندارد فنی به‌خودی‌خود حق، تکلیف ماهوی یا صلاحیت حقوقی ایجاد نمی‌کند.
> وضعیت حقوقی این متن: نسخه رسمی 1.0 — ثبت‌شده و نافذ از 2026-10-01. شماره‌گذاری رسمی اسناد از این نسخه آغاز می‌شود؛ سوابق پیشین صرفاً سابقه توسعه و ممیزی پیش از نسل رسمی 1 هستند.
۱. STD مجموعه قواعد و سازوکارهای فنی برای تبدیل الزامات معتبر EarthCoop به مدل داده، API، رویداد، کنترل دسترسی، state machine، امنیت، لاگ، آزمون و شواهد قابل ممیزی است. ۲. STD قانون موضوعی مستقل نیست و به‌خودی‌خود حق، تکلیف ماهوی، ممنوعیت حقوقی، مجازات، صلاحیت حاکمیتی یا پارامتر قانونی ایجاد نمی‌کند. ۳. هر استاندارد در حدود منبع یا منابع حقوقی اعطاکننده اختیار خود اعتبار دارد. ۴. استاندارد می‌تواند مقدار یا قاعده جاری قانونی را برای اجرای دقیق mirror کند، مشروط بر آنکه Legal Source، Legal Owner، Version و Change Authority روشن باشد و استاندارد اختیار تغییر مستقل آن را نداشته باشد. ---
هدف این سند عبارت است از: ۱. تبدیل قواعد حقوقی EarthCoop به الزامات فنی قابل اجرا. ۲. ایجاد زبان مشترک میان متن قانون و نرم‌افزار. ۳. تضمین سازگاری سامانه‌های EarthCoop با حقوق اعضا. ۴. استانداردسازی هویت، عضویت، گروه‌سازی، رأی‌گیری، نجم‌بهار، پروژه‌ها، بازار و داده. ۵. تعیین اصول APIها، قراردادهای هوشمند، لاگ‌ها، دفترکل، گزارش‌ها و حسابرسی. ۶. تضمین امنیت، حریم خصوصی، دسترسی‌پذیری و قابلیت اعتراض انسانی. ۷. جلوگیری از تمرکز پنهان قدرت فنی. ۸. فراهم‌سازی امکان توسعه متن‌باز، ممیزی مستقل و نسخه‌بندی پایدار. ---
تمام استانداردهای فنی EarthCoop بر اصول زیر استوارند: ۱. قانون‌پذیری. ۲. عدالت‌پذیری. ۳. انسان‌محوری. ۴. امنیت از آغاز طراحی. ۵. حریم خصوصی از آغاز طراحی. ۶. حداقل‌گرایی داده. ۷. شفافیت مسئولانه. ۸. قابلیت ممیزی. ۹. قابلیت توضیح. ۱۰. قابلیت اعتراض. ۱۱. نسخه‌بندی پایدار. ۱۲. متن‌باز بودن امور بنیادین تا حد امکان. ۱۳. دسترسی‌پذیری برای همه اعضا. ۱۴. منع تمرکز قدرت فنی. ۱۵. قابلیت بازیابی، پایداری و تداوم خدمت. ---
۱. در تعارض میان استاندارد و منبع حقوقی معتبر، منبع حقوقی حاکم است. ۲. قانون، مقرره یا Policy معتبر می‌تواند بخشی از جزئیات فنی را به STD تفویض کند؛ استاندارد فقط در حدود همان delegation لازم‌الاتباع است. ۳. Capability، Implementation، Migration، API، Job، Feature Flag، Configuration، Admin Panel، AI Agent یا کد به‌خودی‌خود منبع اختیار حقوقی نیست. ۴. STD نمی‌تواند مستقلاً حق رأی، وضعیت عضویت، جامعه پایه حکمرانی، صلاحیت نقش، علت توقف انتخابات، مقدار پولی، مالیات، ضمانت اجرا یا محدودیت حقوقی را ایجاد یا تغییر دهد. ۵. «No duplicate authority» اصل حاکم است: تکرار یا mirror فنی یک حکم مجاز است، اما منبع مالک و مرجع تغییر باید یکتا و قابل ردیابی بماند. ۶. REF یا GUIDE می‌توانند استاندارد را توضیح دهند اما منبع اختیار فنی یا حقوقی نیستند؛ POL یا REG فقط در حدود تفویض معتبر می‌توانند ورودی الزام‌آور STD باشند. ---
هر استاندارد رسمی، حسب ارتباط، باید علاوه بر اطلاعات موجود دست‌کم موارد زیر را ثبت کند: ۱. `legal_source` و نسخه منبع؛ ۲. `legal_owner`؛ ۳. `delegation_source` و `delegation_scope`، اگر وجود دارد؛ ۴. `change_authority`؛ ۵. `effective_from` و در صورت نیاز `effective_until`؛ ۶. حقوق یا منافع متأثر؛ ۷. implementation component؛ ۸. conformance tests؛ ۹. runtime evidence یا audit evidence؛ ۱۰. migration/rollback plan برای تغییر ناسازگار؛ ۱۱. وضعیت mirror بودن پارامتر یا rule، در صورتی که مالک آن سند دیگری باشد. زنجیره مطلوب برای قواعد اثرگذار بر حقوق چنین است: `Legal Source → Requirement/Procedure → Technical Standard → Implementation → Test → Runtime Evidence`. ---
۱. هر استاندارد فنی EarthCoop باید دارای شناسه یکتا، پایدار و قابل ارجاع باشد. ۲. قالب پایه شناسه استاندارد به شکل زیر است: `EC-XXXX` ۳. عدد چهاررقمی استاندارد، حوزه اصلی استاندارد را مشخص می‌کند. ۴. شناسه استاندارد پس از ثبت نباید حذف یا برای موضوع دیگری استفاده شود. ---
خانواده‌های اصلی استانداردهای فنی EarthCoop عبارت‌اند از: ۱. EC-1000: استانداردهای هویت و عضویت. ۲. EC-2000: استانداردهای گروه‌سازی و دسترسی. ۳. EC-3000: استانداردهای رأی‌گیری، انتخابات و نمایندگی. ۴. EC-4000: استانداردهای نجم‌بهار، بهار، صندوق‌ها و تراکنش‌ها. ۵. EC-5000: استانداردهای پروژه‌ها، بازار، شرکت‌ها و تعاونی‌ها. ۶. EC-6000: استانداردهای داده، حریم خصوصی و رضایت. ۷. EC-7000: استانداردهای API، رویدادها و یکپارچگی سامانه‌ها. ۸. EC-8000: استانداردهای قرارداد هوشمند، دفترکل و امضای دیجیتال. ۹. EC-9000: استانداردهای امنیت، ممیزی، لاگ، هوش مصنوعی و تداوم خدمت. ---
هر استاندارد باید یکی از وضعیت‌های زیر را داشته باشد: ۱. پیش‌نویس اولیه. ۲. پیش‌نویس عمومی. ۳. آزمایشی. ۴. لازم‌الاجرا. ۵. منسوخ‌شده. ۶. جایگزین‌شده. ۷. تعلیق‌شده. ۸. اضطراری. ---
۱. هر استاندارد باید دارای نسخه عددی باشد. ۲. تغییرات جزئی با افزایش نسخه فرعی و تغییرات ناسازگار با افزایش نسخه اصلی ثبت می‌شود. ۳. تغییر نسخه نباید موجب حذف سابقه تصمیمات، داده‌ها یا تعهدات قبلی شود. ۴. هر تغییر باید دارای یادداشت تغییر، دلیل، اثر، تاریخ اجرا و دوره گذار باشد. --- ---
۱. استاندارد EC-1001 قواعد فنی هویت دیجیتال اعضای EarthCoop را تعیین می‌کند. ۲. هر عضو کامل باید دارای شناسه یکتای عضویت باشد. ۳. شناسه عضویت باید به‌گونه‌ای طراحی شود که امکان اتصال امن به گروه‌ها، رأی‌گیری، نجم‌بهار، پروژه‌ها، شکایات و سوابق مشارکت را فراهم کند. ۴. شناسه عضویت نباید بدون ضرورت مشروع، داده‌های حساس یا قابل شناسایی عمومی را آشکار کند. ۵. سامانه باید امکان استفاده از شناسه‌های نمایشی یا مستعار را برای حفظ حریم خصوصی فراهم کند. ---
۱. ثبت‌نام اولیه باید شامل پذیرش قوانین بنیادین، ارائه ایمیل معتبر و تأیید ایمیل باشد. ۲. پس از ثبت‌نام اولیه، وضعیت کاربر باید «کاربر پایه» باشد. ۳. کاربر پایه فقط باید امکان تکمیل ثبت‌نام، مشاهده راهنما و دسترسی محدود به اطلاعات ضروری را داشته باشد. ۴. سامانه باید وضعیت ثبت‌نام، مرحله فعلی و گام‌های باقی‌مانده را روشن نمایش دهد. ---
۱. STD ساختار داده و state machine تکمیل عضویت را مطابق CO، LOC، EX و DG اجرا می‌کند و خود منبع تعیین سطح الزامی حکمرانی نیست. ۲. مدل فنی باید میان داده هویتی، داده صنفی/تخصصی، مسیر نشانی مکانی، جامعه پایه حکمرانی و اجتماعات خردتر اختیاری تمایز روشن داشته باشد. ۳. الزام تکمیل مکان باید در پایین‌ترین سطح حکمرانی معتبر همان محل خاتمه‌پذیر باشد؛ سطوح خیابان، کوچه، مجتمع، بلوک یا ساختمان فقط در صورت قانون یا انتخاب معتبر کاربر وارد فرآیند می‌شوند. ۴. حالت‌های شهر بدون منطقه/محله، منطقه بدون محله و روستای بدون محله باید بدون ایجاد سطح صوری پشتیبانی شوند. ۵. هر تغییر داده مؤثر بر گروه یا حق مشارکت باید منبع قاعده و اثر آن را برای عضو قابل توضیح نگه دارد. ---
۱. مدل فنی نباید عضویت، وضعیت مشارکت، مسئولیت و محدودیت را در یک enum ماهوی واحد ادغام کند. ۲. حداقل باید مفاهیم زیر از هم متمایز باشند: - `membership_state`؛ - `participation_state`؛ - `responsibility_roles`؛ - `restriction_state`. ۳. «فعال»، «ناظر» و «فعال موقت» وضعیت مشارکت‌اند؛ «مدیر» و «بازرس» نقش مسئولیتی‌اند؛ این عناوین به‌خودی‌خود نوع مستقل عضویت ایجاد نمی‌کنند. ۴. هر تغییر دارای اثر حقوقی باید Legal Basis، Actor/Authority، Timestamp، Scope و Appeal/Review Path داشته باشد. ---
۱. سامانه باید برای جلوگیری از حساب تکراری، جعل هویت و سوءاستفاده انتخاباتی یا مالی کنترل‌های فنی متناسب داشته باشد. ۲. کنترل‌های ضدتقلب نباید تبعیض‌آمیز، غیرقابل توضیح یا خارج از مسیر اعتراض باشند. ۳. تشخیص خودکار حساب مشکوک نباید به‌تنهایی موجب محرومیت قطعی شود، مگر در محدودیت موقت، مستند و قابل بازنگری. ---
۱. هر گروه باید شناسه، نوع، scope، منبع قانونی، وضعیت، اعضا و نقش‌های لازم را داشته باشد. ۲. `location_scope` و `governance_scope` باید قابل تفکیک باشند و صرف سطح مکانی، صلاحیت حکمرانی ایجاد نکند. ۳. سطح گروه نباید به فهرست سخت «محله تا جهان» وابسته باشد؛ topology معتبر LOC و registry مکانی منبع تعیین سطوح موجودند. ۴. اجتماع خردتر از جامعه پایه می‌تواند در صورت پیش‌بینی اختیاری باشد و نباید خودکار جای جامعه پایه حکمرانی را بگیرد. ---
۱. موتور گروه‌سازی قواعد معتبر LOC و EX را اجرا می‌کند و DG الزامات داده، امنیت و توضیح‌پذیری آن را اعمال می‌کند. ۲. سامانه باید دلیل، منبع rule و نسخه rule مؤثر بر هر عضویت یا وضعیت مشارکت را قابل ردیابی نگه دارد. ۳. گروه‌سازی خودکار نمی‌تواند rule ماهوی تازه‌ای برای عضویت، رأی یا صلاحیت ایجاد کند. ---
۱. سامانه باید وضعیت مشارکت را از منبع معتبر دریافت و enforce کند. ۲. فعال‌بودن عضو در جامعه پایه و ناظر بودن او در سطوح بالاتر باید بر اساس topology واقعی و قواعد LOC/EX تعیین شود، نه فرض ثابت «محله». ۳. access control باید نتیجه قواعد معتبر باشد؛ RBAC/ABAC خود منبع حق یا محرومیت نیست. ۴. هر تغییر وضعیت باید ثبت‌شده، قابل توضیح و قابل ممیزی باشد. ---
۱. Active Temporary / فعال موقت باید یک participation state مستقل از membership و responsibility role باشد. ۲. این وضعیت به‌خودی‌خود حق رأی انتخاباتی، حق انتخاب شدن یا احتساب در حدنصاب آغاز انتخابات ایجاد نمی‌کند. ۳. سامانه باید مدت یا شرط پایان، scope، authority، purpose و سابقه تغییر را ثبت کند. ۴. پس از پایان، بازگشت به وضعیت معتبر قبلی باید بدون از بین‌بردن audit history انجام شود. ---
۱. عضو ناظر باید بتواند نظر یا پیشنهاد مربوط به سطح بالاتر را در گروه فعال خود ثبت کند. ۲. پیشنهاد باید دارای ارجاع به سطح، گروه، موضوع، متن، تاریخ، پیشنهاددهنده، شاخص حمایت و وضعیت رسیدگی باشد. ۳. اگر پیشنهاد به حدنصاب حمایت برسد، سامانه باید مسیر ارجاع آن به شبکه مدیران و مجمع سطح مربوط را ثبت کند. ۴. وضعیت پیشنهاد باید شامل ثبت‌شده، در حال جذب حمایت، ارجاع‌شده، در حال بررسی، پذیرفته‌شده، ردشده، اجراشده یا بایگانی‌شده باشد. ---
۱. STD موتور انتخابات را مطابق مدل ماهوی معتبر CO و EX پیاده‌سازی می‌کند. ۲. دائمی یا بدون نامزد بودن، تعداد مدیران و بازرسان، حدنصاب، دوره پژوهش، توقف و سایر قواعد ماهوی از منبع مالک دریافت می‌شوند؛ STD مالک مستقل آنها نیست. ۳. سامانه باید ثبت، اصلاح، بازپس‌گیری، شمارش، پذیرش مسئولیت، جایگزینی و محاسبه نتیجه را قابل ممیزی اجرا کند. ۴. Rule Set و Parameter Set مؤثر بر هر نتیجه باید versioned و همراه نتیجه قابل بازیابی باشد. ---
۱. پارامتر انتخاباتی باید از Canonical Parameter Registry یا منبع رسمی هم‌ارز دریافت شود. ۲. حداقل metadata شامل Parameter Key، Current Value، Legal Source، Legal Owner، Change Authority، Scope، Version و Effective Date است. ۳. UI یا Admin Panel فقط interface اعمال اختیار است و وجود کنترل تغییر به معنای اختیار حقوقی نیست. ۴. snapshot پارامترهای مؤثر بر هر election result باید برای audit محفوظ بماند. ---
۱. scheduler فقط دوره و شرایط معتبر توقف را اجرا می‌کند و مقدار مدت را مستقلاً تعیین نمی‌کند. ۲. هر توقف باید Rule/Parameter Version، Effective Time، Scope و Event ID قابل ممیزی داشته باشد. ---
۱. سامانه فقط grounds ماهوی توقف را که منبع معتبر انتخاباتی یا قضایی تعیین کرده است اجرا می‌کند. ۲. STD خودِ «افت اعتماد»، «تعارض منافع»، «تخلف» یا سایر grounds را بدون Legal Source به علت حقوقی توقف تبدیل نمی‌کند. ۳. توقف باید دلیل، authority، scope، آغاز، پایان یا review condition و مسیر اعتراض داشته باشد. ---
۱. سامانه متن قرارداد، مهلت پذیرش، آثار رد/عدم پاسخ و ترتیب جایگزینی را از EX و منابع معتبر دریافت می‌کند. ۲. STD مسئول identity binding، version integrity، timestamp، proof of acceptance و state transition است. ۳. اعتبار ماهوی قرارداد از پیاده‌سازی فنی یا امضای دیجیتال به‌تنهایی ناشی نمی‌شود. ---
۱. سامانه باید قاعده معتبر «یک مسئولیت فعال» و قواعد جایگزینی سطح پایین‌تر را مطابق EX/CO enforce کند. ۲. پذیرش مسئولیت بالاتر نباید بدون منبع معتبر وضعیت حقوقی جدیدی مانند «مدیر معلق» در مسئولیت قبلی ایجاد کند. ۳. انتقال، جانشینی یا خاتمه مسئولیت باید Event و Audit Trail مستقل داشته باشد. ---
۱. STD فقط گزینه‌های visibility مجاز در منبع انتخاباتی/داده‌ای معتبر را اجرا می‌کند. ۲. متن بازخورد، هویت نویسنده و audience باید به‌صورت جداگانه کنترل دسترسی شوند. ۳. سامانه حق ایجاد audience جدید، افشای هویت یا کاهش محرمانگی خارج از مبنای معتبر را ندارد. ۴. moderation یا anti-abuse controls نباید به حذف خودکار حق اعتراض یا نقد مشروع تبدیل شوند. ---
۱. مقدار ۱۰٬۰۰۰ Bahar در STD mirror مقدار قانونی جاری ECON است و STD منبع مالک آن نیست. ۲. Configuration باید Legal Source، Legal Version، Parameter Class، Change Authority و Effective Date را ثبت کند. ۳. mismatch میان mirror فنی و مقدار قانونی باید به‌عنوان conformance failure متوقف‌کننده عملیات مرتبط ثبت شود، نه اینکه یکی خودکار دیگری را overwrite کند. ---
۱. مقدار ۱۲ Bahar و نسبت‌های جاری، در صورت تکرار در STD، mirror نسخه‌دار ECON/Policy معتبرند و اختیار مستقل ایجاد نمی‌کنند. ۲. هر تغییر باید از منبع مالک آمده و سپس به Configuration منتقل شود. ۳. اجرای سامانه باید مقدار و Policy Version مؤثر بر هر پرداخت را همراه Event ثبت کند. ---
۱. طبقه‌بندی داده باید DG و استانداردهای وابسته را اجرا کند. ۲. طبقه‌بندی نادرست، ابتدا `technical_non_conformance` یا در صورت ریسک `security_incident` ثبت می‌شود. ۳. چنین رخدادی فقط در صورت انطباق با عناصر یک قاعده حقوقی معتبر، `legal_violation` محسوب می‌شود؛ و عنوان `adjudicated_violation` فقط پس از تصمیم مرجع صالح قابل استفاده است. ۴. سیستم داده باید این وضعیت‌ها را از هم متمایز نگه دارد. ---
۱. حقوق و مبانی پردازش از DG می‌آیند؛ STD capture، proof، versioning، withdrawal workflow و enforcement فنی آنها را تعریف می‌کند. ۲. هر processing purpose باید حداقل purpose، legal basis، data categories، retention rule و access policy داشته باشد. ---
۱. سامانه باید endpoint یا workflow لازم برای اعمال حقوق داده مقرر در DG را فراهم کند. ۲. STD حق داده تازه‌ای ایجاد یا حق موجود را حذف نمی‌کند؛ در نبود قابلیت خودکار، مسیر انسانی معتبر باید باقی بماند. ---
۱. هر فرم، API یا سامانه فقط باید داده لازم برای هدف مشخص را درخواست کند. ۲. برای هر فیلد مهم باید هدف، ضرورت، سطح حساسیت، مدت نگهداری و مبنای پردازش مشخص باشد. ۳. گردآوری داده بی‌هدف، اضافی یا پنهان ممنوع است. ---
۱. استفاده پژوهشی، آماری یا عمومی از داده‌های اعضا باید تا حد امکان با ناشناس‌سازی یا تجمیع انجام شود. ۲. ناشناس‌سازی باید به‌گونه‌ای باشد که بازشناسایی عضو با روش‌های معمول ممکن نباشد. ۳. داده ناشناس‌شده نباید با داده‌های دیگر برای بازشناسایی غیرمجاز ترکیب شود. ---
۱. رویدادهای مهم سامانه باید ثبت، شناسه‌گذاری و قابل رهگیری باشند. ۲. رویدادهای مهم شامل ثبت‌نام، تکمیل عضویت، تغییر گروه، رأی، تغییر رأی، انتخاب، پذیرش مسئولیت، تراکنش، فعال‌سازی، پروژه، شکایت، تصمیم قضایی، تغییر پارامتر و رخداد امنیتی است. ۳. هر رویداد باید دارای زمان، منبع، موضوع، نوع، نتیجه، شناسه کاربر یا سامانه مجاز، و رکورد حسابرسی باشد. ---
۱. پیام خطای سامانه باید تا حد امکان روشن، غیرگمراه‌کننده و قابل اقدام باشد. ۲. خطاهای امنیتی نباید اطلاعات حساس فنی را افشا کنند. ۳. خطاهای مؤثر بر حق، رأی، داده، پول یا عضویت باید قابل گزارش و پیگیری باشند. ۴. سامانه باید میان خطای کاربر، خطای سامانه، محدودیت قانونی و رخداد امنیتی تفاوت بگذارد. ---
۱. سامانه‌های عضویت، گروه‌سازی، رأی‌گیری، نجم‌بهار، پروژه‌ها، بازار، نجم‌هدا، شکایات، پشتیبانی و مخزن اسناد باید با قواعد روشن یکپارچه شوند. ۲. یکپارچگی نباید به تمرکز خطرناک داده یا وابستگی غیرضروری منجر شود. ۳. تبادل داده میان سامانه‌ها باید هدف‌مند، حداقلی، امن و قابل ممیزی باشد. ---
۱. STD ویژگی‌های فنی انتساب، تمامیت، زمان، اثبات پذیرش و نگهداری امضا را تعیین می‌کند. ۲. انطباق فنی امضا به‌تنهایی به معنای اعتبار ماهوی قرارداد یا کفایت آن در هر قلمرو بیرونی نیست. ۳. برای اثر حقوقی، منبع مربوط باید نوع پذیرش یا امضای قابل قبول را تعیین کند و الزامات قانون قابل اعمال قلمرو رعایت شود. ---
۱. Standard Compliance یا اجرای صحیح کد، اعتبار ماهوی قرارداد زیربنایی را اثبات نمی‌کند. ۲. قرارداد هوشمند باید Legal/Contract Reference، Version، Parties/Authority، Stop/Review Path و Audit Trail داشته باشد. ۳. اجرای خودکار خارج از دامنه اختیار یا ناسازگار با حکم معتبر باید قابل توقف و اصلاح از مسیر قانونی باشد. ---
۱. قرارداد هوشمند مهم باید دارای سازوکار توقف اضطراری باشد. ۲. توقف اضطراری فقط در موارد خطر جدی، خطای فنی، سوءاستفاده، حمله، فساد یا تعارض آشکار با قانون مجاز است. ۳. هر توقف باید ثبت‌شده، مستند، زمان‌مند، قابل بازبینی و دارای گزارش باشد. ---
۱. همه سامانه‌های بنیادین EarthCoop باید دارای کنترل‌های امنیتی متناسب با حساسیت خود باشند. ۲. کنترل‌ها شامل احراز هویت، مجوزدهی، رمزنگاری، ثبت لاگ، پایش، پشتیبان‌گیری، مدیریت آسیب‌پذیری، مدیریت رخداد و آزمون امنیتی است. ۳. امنیت نباید بهانه حذف شفافیت، نظارت عمومی یا حق اعتراض شود. ---
۱. دسترسی به سامانه‌ها و داده‌ها باید نقش‌محور، حداقلی، زمان‌مند، قابل لغو و قابل حسابرسی باشد. ۲. نقش‌های حساس شامل مدیر سامانه، توسعه‌دهنده زیرساخت، حسابرس، مدیر مالی، بازرس، داور، مدیر گروه، متخصص داده و پشتیبان هستند. ۳. دسترسی‌های حساس باید دارای تأیید چندمرحله‌ای و ثبت کامل باشند. ---
۱. حذف، جعل یا دستکاری غیرمجاز لاگ باید به‌عنوان رخداد امنیتی شدید و عدم انطباق فنی ثبت شود. ۲. طبقه‌بندی نهایی آن به‌عنوان تخلف حقوقی تابع DG/JUD و سایر منابع صلاحیت‌دار است. ۳. خود استاندارد با برچسب «تخلف بنیادین فنی» مجازات تازه ایجاد نمی‌کند. ---
۱. سامانه‌های بنیادین EarthCoop باید مشمول ممیزی مستقل فنی، امنیتی، حقوقی و اخلاقی شوند. ۲. ممیزی باید شامل هویت، رأی‌گیری، نجم‌بهار، قراردادهای هوشمند، داده، API، هوش مصنوعی و زیرساخت باشد. ۳. نتایج ممیزی باید در سطح مناسب منتشر یا در اختیار نهادهای نظارتی قرار گیرد. ۴. پنهان‌سازی آسیب‌پذیری مهم یا نتیجه ممیزی اثرگذار بر اعضا ممنوع است. ---
۱. هر رخداد امنیتی باید دارای شناسه، زمان، نوع، شدت، سامانه متأثر، داده متأثر، اقدامات فوری، مسئول رسیدگی و گزارش نهایی باشد. ۲. رخدادهای مؤثر بر حقوق، داده، رأی، پول یا عضویت اعضا باید در زمان مناسب به ذی‌نفعان اطلاع داده شوند، مگر اطلاع‌رسانی فوری موجب آسیب شدیدتر شود. ۳. پس از رخداد، گزارش علت، اثر، اصلاح و پیشگیری باید تهیه شود. ---
۱. داده‌ها و سامانه‌های بنیادین باید دارای سیاست پشتیبان‌گیری، بازیابی، آزمون بازیابی و تداوم خدمت باشند. ۲. از دست رفتن داده‌های رأی، مالی، هویتی، قضایی یا عضویتی باید به‌عنوان رخداد مهم بررسی شود. ۳. پشتیبان‌ها باید امن، رمزنگاری‌شده و دارای کنترل دسترسی باشند. --- ---
۱. نقش‌ها و محدودیت‌های ماهوی نجم‌هدا از DG، ETH و سایر قوانین مربوط می‌آیند؛ STD آنها را به guardrail، human-approval gate، provenance، model/version record، explanation و escalation قابل آزمون تبدیل می‌کند. ۲. هر تصمیم یا پیشنهاد Hoda که ممکن است اثر الزام‌آور بر حق شخص پیدا کند باید Authority Source و Human/Institutional Approval Path مقرر را ثبت کند. ۳. نبود قابلیت فنی برای escalation نباید مجوز تصمیم خودکار الزام‌آور ایجاد کند. ---
۱. هر تصمیم ماشینی یا نیمه‌ماشینی مؤثر بر حقوق اعضا باید دارای توضیح، مبنا، داده‌های اصلی، مدل یا قاعده، نتیجه و مسیر اعتراض باشد. ۲. هیچ تصمیم ماشینی غیرقابل توضیح نباید به‌تنهایی موجب محرومیت مهم عضویتی، مالی، انتخاباتی، قضایی یا اعتباری شود. ۳. سامانه باید امکان ارجاع به بازنگری انسانی را فراهم کند. ---
۱. سامانه‌های هوش مصنوعی مؤثر بر حقوق، داده، رأی، پول، اعتبار، پروژه یا مشارکت باید ممیزی دوره‌ای شوند. ۲. ممیزی باید خطا، تبعیض، جانبداری، توهم، دستکاری رفتاری، نقض حریم خصوصی و آثار نامطلوب را بررسی کند. ۳. نتیجه ممیزی باید در سطح مناسب ثبت و گزارش شود. ---
۱. ممنوعیت حقوقی یا اخلاقی manipulation از DG/ETH و قوانین مربوط می‌آید؛ STD معیارهای فنی قابل آزمون آن را تعریف می‌کند. ۲. استانداردهای تفصیلی باید حسب مورد preselection، asymmetry، hidden cancellation friction، misleading prominence و سایر dark patternهای قابل سنجش را پوشش دهند. ۳. `technical_non_conformance` رابط به‌تنهایی مجازات حقوقی ایجاد نمی‌کند. ---
۱. سامانه‌های EarthCoop باید تا حد امکان برای افراد دارای توانایی‌ها، زبان‌ها، سوادها، ابزارها و شرایط متفاوت قابل استفاده باشند. ۲. طراحی باید محدودیت‌های دیداری، شنیداری، حرکتی، شناختی، زبانی، مالی و فنی را در نظر بگیرد. ۳. هیچ عضو نباید به‌دلیل ناتوانی فنی یا دسترسی محدود، به‌طور ناعادلانه از حق بنیادین مشارکت محروم شود. ---
۱. اطلاعات مهم حقوقی، مالی، انتخاباتی، داده‌ای و عضویتی باید تا حد امکان به زبان روشن و قابل فهم ارائه شود. ۲. متن‌های پیچیده باید دارای خلاصه ساده، توضیح، مثال یا راهنمای کاربر باشند. ۳. زبان ساده نباید موجب تحریف یا حذف مفاد حقوقی مهم شود. ---
۱. رابط کاربری باید انتخاب‌های مهم را روشن، بی‌طرفانه و قابل فهم نشان دهد. ۲. گزینه‌های مرتبط با رأی، پول، داده، عضویت، رضایت، شکایت و خروج نباید پنهان یا فریبنده طراحی شوند. ۳. رابط کاربری نباید کاربر را با فشار روانی، اعلان‌های دستکاری‌گر یا مسیرهای پیچیده به تصمیم ناخواسته سوق دهد. ---
۱. هر سامانه بنیادین باید دارای مستندات فنی، حقوقی، امنیتی، داده‌ای و عملیاتی باشد. ۲. مستندات باید شامل معماری، مدل داده، APIها، وابستگی‌ها، نقش‌ها، جریان‌های کاری، خطاها، لاگ‌ها، آزمون‌ها، ممیزی و محدودیت‌ها باشد. ۳. مستندات باید نسخه‌بندی‌شده و برای افراد مجاز قابل دسترس باشد. ---
۱. زیرساخت‌های بنیادین EarthCoop باید تا حد امکان متن‌باز، قابل بررسی و قابل ممیزی باشند. ۲. استثناهای امنیتی باید محدود، مستند، موقت و قابل بازنگری باشند. ۳. متن‌باز بودن نباید به افشای داده حساس، کلیدهای امنیتی یا آسیب‌پذیری‌های فعال منجر شود. ---
۱. کدهای مؤثر بر هویت، رأی‌گیری، نجم‌بهار، قراردادهای هوشمند، داده، امنیت و دادرسی باید پیش از اجرا بازبینی شوند. ۲. بازبینی باید توسط افراد واجد صلاحیت و فاقد تعارض منافع مؤثر انجام شود. ۳. تغییرات اضطراری باید پس از اجرا نیز مشمول بازبینی و گزارش شوند. ---
۱. هر قابلیت بنیادین باید پیش از production آزمون‌های لازم قانون، امنیت، داده، عملکرد و حقوق اعضا را طی کند. ۲. برای قواعد اثرگذار بر حقوق باید Compliance Matrix قابل ممیزی وجود داشته باشد که حداقل Requirement/Rule ID، Legal Source، Standard، Implementation Component، Test و Evidence را متصل کند. ۳. نبود آزمون ضروری باید deployment را متوقف کند مگر در آزمایش محدود، کنترل‌شده، دارای مبنای معتبر و rollback روشن. ۴. عبور از test فنی به‌تنهایی اثبات انطباق حقوقی کامل نیست اگر Legal Source یا Rule Version اشتباه باشد. ---
۱. سامانه شکایات باید امکان ثبت شکایت، اعتراض، گزارش تخلف و درخواست رسیدگی را فراهم کند. ۲. هر شکایت باید دارای شناسه، موضوع، طرف‌های مرتبط، شرح، مستندات، سطح فوریت، زمان ثبت، وضعیت و مسیر پیگیری باشد. ۳. شاکی باید رسید ثبت و وضعیت پرونده را مشاهده کند. ---
۱. هر پرونده قضایی، داوری، میانجی‌گری یا رسیدگی باید دارای شناسه یکتا و ساختار داده مشخص باشد. ۲. پرونده باید شامل طرفین، موضوع، ادله، لاگ‌ها، تصمیمات، مهلت‌ها، دفاع‌ها، رأی، ضمانت اجرا و مسیر اعتراض باشد. ۳. دسترسی به پرونده باید نقش‌محور، امن و ثبت‌شده باشد. ---
۱. اجرای حکم فقط بر اساس Judgment/Order معتبر و در دقیق‌ترین دامنه مقرر انجام می‌شود. ۲. سامانه باید Authority، Order ID، Scope، Effective Time، Appeal/Stay State و Execution Events را ثبت کند. ۳. کد حق ندارد اثر حکم را توسعه دهد یا بیش از آنچه مرجع صالح مقرر کرده محدودیت اعمال کند. ---
۱. مرجع استاندارد فنی مالک قانون موضوعی نیست؛ وظیفه آن تدوین specification فنی در حدود منابع معتبر است. ۲. در استاندارد هر حوزه، علاوه بر متخصصان فنی، نمایندگی مناسب متخصصان حوزه ماهوی و حقوقی منبع باید حضور داشته باشد. ۳. مرجع استاندارد نباید از طریق specification، تصمیم سیاستی یا حقوقی‌ای را که نیازمند منبع دیگری است اتخاذ کند. ---
۱. پیشنهاد استاندارد باید علاوه بر مسئله و طراحی فنی، Legal Source، Delegation Scope و اثر بر حقوق موجود را مشخص کند. ۲. اگر اجرای پیشنهاد نیازمند حق، تکلیف، ممنوعیت یا پارامتر ماهوی جدیدی باشد که منبع معتبر ندارد، فرآیند استاندارد باید آن بخش را متوقف و به اصلاح قانون/Policy/REG صلاحیت‌دار ارجاع دهد. ۳. «اثر حقوقی» در proposal به معنای تحلیل اثر بر حقوق موجود است، نه اختیار STD برای ایجاد اثر حقوقی تازه. ---
۱. اصلاح استاندارد باید versioned، مستند، قابل بررسی و دارای migration/rollback plan متناسب باشد. ۲. تغییر اضطراری امنیتی فقط در حداقل دامنه و کوتاه‌ترین زمان لازم مجاز است و باید مشمول retrospective review شود. ۳. تغییر اضطراری نمی‌تواند محدودیت دائمی بر حق ایجاد کند مگر آنکه منبع حقوقی صالح آن را تصویب کند. ---
۱. میان استانداردهای مبتنی بر یک منبع و یک قلمرو، قاعده خاص‌تر بر عام‌تر مقدم است، مگر منبع معتبر خلاف آن را مقرر کند. ۲. نسخه جدیدتر استاندارد فقط در همان دامنه و lineage خود مقدم است و صرف جدیدتر بودن برای کنارزدن استاندارد حوزه دیگر صلاحیت ایجاد نمی‌کند. ۳. اگر تعارض standards در واقع ناشی از تعارض قوانین یا delegationها باشد، مرجع فنی حق حل ماهوی تعارض قوانین را ندارد و باید موضوع را به مرجع صلاحیت‌دار ارجاع دهد. ۴. در همه موارد، قانون و منبع معتبر حاکم‌اند. ---
۱. اسناد EC-XXXX باید «استاندارد فنی» باشند، نه آیین‌نامه ماهوی انتخابات، اقتصاد، داده یا دادرسی. ۲. عنوان و دامنه استاندارد باید موضوع فنی را نشان دهد؛ برای نمونه «استاندارد ثبت، محرمانگی و ممیزی رأی» به‌جای «آیین‌نامه انتخابات» و «استاندارد فنی Ledger نجم‌بهار» به‌جای «آیین‌نامه نجم‌بهار». ۳. REG و POL از مسیر منبع قانونی خود اختیار می‌گیرند و زیرمجموعه STD محسوب نمی‌شوند؛ STD می‌تواند آنها را در صورت اعتبار به‌عنوان normative input اجرا کند. ۴. REF و GUIDE اسناد توضیحی‌اند و به‌تنهایی normative input الزام‌آور محسوب نمی‌شوند. ۵. شناسه‌های EC باید از registry یکتای استانداردهای فنی تخصیص یابند؛ هیچ قانون موضوعی یا استاندارد دیگر نباید namespace موازی و متعارض ایجاد کند. ---
۱. STD Core و هر EC-XXXX باید version history و status مستقل و قابل ردیابی داشته باشند. ۲. تغییر یک استاندارد تفصیلی نباید لزوماً باعث تغییر محتوایی همه استانداردهای دیگر شود. ۳. registry فنی باید parent legal source، delegation، current version، effective status و supersession هر استاندارد را ثبت کند. ۴. ثبت فنی در registry به‌خودی‌خود قانون یا Policy را نافذ نمی‌کند. ---
۱. این اصلاحیه در صورت ثبت و تصویب رسمی، STD را به نسخه 1.0 ارتقا می‌دهد. ۲. تا پیش از ثبت و تصویب، این فایل پیش‌نویس کاری و فاقد اثر مستقل است. ۳. STD 0.1 منبع مبنای محافظت‌شده است و نباید برای همسان‌سازی ظاهری ویرایش شود؛ تغییر حقوقی از مسیر اصلاحیه نسخه‌دار انجام می‌شود. ۴. پیش از ارتقای public baseline یا استفاده از عنوان «متن کامل STD 1.0»، Consolidated Edition باید از STD 0.1 + STD 0.2 + STD 1.0 تولید شود، توالی و یکتایی شناسه مواد حفظ گردد و provenance و amendment history قابل بازیابی باشد. ۵. Consolidated Edition متن خوانش یکپارچه نسخه جاری است و تاریخ حقوقی amendmentها را حذف یا بازنویسی نمی‌کند. ۶. registries و manifestها فقط طبق مدل رسمی registry و پس از تصمیم ثبت/انتشار مربوط به‌روزرسانی می‌شوند و به‌تنهایی موجب نفاذ حقوقی نمی‌شوند.