Projection Engineering מטילה Claims לא ודאיות לתוך גרף הניתן לביקורת

תמונה: נוצרה באמצעות Google Gemini.

מערכת אוטומטית אומרת ששכר הדירה של יולי לא שולם.

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

התשובה היא משפט אחד. גבול האימות שלה משתרע על פני העולם.

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

האימות נעשה יקר יותר מן היצירה.

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

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

אני מכנה את שכבת האחריות החסרה הזאת Projection Engineering.

השכבה החסרה בין רשומה להחלטה

המטרולוגיה אינה סומכת על המחוג

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

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

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

המשפט אינו סומך על הטענה

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

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

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

Fact פירושה Accepted Fact

השם Projection Engineering זקוק לגבול נוקשה. הוא אינו מבטיח לייצר אמת מוחלטת.

ב-Projection Engineering, Fact פירושה Accepted Fact.

Accepted Fact היא Claim שהוסמכה לשמש הנחה בהחלטה מסוימת, תחת מטרה, היקף, זמן ייחוס, רמת הוכחה ומדיניות מפורשים.

שלושה עצמים חייבים להישאר נפרדים:

  • Claim: טענה או תצפית שהגיש מקור מזוהה.
  • Accepted Fact: Claim שהתקבלה כהנחה באמצעות הליך מוסמך.
  • Conclusion: תוצאה שחושבה מ-Accepted Facts ומכללים.

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

Projection Engineering אינה בעלת האמת. היא מהנדסת את הגבול סביב החלטה כדי שאדם אחר יוכל לבדוק אותה ולערער עליה.

בינה מלאכותית כבר סגורה — על טוקנים

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

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

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

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

המטר מראה מה סגירות יכולה לעשות

בשנת 1983 הגדירה הוועידה הכללית ה-17 למשקולות ולמידות את המטר כמרחק שהאור עובר בריק במשך 1/299,792,458 של שנייה, וקיבעה את מהירות האור בדיוק על 299,792,458 m/s בתוך הגדרת מערכת היחידות הבין-לאומית (החלטה 1 של הוועידה הכללית ה-17 למשקולות ולמידות (1983)).

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

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

המקום שבו האנלוגיה נשברת

מטרולוגיה היא מדריך, לא תחפושת לבעיות שלא נפתרו.

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

שנית, לעיתים קרובות אפשר להפיץ אי-ודאות מספרית דרך משוואות. לטענות לא מוכרעות עדיין אין אריתמטיקה כללית באותה מידה. שימור supported, defeated ו-unknown לאורך גזירות ארוכות, בלי להלבין אותם לדיוק כוזב, נותר בעיית מחקר פתוחה.

שלישית, הכרזה שמקור שלם או שמדיניות מחייבת היא הפעלת סמכות. עקיבות יכולה לחשוף את הבחירה הזאת, אך אינה יכולה להפוך אותה לנטולת הטיה. Projection Engineering חייבת לחשוף מי הניח את האצבע על המאזניים; היא אינה יכולה להבטיח להסיר כל אצבע.

GAF אינה רשימה

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

לכן התוצר של Projection Engineering הוא Graph of Accepted Facts (GAF).

Records / Observations
          │
          ▼
        Claims ◀──── Evidence / Counterevidence
          │
          ▼
  Evaluation + Projection Policy
          │
          ▼
   Accepted Facts ─────┐
          │             │
          ▼             │
 Rules / Derivations    │
          │             │
          ▼             │
      Conclusions       │
                        │
 Provenance ────────────┘

GAF מחברת רשומות מקוריות, Claims שחולצו, ראיות תומכות ומפריכות, הערכות, מדיניות וסמכות, Accepted Facts, גזירות, מסקנות, גרסאות, חותמות זמן ותלויות. תקנים קיימים כבר ממדלים ישויות, פעילויות, סוכנים ויחסי provenance; PROV-O: אונטולוגיית PROV מראה שאוצר המילים הזה אינו חייב להשתייך למוצר מסד נתונים יחיד.

גם אין הכרח ש-GAF תחיה במסד נתונים גרפי. מסד נתונים טבלאי או יומן append-only מספיקים אם הם משמרים קשרים ושושלת נתונים דו-כיוונית.

  • ממסקנה, מבקר חייב להיות מסוגל ללכת לאחור דרך Accepted Facts ו-Claims אל הרשומות המקוריות.
  • מרשומה שנפסלה, המערכת חייבת להיות מסוגלת ללכת קדימה אל כל Accepted Fact, מסקנה ופעולה מוסמכת שאולי צריך לפתוח מחדש.

המסלול הראשון הופך החלטה לניתנת לביקורת. השני הופך תיקון לבר-חישוב.

תשלום שכר דירה אחד, שלוש בעיות הנדסיות

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

המשימה הראשונה היא פירוק הטענה:

A payment moved from the tenant's account to the landlord.  [accepted]
That payment discharged this month's rent obligation.       [undetermined]

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

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

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

Completeness contract C-04

Declarant: operator of ledger L
Scope: all settled transactions for account A during period P
Excludes: pending transactions and records held by other institutions
Authority: signed policy version V

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

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

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

מ-Claim לפעולה מוסמכת

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

Reality
   │
   ▼
Records / Observations
   │  preservation · calibration · transformation history
   ▼
Claims
   │  proposition decomposition · source evaluation · conflicts and gaps
   ▼
Projection
   │  purpose · scope · reference time · proof standard · authority · policy version
   ▼
GAF
   │  Accepted Facts · provenance · dependencies
   ▼
Closed Decision World
   │
   ▼
Deterministic Conclusion
   │
   ▼
Authorized Action

כל מעבר יכול לייצר שגיאה אחרת:

  • החמצת רשומה מקורית היא שגיאת איסוף.
  • OCR או חילוץ גרועים הם שגיאת התמרה.
  • מסגור הסוגיה הלא נכונה או קבלת ה-Claim הלא נכונה הם שגיאת היטל.
  • חישוב מסקנה שגויה מ-Accepted Facts נכונות הוא שגיאת כלל.
  • החלת מסקנה נכונה על היעד הלא נכון היא שגיאת ביצוע.

כל אחת דורשת תיקון אחר. ראיה חדשה מתקנת איסוף. הערכה מחדש מתקנת היטל. מנוע כללים מתוקן יכול להפעיל מחדש GAF קפואה. כשלי ביצוע דורשים ביטול, תיקון או פיצוי — לא שכתוב של העובדות. הכינוי “הבינה המלאכותית טעתה” לכל כשל הופך את כולם לבלתי ניתנים לתיקון.

שלמו את מחיר ההבנה פעם אחת

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

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

מטמון prompt אינו יכול להחליף את השכבה הזאת. מטמון משמר בתים וסדר. GAF משמרת משמעות ו-provenance. מטמון קידומת עלול להישבר כשהסדר משתנה; טענה יכולה להשתלב עם Claims שחולצו במקום אחר ולשרת כל החלטה שתלויה בה.

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

שושלת נתונים היא פסילת מטמון.

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

הגבול עם דיסציפלינות שכנות

Projection Engineering אינה תחליף ל-Data Engineering, Knowledge Engineering, Rule Engineering, Prompt Engineering או Context Engineering. היא בעלת גבול האחריות שהן חוצות כיום ללא אפוטרופוס אחראי יחיד.

Data Engineering מעבירה רשומות דרך source → ingest → transform → store → serve. Projection Engineering שואלת אם רשומה מכשירה מידע לשימוש כהנחה דרך record → claim → evaluate → project → GAF. סכמה תקפה יכולה להכיל רשומה כוזבת.

Knowledge Engineering מייצגת מושגים ויחסים לשימוש מכונה. Projection Engineering מתייחסת לכל יחס תחילה כ-Claim ורושמת מי הסמיך את השימוש בו כידע בהחלטה תחומה.

Rule Engineering מחשבת מסקנות מהנחות שסופקו. Projection Engineering בונה ומקפיאה את גרף ההנחות שעליו הכללים האלה פועלים.

Prompt Engineering מעצבת הוראות. Context Engineering בוחרת מידע לחישוב. Projection Engineering שואלת את השאלה המוקדמת יותר: איזו Claim המידע הזה מייצג, ומדוע מותר לו לשמש כאן הנחה?

prompt טוב יותר אינו יכול להציל הנחה שהתקבלה בטעות.

ה-LLM הוא עובד, לא הסמכות

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

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

אם אותו מודל מחלץ Claim, מקבל אותה, בוחר את הכלל, מסביר את התוצאה ומסמיך פעולה, קו העיבוד קורס ליצירה אטומה אחת. נרטיב בדיעבד אינו רשומת provenance.

היצירה יכולה להיות הסתברותית. קבלת Fact, השלמה והסמכות לפעול חייבות להיות מנוהלות בנפרד.

הבטחה סטטיסטית אינה יכולה להסביר את המקרה שלי

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

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

מה הייתה ההנחה במקרה שלי?

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

ההבחנה הזאת מגדירה את ההיקף. Projection Engineering אינה מיועדת לכל מערכת בינה מלאכותית. היא מיועדת למערכות שמקבלות החלטות הניתנות לערעור — אשראי, שכר, זכאות, פינוי, ביטוח, אישור רפואי ופעולות דומות שבהן אדם חייב להיות מסוגל לבדוק את מערכת ההנחות ולערער עליה. מסגרת NIST לניהול סיכוני בינה מלאכותית מתייחסת לאחריותיות ולשקיפות כמאפיינים של מחזור החיים, ואילו תקנה (EU) 2024/1689 מחייבת רישום אירועים במערכות בסיכון גבוה.

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

החוזה המינימלי

מערכת שטוענת שהיא עוסקת ב-Projection Engineering צריכה לענות בחיוב על כל השאלות הבאות:

  1. האם היא מבדילה בין רשומות מקוריות ל-Claims נגזרות ומצרפת לכל Claim מקור, זמן והיסטוריית התמרה?
  2. האם היא מפרקת Claims מורכבות לטענות שניתן לערער עליהן בנפרד, ורושמת מי ניסח את הסוגיות ומדוע?
  3. האם היא משמרת Claims סותרות וחלופות שנדחו במקום למחוק אותן?
  4. האם היא מבחינה בין false, unknown ו-not found, ודורשת חוזה שלמות לפני הפיכת היעדר לשלילה?
  5. האם היא יכולה לעקוב לאחור מ-Accepted Fact אל הראיה, המדיניות, הסמכות והגרסה — וממקור שנפסל קדימה אל המסקנות שהושפעו?
  6. האם היא יכולה לשחזר את ה-GAF המדויקת ואת תמונת המצב של הכללים ששימשו להחלטה, ולקבל את אותה מסקנה תחת אותה סגירות?
  7. האם היא יכולה לשמר שיפוט אנושי חוזר כמדיניות מאושררת בעלת היקף, חריגים ומועד כניסה לתוקף?
  8. האם קבלת Claim, שיפוט לפי כלל והסמכות לפעול מופרדים, עם הליך לפתיחה מחדש במקום למחיקת החלטת עבר?

אם תשובה כלשהי היא לא, המערכת מקדמת בשקט Claim ל-Fact במקום כלשהו.

מדוע זו דיסציפלינה הנדסית חדשה

הרכיבים כבר קיימים: provenance, ניהול ראיות, גרפי טיעון, מערכות שימור אמת, event sourcing, מנועי כללים, יומני ביקורת, בירור עובדות משפטי, מטרולוגיה והיסק בעולם סגור.

רכיבים אינם גבול אחריות. מסדי נתונים ו-ETL התקיימו לפני ש-Data Engineering התגבשה לתחום. שרתים ותסריטי פריסה התקיימו לפני DevOps. תחום נוצר כאשר כשלים חוזרים המפוזרים בין ארגונים נאספים תחת תפקיד אחראי אחד, מחלקה אחת של תוצרים ושיטות אימות הניתנות לחזרה.

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

באיזה רגע, מכוח סמכותו של מי ותחת איזו מדיניות הפכה רשומה מן המציאות ל-Accepted Fact שאפשר להשתמש בה בהחלטה?

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

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

להפוך שוב את האימות לזול

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

Projection Engineering בוחרת חוזה צר יותר:

  • לשמר Claims במקום למחוק מחלוקת.
  • לומר Accepted Fact בכל פעם ש-Fact פירושה הנחה מוסמכת.
  • לחבר כל קבלה לראיה, למדיניות, לסמכות, לזמן ולהיקף.
  • לעולם לא להפוך לא-ידוע לכוזב ללא חוזה שלמות.
  • להקפיא את עולם ההחלטה ואת הכללים שבהם נעשה שימוש בפועל.
  • לשחזר את המסקנה מאותם קלטים סגורים.
  • לשמר שיפוט חוזר כמדיניות מפורשת ומאושררת.
  • לפתוח החלטות מחדש כשהראיות משתנות במקום לשכתב את העבר.

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

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

לבינה מלאכותית כבר יש אריתמטיקה. חסר לה המוסד שמסביב לאריתמטיקה.

המטרה של Projection Engineering פשוטה:

להפוך שוב את האימות לזול.

המציאות נותנת לנו Claims.

החלטות דורשות Accepted Facts.

Projection Engineering מטילה Claims לתוך Graph of Accepted Facts הניתן לביקורת.

מאמרים קשורים

  • האמת אינה מתגלה — מדוע המציאות הפתוחה נותנת לנו Claims בעוד שעולמות מוסדיים תחומים יכולים לייצר עובדות אופרטיביות
  • מ-Claims ל-GAF — הארכיטקטורה הטכנית להטלת Claims לתוך גרף הניתן לביקורת
  • שטף אינו אמת — מדוע ראיות ניתנות לצפייה ובדיקות צריכות להחליף שפה משכנעת

מקורות