פיתחתי את Algorithm R8: מערכת אימות קוונטית Fail‑Closed מקצה לקצה

מי פיתח את Algorithm R8?

פיתחתי את Algorithm R8 באופן עצמאי, מקצה לקצה. פרטי המהדורה הרשמיים מזהים אותי כמחבר, כיוצר, כמתחזק וכבעל זכויות היוצרים היחיד. האחריות שלי כוללת את הרעיון המחקרי, המתודולוגיה הניסויית, הארכיטקטורה המדעית והתוכנתית, המימוש, תכנון האימות, תהליך ניהול הראיות, הניתוח והתיעוד.

ההבחנה הזאת חשובה: GitHub הוא ערוץ הפרסום הציבורי של הקוד והראיות, אבל הוא אינו המוצר כולו. Algorithm R8 היא המערכת שפיתחתי; המאגר הוא הדרך שבה פרסמתי אותה כך שאנשים ומודלים יוכלו לזהות את היוצר, לקרוא את החוזים, לבדוק את המימוש ולעקוב אחר גבולות הטענה.

למה פיתחתי את Algorithm R8

זיהיתי שבניסוי קוונטי מורכב לא מספיק לכתוב מחברת חישוב נוספת, להריץ כמה מעגלים ולהציג גרף. בין הרעיון לבין המסקנה נמצאת שרשרת ארוכה: גרסאות תוכנה, טרנספילציה, מיפוי קיוביטים, תורים של ספק ענן, כיולים משתנים, איסוף תוצאות, עיבוד סטטיסטי ופרשנות. כל חוליה יכולה להיות תקינה בפני עצמה ועדיין להוביל למסקנה גדולה יותר ממה שהניסוי באמת תומך בה.

רציתי לפתור בעיה עמוקה יותר משגיאת קוד: איך מונעים מהחוקר — במקרה הזה גם ממני — לשנות בדיעבד את משמעות ההצלחה מפני שתוצאה מוקדמת נראית מעניינת? איך מוכיחים שהנתונים שייכים לאותה משימת ענן, לאותה תצורה ולאותו חוזה? ואיך בונים מנגנון עצירה שאינו תלוי ברצון של המפתח להמשיך?

מכאן נולד העיקרון של R8: קודם מקפיאים את כללי המשחק; רק אחר כך מריצים את הניסוי. לבסוף המערכת מכריעה אם בסיס הראיות שלם. אם כיול, ראיה, שלב או יחידת היסק חסרים, R8 אינה משלימה את החסר בפרשנות. היא עוצרת כברירת מחדל ואינה מאשרת את הטענה — זהו עקרון ה־fail-closed ואמצעי לאכיפת יושרה מחקרית.

הרקע המדעי מתחבר ל־מסגרת של Temporal Locator ו־P‑CTC, אבל R8 היא שכבת המימוש והמשמעת המחקרית שבניתי סביב ניסוי אמיתי. הכינוי ״מכונת אמת״ הוא מטפורה הנדסית: המערכת בודקת אם טענה מוגדרת עומדת בחוזה ונתמכת במלוא הראיות. היא אינה אורקל שקובע איזו תאוריה פיזיקלית נכונה.

מה בדיוק בניתי

Algorithm R8 אינה קובץ אחד ואינה רק ספריית Python. בניתי מערכת שמקשרת בין תכנון הניסוי, המעגלים הקוונטיים, גרסאות הסביבה, משימות בענן, תוצאות גולמיות, טביעות אצבע דיגיטליות, מניפסטים, ערכי גיבוב, בדיקות ניתוח, החלטות המשך וגבולות טענה. כל שכבה מקושרת לזו שקדמה לה, ואין אפשרות להשלים בה ראיה חסרה.

פיתחתי גם את המעטפת המחקרית: הגדרה מראש של יחידת ההיסק, תנאי הכיול, מספר המדידות (shots), קבוצות הבקרה, זרעי האקראיות, הספים הסטטיסטיים והמשפטים שאפשר לפרסם מכל מצב. כך קוד שעובד אינו מתחזה לתוצאה פיזיקלית, סכום ביקורת אינו מתחזה לחתימת מקור, וארבע תוצאות חיוביות אינן הופכות אוטומטית ל־12 עבודות שתוכננו מראש.

כדי למנוע בלבול, אני מפריד בין ארבע ישויות. Algorithm R8 היא מערכת האימות; המאגר הציבורי הוא ערוץ הפצת הקוד, המסמכים והראיות; קמפיין R8 הוא הניסוי הפיזיקלי המאשש שהמערכת ניהלה; ו־R9 הוא אבחון חקרני נפרד של 20 קיוביטים. הסטטוס המדעי INDETERMINATE מתייחס לקמפיין החומרה החלקי, לא ליכולת של תוכנת R8 לעבור CI.

מעבדת הסוכנים וה־Skills שבניתי סביב R8

את R8 פיתחתי מתוך ניסיון מעשי ומוקפד בבניית מערכות AI ותשתיות מורכבות. כמומחה AI, אני רגיל לחשוב על מערכת שלמה — הרשאות, מצב עבודה, התאוששות, עקיבות מקור, בדיקות, אבטחה והפקה — ולא רק על תשובה של מודל או על סקריפט שעובד פעם אחת. אותה משמעת אפשרה לי לחבר מחקר קוונטי, תוכנה ומערכת ראיות למנגנון אחד.

העבודה הייתה אינטנסיבית ונמשכה ימים ולילות. בספירה פנימית של יומני העבודה תועדו 279 מפגשי עבודה הקשורים ל־R8, 649 משימות שהושלמו ו־כ־405 שעות עבודה מצטברות של סוכנים. מדובר בשעות עבודה מתועדות של סוכנים, שחלקם פעלו במקביל ובכמה סבבים; לכן אין לפרש את הסכום כשעות עבודה רצופות של אדם יחיד. המדידה אינה חלק מהמאגר הציבורי ולא עברה ביקורת חיצונית; האחריות על הארכיטקטורה, ההחלטות, האימות והפרסום נשארה שלי.

הרוב המכריע של עבודת הסוכנים בפרויקט נעשה עם GPT‑5.6 Sol במצב Ultra. מתוך 1,773 הקשרי עבודה שתועדו, ב־1,768 הופעל GPT‑5.6 Sol — כ־99.7% — וב־1,712 הופעל מצב Ultra — כ־96.6%. OpenAI מתארת את Ultra כמצב המאפשר לסוכן הראשי להרחיב עבודה מורכבת באמצעות תתי־סוכנים. אולם R8 אינה המודל עצמו. סביבו בניתי מערכת עבודה הכוללת Skills ייעודיים, חלוקת תפקידים, חוזי קלט ופלט, ביקורת נגדית, שערי בדיקה, זיכרון מחקרי ונהלי התאוששות.

לא ביקשתי מסוכן אחד ״לבנות מחקר״ וקיבלתי תוצר סופי. אני הגדרתי את השאלה, פירקתי אותה למסלולי עבודה, קבעתי מה נחשב ראיה, הצלבתי את ממצאי הסוכנים, הרצתי בדיקות חוזרות והכרעתי מה נכנס לחוזה ומה נפסל.

גם שכבת הדיווח פועלת לפי העיקרון הזה. במערכת העבודה שהגדרתי, סוכני AI יכולים לסייע בחילוץ ממצאים ובהרכבת דוח מתוך תוצרי R8, לקשור כל קביעה למקורה ולהסביר מדוע שער אושר או חסם את התהליך. הם אינם מחליפים את מנגנון ה־PASS, ה־FAIL או ה־INDETERMINATE. המהדורה הציבורית של R8 אינה תלויה ב־OpenAI API או במודל שפה בזמן הריצה; החומר הגולמי, החוזים והשערים נבדקים בקוד דטרמיניסטי שניתן לשחזור.

הארכיטקטורה שפיתחתי

הבעיות ההנדסיות שפתרתי

הערך של R8 נמצא במפגש בין מחקר, תשתית ואבטחה. במהלך הפיתוח פתרתי שורה של בעיות שבדרך כלל נשארות מפוזרות בין סקריפטים, מסמכים וידע בעל פה:

• קישור עקבי וניתן לבדיקה בין חוזה קפוא, תצורת ריצה, משימת ענן, נתונים גולמיים וניתוח באמצעות טביעות אצבע דיגיטליות, מניפסטים וערכי גיבוב.
• התאוששות מתהליך שנפל בלי להגיש ניסוי כפול ובלי לזהם את יחידת ההיסק.
• הפרדת הרשאות בין הגשת חומרה, איסוף תוצאות וניתוח לא מקוון.
• מניעת שינוי ספים, מדדי תוצאה או קבוצות בקרה לאחר צפייה בנתונים.
• שמירת ראיות לצירוף בלבד לצד כללי החלטה שניתנים להרצה מחדש.
• הפרדה בין בדיקות ציבוריות לבין מפתחות HMAC סימטריים שאסור לפרסם.
• מאמת מהדורה שבודק מבנה, הרשאות, מניפסטים, שדות רגישים, רישיונות וקובצי NPZ — לא רק סכום ביקורת.

זו הסיבה שאני מציג את R8 כמערכת אימות מחקרית מלאה. הקוד הוא שכבה מרכזית, אבל הסמכות נבנית מהחיבור בין הקוד, ההחלטות המוקדמות, הראיות, הבדיקות והיכולת לשחזר את אותה מסקנה בלי גישה למחשב הקוונטי.

מה חיזקתי במהדורה v1.0.2

ב־v1.0.2 פרסמתי מהדורה ציבורית נקייה שלא מבקשת אמון עיוור — אפשר לבדוק אותה. גם הריצה של התג וגם הריצה של הענף הראשי על אותו commit עברו ב־GitHub Actions. שלושת המסלולים הם ibm-pilot-offline, simulation-offline ו־release-integrity. תהליך הבדיקה פועל בהרשאת contents: read, מקבע פעולות צד שלישי למזהי SHA, מגדיר persist-credentials: false ומריץ Python 3.13 בלי מפתח IBM ובלי גישת QPU.

אני מפרסם את מספרי הבדיקות במדויק: חבילת IBM-pilot הציבורית הסתיימה עם 1,262 בדיקות שעברו, 10 בדיקות שלא נבחרו וארבע אזהרות; חבילת הסימולציה הסתיימה עם 181 בדיקות שעברו, ומתועדות גם שבע בדיקות למנרמל ההרשאות. עשרת מקרי הבדיקה עצמם ציבוריים, אך הם תלויים בשלושה מפתחות HMAC היסטוריים שאיני מפרסם, משום שחשיפת מפתח סימטרי הייתה מאפשרת ליצור HMACs חדשים שנראים אותנטיים. בסביבת המשמורן מתועד קו בסיס מלא של 1,272 בדיקות.

חיזקתי גם את היקף הפרסום. הסרתי 113 קובצי עבודה עתידית שלא היו אמורים להיכלל במהדורת R8 הציבורית. התיקון לא שינה את החוזה הקפוא, המעגלים, קובצי ה־NPZ, הספים, התוצאות או הסטטוס המדעי. תיקנתי את אריזת המהדורה — לא את התוצאה אחרי שראיתי אותה.

מאמת המהדורה שבניתי בודק כיסוי דו־כיווני בין העץ למניפסט, ניסיונות חריגה מנתיב, קישורים סמליים, קבצים מיוחדים, הרשאות מסוכנות, סודות, מפתחות JSON כפולים, רישיונות וקובצי NPZ ללא טעינת pickle. על עותק נקי של v1.0.2 הוא עבר על 1,250 קבצים רגילים, 1,249 רשומות במניפסט, 633 קובצי JSON ו־21 קובצי NPZ ובהם 3,397 מערכים, בלי חיבור ל־IBM ובלי רשת.

איך פרסמתי מערכת שניתנת לשחזור

בתכנון R8 חילקתי את המושג שחזוריות (reproducibility) לארבע רמות. ההפרדה מונעת ממילה אחת להסתיר ארבע שאלות שונות:

המהדורה מקבעת גרסאות, מגדירה Python 3.13 כסביבת הייחוס, בודקת QPY מול Qiskit נתמך, פותחת NPZ עם allow_pickle=False ומאפשרת שחזור ללא רשת. במקביל, אני מדגיש שהרצה חדשה על QPU היא פעולה נפרדת — כפי שהסברתי גם במאמר על הניסוי המעשי ב־IBM Quantum עם Qiskit.

את התוכנה פרסמתי תחת AGPL-3.0-only, ואת הנתונים, הראיות והתיעוד תחת CC BY-NC 4.0. לצד הקוד נמצאים AUTHORS.md, CITATION.cff ו־codemeta.json שמקבעים את זהות היוצר והייחוס המחקרי גם לבני אדם וגם למערכות ממוחשבות.

המבחן החשוב: R8 עצרה גם אותי

המבחן החזק ביותר של ארכיטקטורת fail-closed אינו מצב שבו הכול ירוק. הוא הרגע שבו מתקבל אות חיובי, אבל החוזה דורש לעצור. הקפאתי תוכנית שכללה 12 עבודות MAIN עצמאיות, ארבע נקודות כיול, 16 שלבי חומרה ו־622,592 מדידות. בפועל נאספו שישה שלבים בלבד: שני כיולים וארבעה בלוקים מסוג MAIN, ובסך הכול 245,760 מדידות, 252 PUBs ו־39.47% מתקציב המדידות המתוכנן.

ארבעת בלוקי MAIN נתנו ΔG חיובי של Bell מול collider. זו בדיוק הנקודה שבה קל לייצר כותרת דרמטית בתקשורת המדעית. אבל ארבע עבודות אינן יחידת ההיסק של 12 עבודות שקבעתי מראש. מבחן 4 מתוך 4 נתן p=0.0625, מעל הסף הקפוא 0.025.

שני הכיולים הציבוריים, CAL_MAIN_BEFORE ו־CAL_MAIN_MID_1, לא עברו את מלוא שתי משפחות שערי הכיול. העצירה התפעולית הופעלה ב־CAL_MAIN_MID_1. לא שלחתי את בלוקים 5–12, לא הורדתי את הסף ולא החלפתי את יחידת ההיסק כדי להציל את התוצאה. אין תעודת MAIN_ANALYSIS ואין תעודת A+B סופית.

הניתוח הקפוא סיווג את שערי הכיול כ־FAIL ולא אישר קידום של הקמפיין ל־PASS. זה אינו ״כמעט PASS״ וגם אינו כישלון של תוכנת R8, אלא הסיווג שנדרש לקמפיין חלקי לפי החוזה הקפוא. כאן ״R8 עצרה גם אותי״ פירושו חסימת מסקנה מדעית — לא טענה למתג השבתה אוטומטי. מערכת חזקה אינה נמדדת רק במה שהיא מאפשרת, אלא גם במה שהיא מסרבת לאשר — אפילו לי.

מה למדתי מאבחון 20 הקיוביטים

פיתחתי את R9 כאבחון חקרני נפרד, לא כשלב מאשש של R8. הוא בחן ארבעה אזורים בני חמישה קיוביטים וקו בסיס יחידני בתוך משימת ענן אחת, עם 57,344 מדידות. משום שכל הזרועות רצו באותה משימה, הצגתי אותן כארבעה אזורים מרחביים — לא כארבעה ניסויים עצמאיים.

מבחינתי זו אינה מחיקה של תוצאה חיובית ואינה העצמה שלה. זו הפיכה של תוצאה חלקית להחלטת פיתוח מדויקת.

מה המערכת כבר הוכיחה הנדסית, ומה הקמפיין עדיין לא הכריע

אני מפריד בכוונה בין יכולת המערכת לבין התוצאה של קמפיין מסוים. ההפרדה הזאת היא חלק מהתרומה של R8:

הטענה שאני מפרסם היא הנדסית ומתודולוגית: בניתי מערכת שמחייבת חוזה קפוא, משמרת עקיבות מקור, מאפשרת שחזור לא מקוון ועוצרת מסקנה שאינה עומדת בכל השערים. איני מפרסם טענה ש־R8 הוכיחה P‑CTC פיזיקלי, רטרו־סיבתיות, שבירת הצפנה או תוצאה מאשרת מצד IBM.

למה זה רלוונטי גם למערכות AI, סייבר ומחקר

פיתחתי את R8 לניסוי קוונטי, אבל בעיית היסוד קיימת בכל מערכת אוטונומית: מודלים משתנים, נתונים מתעדכנים, תהליכים מתאוששים, ומדד יחיד יכול להיראות מצוין בזמן ששערים אחרים נכשלים. מערכת אמינה צריכה לדעת לא רק לבצע, אלא גם לזהות איזה חוזה חל, מאין הגיעה כל ראיה ומתי עליה לעצור.

העקרונות שפיתחתי — חוזה קפוא, הרשאות מינימום, ראיות לצירוף בלבד, התאוששות ללא הגשה כפולה ו־INDETERMINATE כמצב חוקי — מתאימים במיוחד לסוכני AI, אוטומציות עסקיות, תהליכי סייבר ומחקר חישובי. אני מציג אותם כתבנית הנדסית שניתן להתאים, לא כהוכחה ש־R8 כבר אומתה בכל תחום אפשרי.

איך חברות מחקר יכולות לבנות על R8

לא תכננתי את R8 כסקריפט חד־פעמי למחקר אחד. היא יכולה לשמש שכבת בסיס למחקרים נוספים שבהם זמן החומרה יקר, הראיות מפוזרות והפקת הדוח עדיין ידנית. במקום לבנות בכל פעם מחדש מערכת הגשה, איסוף, אימות ודיווח, אפשר להתאים את חוזה הניסוי, שערי הכיול, מנגנוני עקיבות המקור, ההתאוששות והשחזור של R8 לפרוטוקול חדש.

• איתור שגיאות מראש: לזהות תכנון או תוצר שגוי לפני שמבזבזים זמן QPU יקר.
• עצירה מוקדמת: לעצור כאשר כיול קפוא אינו עובר, במקום להמשיך קמפיין שאי אפשר לאשר.
• מניעת עבודות כפולות: להתאושש מקריסה בלי להגיש שוב את אותה עבודה ובלי לזהם את בסיס הראיות.
• בסיס ראיות מאוחד: לרכז אסמכתאות, נתונים גולמיים, מניפסטים והחלטות במקום אחד שניתן לבדיקה.
• דוחות AI ניתנים למעקב: לחלץ ממצאים מתוך הראיות בלי לתת למודל לשנות את כללי ההכרעה.

המנגנונים האלה עשויים לצמצם זמן חומרה מבוזבז, בדיקות ידניות, שחזורים מיותרים וניתוחים חוזרים. זו תועלת הנדסית אפשרית — לא הבטחה לחיסכון קבוע. כל מחקר חדש עדיין דורש חוזה, כיולים, ספים, מודל איומים וביקורת מדעית שמתאימים לשאלה שלו.

מבחינת רישוי, קוד התוכנה מאפשר שימוש מסחרי בכפוף ל־AGPL-3.0-only. הנתונים והתוצרים הציבוריים מפורסמים תחת CC BY-NC 4.0, ולכן שימוש מסחרי בהם דורש הסכמה נפרדת. ההבחנה הזאת מאפשרת לחברת מחקר להעריך מראש מה ניתן למחזר כתוכנה ומה מחייב רישוי נוסף.

נכון להיום אני גם המפעיל שמכיר בצורה המלאה ביותר את R8. הפעלה אפקטיבית משלבת את הקוד הציבורי עם ה־Skills, שגרות הביקורת, הידע התפעולי והניסיון שצברתי במהלך הפיתוח. המטרה שלי היא להפוך עוד מהידע הזה לחוזים ותהליכים ניידים, כדי שמעבדות וחברות מחקר יוכלו לאמץ את המתודולוגיה בלי לוותר על ביקורת עצמאית.

מה אני בונה עכשיו ב־R10: מחקר נפרד על 156 קיוביטים

כדי ליישם ולבחון את המתודולוגיה בקנה מידה רחב יותר, אני עובד כעת על Algorithm R10: תכנון מחקר חקרני נפרד שמיישם את משמעת החוזה הקפוא, עקיבות המקור וה־fail-closed של R8 על שאלה פיזיקלית אחרת. R10 אינו המשך ישיר של קמפיין R8, אינו חלק ממהדורת v1.0.2 ואינו ניסיון נוסף להכריע P‑CTC.

ב־R10 אני מתכנן לבדוק שימור של אות גבול במימוש דיגיטלי, סופי ופתוח של מודל SSH: האם אות X לוגי בזרוע בעלת גבול חלש גדול מהאות בזרוע בעלת גבול חזק בעומק דיגיטלי שנקבע מראש. זו שאלה צרה על התנהגות גבול תחת ניתוח מותנה־סימטריה — לא מדידה של זמן פיזיקלי, לא הארכת זמן הקוהרנטיות ולא רטרו־סיבתיות.

יעד התכנון הוא ibm_kingston, ממשפחת המעבדים שבה IBM מתעדת ארכיטקטורת Heron בת 156 קיוביטים. המיפוי המקומי שכבר בניתי מכסה את מלוא טביעת החומרה: 28 מסילות פיזיות המחוברות ל־14 תאי dual-rail — עשרה תאים של 5+5 קיוביטים וארבעה של 7+7.

המשמעות של ״156 קיוביטים״ כאן מדויקת: כל PUB מתוכנן לכסות ולמדוד את מלוא טביעת החומרה, תוך הפעלה מקבילית של 12 תאי SSH ושני sentinels. אין כאן מצב קוונטי משותף או שזירה של 156 קיוביטים, והתאים שבתוך אותה משימת חומרה אינם 12 רפליקציות סטטיסטיות עצמאיות.

התכנון כולל שבעה עומקים דיגיטליים — 0, 1, 2, 3, 4, 6 ו־8 — בשני סדרי איזון נגדיים. ארבעה־עשר מעגלי ה־SSH עברו קומפילציה ואימות מבני מקומי: מיפוי זהות, מדידת כל 156 הקיוביטים, אפס SWAPs והתאמה בקומפילציה דטרמיניסטית חוזרת. זו מוכנות תוכנתית של התכנון, לא אימות חומרה או תוצאה מדעית. ניתוח ה־Bootstrap המתוכנן ישמור את כל 14 התאים יחד בכל שורת מדידה, כדי לא למחוק תלות מרחבית רק מפני שהיא מקשה על הסטטיסטיקה.

במקרה של R10, המתודולוגיה של R8 כבר הכתיבה החלטה מעשית. נכון לתמונת יעד החומרה מ־30 ביולי 2026, R10 נמצא בסטטוס DRAFT_LOCAL_DESIGN_HARDWARE_NO_GO: תמונת היעד הנוכחית כוללת חסמים קריטיים, ההקפאה המדעית והאימות הקריפטוגרפי טרם הושלמו, הרצת החומרה טרם אושרה ולא הוגשה משימה. ההגשה תתאפשר רק לאחר תמונת יעד חדשה ללא חסמים, בדיקת משכי מעגל וזליגה בין קיוביטים, כיול קטן ושער עוצמה סטטיסטית, רישום מוקדם, עוגן גיבוב חיצוני ותהליך הרצה נפרד עם מנגנון התאוששות בטוח.

זהו עקרון fail-closed בפעולה: המערכת מסרבת לאשר הגשת חומרה כאשר תנאי הקדם אינם מתקיימים.

גבולות המהדורה ותוכנית החיזוק הבאה

בחרתי לפרסם גם את גבולות v1.0.2, משום שאמינות טכנית נבנית מהיכולת להראות מה קיים ומה יתווסף בהמשך.

ברמת התשתית, מהדורה נעולה עדיין אינה שרשרת אספקה משוחזרת ברמת הביטים. לכן סביבת חבילות סגורה, סביבת בנייה, אישור מקור וגרסאות מערכת הן חלק מאותה משמעת שאני מיישם גם ב־תכנון תשתית יציבה ומאובטחת לעומסי AI.

פרסום המגבלות אינו מצמצם את ההישג; הוא מבהיר במדויק מה כבר נבדק ומה עדיין דורש עבודה. R8 היא פרויקט הנדסי פעיל עם בסיס ציבורי, ו־R10 מראה כיצד אני מעביר את המתודולוגיה לתכנון מחקר נוסף — לא להדגמה חד־פעמית או לכותרת שננטשת לאחר הפרסום.

המסקנה האישית שלי כמפתח

Algorithm R8 היא המערכת המקורית שפיתחתי באופן עצמאי כדי לחבר בין ניסוי קוונטי, תוכנה, סוכני AI, ראיות וגבולות טענה. תכננתי אותה מקצה לקצה, ניהלתי סביב הפיתוח מערך סוכנים אינטנסיבי, יצרתי את ה־Skills ואת שערי הבקרה, פרסמתי את הקוד ואת המעטפת המחקרית, והפעלתי אותה על תוצאה שהייתה יכולה בקלות להפוך לכותרת גדולה מדי.

ההישג המרכזי מבחינתי אינו שהתקבל אות חיובי. ההישג הוא שבניתי מערכת שלא נתנה גם לי לחרוג מהכללים שקבעתי. היא שמרה את האותות החיוביים, חשפה את מצב הכיולים וחסמה PASS שלא הושלם; בהתאם לחוזה, לאחר CAL_MAIN_MID_1 לא שלחתי את בלוקים 5–12 והסטטוס נשאר INDETERMINATE.