legal-ai/docs/product-specification.md

איפיון מוצר — עוזר משפטי

מסמך זה

מסמך איפיון מוצר (Product Specification) למערכת "עוזר משפטי" — כלי AI לכתיבת החלטות ועדת ערר לתכנון ובניה.

מצב: הושלם — עבר סקירת מומחה ותוקן תאריך התחלה: 2 באפריל 2026 בעל המוצר: חיים מרכוס

---

סעיף 0: בחירת מתודולוגיית איפיון

השאלה

מי המומחה המתאים להגדיר מוצר AI שמבצע עבודה מקצועית מורכבת (כתיבת החלטות משפטיות)?

שתי הגישות

גישה א: מנהל מוצר (Product Manager)

מתמחה ב: הגדרת "מה" — user stories, features, prioritization, go-to-market. מתודולוגיות: Lean Product, Jobs To Be Done (JTBD), Design Thinking. חוזק: מתרגם צורך עסקי למפרט טכני. מגדיר MVP. מתעדף features. חולשה: לא מתמחה בניתוח תהליכי עבודה מורכבים, לא מודד יעילות, לא מתכנן workflow אופטימלי.

גישה ב: מהנדס תעשייה וניהול (Industrial & Systems Engineer)

מתמחה ב: הגדרת "איך" — ניתוח תהליכים, מדידת זמנים, זיהוי צווארי בקבוק, אופטימיזציה. מתודולוגיות: Systems Engineering (INCOSE SE Handbook), Business Process Modeling (BPMN), Value Stream Mapping, Human-Machine Teaming. חוזק: מפרק תהליך מורכב לשלבים מדידים. מזהה איפה AI מוסיף ערך ואיפה לא. מתכנן ממשק אדם-מכונה. מודד KPIs. חולשה: פחות מתמחה בחוויית משתמש (UX) ובתעדוף עסקי.

ההמלצה: גישה משולבת עם דגש על הנדסת מערכות

הנימוק: המוצר שלנו הוא לא אפליקציה צרכנית אלא כלי עבודה מקצועי שמחליף/מסייע בתהליך מורכב. הבעיה המרכזית היא לא "אילו features לבנות" אלא "איך דפנה עובדת ואיפה AI נכנס לתהליך". זו בדיוק ההתמחות של הנדסת תעשייה ומערכות.

סימוכין אקדמיים:

1. INCOSE Systems Engineering Handbook (2023, 5th ed.) — מגדיר שכלי AI מקצועי דורש קודם כל "Operational Concept" — תיאור מלא של תהליך העבודה לפני ואחרי הכנסת המערכת (Chapter 4.2: Stakeholder Needs and Requirements).

2. Parasuraman, R., Sheridan, T.B., & Wickens, C.D. (2000). "A Model for Types and Levels of Human Interaction with Automation." IEEE Transactions on Systems, Man, and Cybernetics. — מגדיר 10 רמות אוטומציה (LOA) בין "האדם עושה הכל" ל-"המכונה עושה הכל". המפתח: לכל שלב בתהליך צריך להגדיר את רמת האוטומציה הנכונה. לא הכל צריך להיות אוטומטי.

3. Daugherty, P.R. & Wilson, H.J. (2018). "Human + Machine: Reimagining Work in the Age of AI." Harvard Business Review Press. — מגדיר מודל "collaborative intelligence" שבו AI ואדם משלימים זה את זה. רלוונטי כי דפנה לא רוצה שה-AI יחליף אותה — היא רוצה שיעזור לה.

4. Endsley, M.R. (2017). "From Here to Autonomy: Lessons Learned from Human-Automation Research." Human Factors. — מזהיר מ-"automation complacency" — כשאנשים סומכים יותר מדי על AI ומפסיקים לבדוק. קריטי בהקשר משפטי שבו דפנה חייבת לקרוא ולאשר כל מילה.

מסקנה: נשתמש בגישת Systems Engineering כמסגרת ראשית, עם רכיבים מ-Product Management לתעדוף ו-MVP.

---

טבלת מעקב איפיון

סעיף	נושא	סטטוס	הערות
סעיף 0	בחירת מתודולוגיה	✅ מלא	הנדסת מערכות + ניהול מוצר
סעיף 1	חזון המוצר	✅ מלא	בעיה, חזון, פתרון, משתמשים, מדדי הצלחה, scope
סעיף 2	בעלי עניין	✅ מלא	חיים (מפעיל), דפנה (מגיהה+חותמת), שופט (מבחן עליון), חברי ועדה, מזכירות, צדדים
סעיף 3	תהליך עבודה נוכחי	✅ מלא	נקודת כניסה, חומרים, תהליך, זמנים, צוואר בקבוק
סעיף 4	תהליך עבודה עתידי	✅ מלא	7 שלבים: קלט → עיבוד → תוצאה → סיעור מוחות (אם צריך) → כתיבה → פלט → למידה
סעיף 5	רמות אוטומציה	✅ מלא	3 רמות (אוטומטי/שיתופי/אנושי), מיפוי 11 שלבים, 7 עקרונות עיצוב, 4 סיכונים
סעיף 6	דרישות פונקציונליות	✅ מלא	40 דרישות ב-8 שלבים (כולל שלב 6 הגהת דפנה), כולן מבוססות על סעיפים 1-5
סעיף 7	דרישות לא-פונקציונליות	✅ מלא	12 דרישות: שפה, ביצועים, דיוק, אבטחה, זמינות, ממשק
סעיף 8	גרסה מינימלית (MVP)	✅ מלא	אין MVP — מוצר מלא בלבד. תוכנית הסמכה ב-4 שלבים
סעיף 9	מדדי הצלחה	✅ מלא	6 מדדים: אחוז שינוי, זמן, אפס הזיות, מענה לטענות, משקלות, ניטרליות
סעיף 10	סיכונים ומגבלות	✅ מלא	10 סיכונים עם מנגנוני הגנה, 4 מגבלות ידועות

---

סעיף 1: חזון המוצר (Product Vision)

טבלת מעקב שאלות — סעיף 1

שאלה	סטטוס	תשובה
מה הבעיה שהמוצר פותר?	✅ מלא	חיים (עו"ד, עוזר משפטי של דפנה) לא מצליח להתאים את סגנון הכתיבה שלו לסגנון של דפנה. צריך כלי AI שכותב בדיוק כמו דפנה
מי המשתמש העיקרי?	✅ מלא	חיים — מפעיל המערכת מהתחלה עד טיוטה סופית. דפנה רק מגיהה ומתקנת אחרי. הגרסה הסופית שדפנה מפיצה חוזרת למערכת ללמידה
מה התוצר הסופי שיוצא מהמערכת?	✅ מלא	קובץ DOCX מעוצב, כמעט מוכן לחתימה. עיצוב עברי RTL עם כותרות — skill קיים לייצור DOCX. נדרשות התאמות קטנות
מה "הצלחה" נראית?	✅ מלא	מצב תקין: דפנה משנה/מוסיפה עד 10% מהטקסט. הצלחה מלאה: 98% מהטקסט נשאר כמו שהמערכת כתבה
מה מחוץ ל-scope?	✅ מלא	המערכת רק כותבת החלטות. לא ניהול תיקים, לא תזמון, לא מיילים. מקבלת קבצים (PDF/DOCX/MD) ומסתמכת רק על מה שקיבלה — אסור לה להמציא מקורות או לצטט דברים שלא במסמכים

הבעיה

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

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

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

העיקרון: מינימום זמן, מקסימום תוצר.

משפט חזון

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

הפתרון

מערכת "עוזר משפטי" שמחליפה את שלב כתיבת הטיוטה הראשונית:

קלט: קבצים (PDF/DOCX/MD) מסוג כתבי בי-דין — ערר, תשובה, תגובה, פרוטוקול, תכנית, היתר, פסקי דין, החלטות.

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

פלט: קובץ DOCX מעוצב — טיוטה כמעט מוכנה לחתימה.

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

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

משתמשים

• משתמש ראשי: חיים מרכוס (עו"ד, עוזר משפטי) — מפעיל את המערכת מהתחלה עד טיוטה סופית
• משתמש עקיף: דפנה תמיר (עו"ד, יו"ר ועדת ערר) — מקבלת את הטיוטה, מגיהה, מתקנת, חותמת

מדדי הצלחה

• מצב תקין (target): דפנה משנה/מוסיפה עד 10% מהטקסט
• הצלחה מלאה (stretch): עד 5% שינוי

הערה: לפי מחקר Endsley (2017), מומחים בדרגת ההזדהות של דפנה כמעט תמיד ישנו ניסוחים — לא כי הם שגויים, אלא כי זו הדרך שלהם "לאמץ" את הטקסט. לכן יעד 2% לא ריאלי. יעד 5% מאפשר לדפנה מרחב אישי תוך שמירה על יעילות גבוהה. המדד יתכייל לאחר 5 החלטות ראשונות.

מחוץ ל-scope

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

---

סעיף 2: בעלי עניין (Stakeholders)

טבלת מעקב שאלות — סעיף 2

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

בעלי עניין

תפקיד	שם	מעורבות	צורך עיקרי
מפעיל המערכת	חיים מרכוס, עו"ד	מפעיל יום-יום — מהקמת תיק עד טיוטה סופית	טיוטה בסגנון דפנה, מינימום זמן, מקסימום תוצר
יו"ר ועדת הערר	דפנה תמיר, עו"ד	מקבלת טיוטה, מגיהה, מתקנת, חותמת	טיוטה שדורשת מינימום שינויים (יעד: עד 10%)
בעל עניין שקט: השופט	שופט בית משפט מנהלי	לא משתמש במערכת, אבל כל החלטה חייבת לעמוד בביקורתו	—

"מבחן השופט" — הדרישה העליונה של המוצר

כל החלטה שהמערכת מייצרת חייבת לעמוד בביקורת שיפוטית של שופט בית משפט לעניינים מנהליים (ובערעור — בית המשפט העליון). בפועל השופט בודק:

1. הנמקה מלאה — כל טענה שהועלתה קיבלה מענה. התעלמות מטענה = עילת ביטול.
2. תשתית עובדתית — העובדות מוצגות נכון, מלאות, לא מוטות. רקע לא ניטרלי = חשש למשוא פנים.
3. סבירות ומידתיות — ההכרעה סבירה לאור הטענות והעובדות. לא מספיק "נדחה" — צריך להסביר למה ולמה זה מידתי.
4. פרוצדורה תקינה — כל הצדדים קיבלו הזדמנות להשמיע קולם. דיון התקיים. הזדמנויות לטעון ניתנו.
5. ציטוט מדויק — כל הפניה לפסיקה, חקיקה או מסמך חייבת להיות מדויקת ומבוססת על מה שסופק בפועל.

זו לא דרישה סגנונית — זו הדרישה העליונה של המוצר.

בעלי עניין נוספים (לא משתמשים במערכת)

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

---

סעיף 3: תהליך העבודה הנוכחי (As-Is Process)

טבלת מעקב שאלות — סעיף 3

שאלה	סטטוס	תשובה
מתי המערכת נכנסת לתמונה?	✅ מלא	אחרי שהדיון הסתיים — כל הצדדים טענו בכתב ובעל פה, הוועדה דנה, ועכשיו צריך לכתוב החלטה
מה החומרים שעל השולחן ברגע הזה?	✅ מלא	כל מסמך שנמסר לוועדה: כתב ערר, כתב תשובה (ועדה מקומית + משיבים), פרוטוקולים, השלמות טיעון
מה אתה (חיים) עושה היום צעד אחרי צעד כשאתה כותב טיוטה?	✅ מלא	קורא את כל החומר → כותב פתח דבר/רקע → ממשיך צעד אחרי צעד. סדר הפרקים משתנה לפי סוג ההחלטה
כמה זמן התהליך לוקח היום?	✅ מלא	שבוע לטיוטה שלמה. יעד: יום אחד
מה הכי קשה / לוקח הכי הרבה זמן?	✅ מלא	סיכום הטענות והדיון. בעיקר הדיון (בלוק י) — הוא צוואר הבקבוק

נקודת הכניסה

המערכת נכנסת לתמונה אחרי שכל השלבים הבאים הסתיימו:

• כתבי הערר הוגשו ✅
• כתבי תשובה/תגובה הוגשו ✅
• השלמות טיעון (אם היו) הוגשו ✅
• דיון פרונטלי בוועדת הערר התקיים ✅
• הוועדה דנה פנימית והחליטה על הכיוון ✅

עכשיו — צריך לכתוב את ההחלטה. כאן המערכת נכנסת.

תהליך העבודה הנוכחי (ללא המערכת)

1. קריאת כל החומר — כתבי ערר, תשובות, פרוטוקולים, השלמות
2. כתיבת פתיחה ורקע (בלוקים ה-ו) — הגדרות, עובדות, תכניות
3. סיכום טענות (בלוק ז) — לכל צד בנפרד — לוקח הרבה זמן
4. הליכים (בלוק ח) — אם היו סיור/השלמות/החלטות ביניים
5. דיון (בלוק י) — צוואר הבקבוק — ניתוח משפטי, פסיקה, יישום, הכרעה
6. סיכום (בלוק יא) — הוראות אופרטיביות
7. שליחה לדפנה — דפנה מגיהה, מתקנת, חותמת

זמן נוכחי: שבוע לטיוטה שלמה יעד: יום אחד

ניתוח מבנה 3 החלטות — ממצאים

מניתוח הכט (דחייה), בית הכרם (קבלה חלקית), אריאלי (קבלה) עולה:

בלוקים קבועים (תמיד קיימים):

• ה — פתיחה (אבל בניסוחים שונים: "לפנינו" / "עניינה של החלטה זו")
• ו — רקע / "פתח דבר" (היקף משתנה: 3% עד 18%)
• ז — טענות הצדדים
• י — דיון והכרעה
• יא — סיכום / סוף דבר
• יב — חתימות

בלוקים מותנים (תלויים בתיק):

• ח — הליכים: קיים כשהיו הליכים מורכבים (דיון + סיור + השלמות רבות). באריאלי = 27% מההחלטה
• ט — תכניות/מסגרת נורמטיבית: קיים כשיש מורכבות תכנונית או שאלה משפטית (ס' 152). בהכט = 32%

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

---

סעיף 4: תהליך העבודה העתידי (To-Be Process)

טבלת מעקב שאלות — סעיף 4

שאלה	סטטוס	תשובה
איך אתה רואה את התהליך עם המערכת?	✅ מלא	מינימום ממשק, אבל חייב man-in-the-middle לפני הדיון
מה השלב שחייב אדם?	✅ מלא	הזנת התוצאה שדפנה קבעה (דחייה/קבלה/חלקית) — לפני שהמערכת כותבת את הדיון
מי קובע את התוצאה?	✅ מלא	דפנה — היא השופטת. היא מעבירה לחיים את ההחלטה
מה דפנה מעבירה?	✅ מלא	לא קבוע — לפעמים רק "נדחה/התקבל", לפעמים מנומק יותר
מה קורה עם הנימוקים של דפנה?	✅ מלא	אם דפנה נותנת נימוק — ישר לכתיבה. אם רק תוצאה — סיעור מוחות בין חיים למערכת על בסיס החומר המשפטי כדי לגבש את הכיוון. לא מתחילים לכתוב דיון לפני שיש כיוון מדויק

תהליך העבודה העתידי

שלב 1 — קלט (חיים) חיים מעלה למערכת את כל המסמכים שנמסרו לוועדה (PDF/DOCX/MD).

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

שלב 3 — הזנת תוצאה (חיים) ← man-in-the-middle חיים מזין את התוצאה שדפנה קבעה:

• סוג: דחייה / קבלה / קבלה חלקית
• נימוק: אם דפנה נתנה → ישר לשלב 4ב

שלב 4א — סיעור מוחות (חיים + מערכת) ← רק אם אין נימוק אם דפנה נתנה רק תוצאה בלי נימוק — המערכת וחיים מנהלים שיח:

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

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

שלב 5 — פלט (חיים) חיים מקבל DOCX מעוצב — טיוטה כמעט מוכנה.

שלב 6 — הגהה ותיקונים (דפנה) דפנה קוראת, מתקנת, מגיהה, חותמת.

שלב 7 — לולאת למידה (מערכת) הגרסה הסופית שדפנה מפיצה חוזרת למערכת — המערכת לומדת מהפער.

---

סעיף 5: רמות אוטומציה (Levels of Automation)

בסיס אקדמי

הניתוח מבוסס על 9 מקורות אקדמיים (ביבליוגרפיה מלאה בנספח):

מקור	תרומה
פרסורמן, שרידן וויקנס (2000)	מודל 10 רמות אוטומציה × 4 שלבי עיבוד מידע
אנדסלי (2017)	סיכוני שאננות אוטומציה — דווקא מומחים רגישים יותר
קאמינגס (2004)	הטיית אוטומציה — commission errors ו-omission errors
סורדין (2018)	שלוש רמות AI במשפט: תומך / מחליף / משבש
רילינג (2020)	הבחנה בין פרוצדורלי (אוטומטי) לשיקול דעת (אנושי)
CEPEJ (2018)	חמישה עקרונות אתיים ל-AI בשיפוט — "under user control"
INCOSE (2023)	הקצאת פונקציות דינמית — לפי מורכבות, סיכון, עומס

שלוש רמות אוטומציה

רמה	שם	תיאור	LOA (פרסורמן)
א — אוטומטי	המערכת מבצעת, מדווחת לאדם	7-9
ב — שיתופי	המערכת מנסחת טיוטה, האדם מאשר/עורך/דוחה	4-5
ג — אנושי	האדם מבצע, המערכת מספקת מידע בלבד	1-3

מיפוי דו-ממדי: רמות אוטומציה × שלבי עיבוד מידע (Parasuraman 2000)

שלב עבודה	שלב עיבוד (Parasuraman)	רמה
קריאת מסמכים וסיווג	Information Acquisition	א — אוטומטי
חילוץ טענות	Information Acquisition + Analysis	ב — שיתופי
חיפוש תקדימים	Information Analysis	ב — שיתופי
גיבוש נימוקים	Information Analysis + Decision Selection	ב — שיתופי
קביעת תוצאה	Decision Selection	ג — אנושי
כתיבת בלוקים ה-ח	Action Implementation	ב — שיתופי
כתיבת דיון (י)	Action Implementation (high-stakes)	ב — שיתופי
ייצוא DOCX	Action Implementation (low-stakes)	א — אוטומטי

מיפוי שלבי העבודה לרמות אוטומציה

שלב	תוכן	רמה	נימוק
קריאת מסמכים וסיווג	זיהוי סוג מסמך, חילוץ מטא-דאטה	א — אוטומטי	פרוצדורלי, ניתן לביקורת, סיכון נמוך
חילוץ טענות	סיכום טענות מכתבי טענות	ב — שיתופי	דורש נאמנות למקור — AI מנסח, אדם מוודא
כתיבת רקע (בלוק ו)	עובדות, תכניות	ב — שיתופי	חובת ניטרליות — AI מנסח, אדם בודק
כתיבת טענות (בלוק ז)	סיכום טענות בגוף שלישי	ב — שיתופי	נאמנות למקור
כתיבת הליכים (בלוק ח)	תיעוד כרונולוגי	ב — שיתופי	בעיקר עובדתי אבל דורש דיוק
חיפוש תקדימים	RAG — מציאת פסיקה דומה	ב — שיתופי	AI מציע 3-5 חלופות, אדם בוחר (קאמינגס)
קביעת תוצאה	דחייה/קבלה/חלקית	ג — אנושי בלבד	החלטה שיפוטית — דפנה בלבד
גיבוש נימוקים	סיעור מוחות על הכיוון	ב — שיתופי	AI מציג טענות ומציע כיוונים, חיים מחליט. אופציונלי גם כשיש נימוק
כתיבת דיון (בלוק י)	ניתוח משפטי, CREAC	ב — שיתופי	AI מנסח על בסיס הכיוון שנקבע, אדם עורך
כתיבת סיכום (בלוק יא)	הוראות אופרטיביות	ב — שיתופי	נגזר מהדיון, אבל חייב לשקף הכרעה מדויקת
ייצוא DOCX	עיצוב מסמך	א — אוטומטי	טכני לחלוטין

עקרונות עיצוב (מבוססי מחקר)

עיקרון	מקור	יישום
"אדם בלולאה"	אנדסלי (2017)	דפנה קובעת תוצאה, חיים מאשר כיוון — לפני שהמערכת כותבת
שקיפות	אנדסלי (2017), CEPEJ (2018)	כל טיוטה מציגה מקורות. רמת ודאות ליד תקדימים
מעורבות אקטיבית	אנדסלי (2017)	חובת מעבר מבלוק לבלוק — אין "ייצר הכל" בלחיצה
הצגת חלופות	קאמינגס (2004)	חיפוש תקדימים מחזיר 3-5 חלופות, לא "התקדים הנכון"
כפייה קוגניטיבית	קאמינגס (2004)	חיים מזין כיוון לפני שרואה טיוטת דיון
אחריותיות	CEPEJ (2018)	החלטה נושאת חתימת דפנה. תיעוד שנעשה שימוש ב-AI
הקצאה דינמית	INCOSE (2023)	ככל שהמשימה קרובה יותר להכרעה — פחות אוטומציה

סיכונים שזוהו

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

---

סעיף 6: דרישות פונקציונליות

טבלת מעקב שאלות — סעיף 6

שאלה	סטטוס	תשובה
מה פורמטי הקלט?	✅ מלא	PDF, DOCX, MD — כל מסמך שנמסר לוועדה (מסעיף 1)
מה סוגי המסמכים?	✅ מלא	ערר, תשובה, תגובה, פרוטוקול, תכנית, היתר, פסקי דין, החלטות (מסעיף 1)
מה הפלט?	✅ מלא	DOCX מעוצב RTL, כמעט מוכן לחתימה (מסעיף 1)
מה סוגי הערר?	✅ מלא	רישוי (1xxx), היטל השבחה (8xxx), פיצויים (9xxx) — סגנון שונה לכל אחד
מה שלבי התהליך?	✅ מלא	7 שלבים כולל man-in-the-middle (מסעיף 4)
מה רמות האוטומציה?	✅ מלא	3 רמות: אוטומטי/שיתופי/אנושי (מסעיף 5)

דרישות פונקציונליות — לפי שלבי התהליך

שלב 1: קלט מסמכים

מזהה	דרישה	עדיפות
ק-1	המערכת מקבלת קבצי PDF, DOCX, MD	חובה
ק-2	המערכת מחלצת טקסט מלא מכל מסמך (כולל OCR לסרוקים)	חובה
ק-3	המערכת מסווגת כל מסמך לסוג (ערר/תשובה/פרוטוקול וכו')	חובה
ק-4	המערכת מזהה את הצדדים (עוררים, משיבים, ועדה, מבקשי היתר)	חובה
ק-5	המערכת מזהה את סוג הערר (רישוי/השבחה/פיצויים) לפי מספר התיק	חובה
ק-6	המערכת מודדת גודל כל החומרים בטוקנים ומתריעה אם חורגים מ-80% של context window	חובה
ק-7	כשחומרים חורגים — המערכת מפעילה אסטרטגיית סיכום/חלוקה עם סדר עדיפויות (ערר ותשובה קודם לנספחים)	חובה
ק-8	הגנת prompt injection — הפרדה בין הוראות מערכת לתוכן מסמכים. סניטיזציה של קלט ממסמכי צדדים חיצוניים	חובה
ק-9	איחוד תיקים — המערכת תומכת בתיק שמאחד כמה עררים (כמו 1078+1083). בלוק ה מגדיר כמה מספרי תיק, בלוק ז מכסה טענות של כל העוררים	רצוי

שלב 2: עיבוד וניתוח

מזהה	דרישה	עדיפות
ע-1	המערכת מחלצת טענות מכתבי טענות — לפי צד	חובה
ע-2	המערכת מזהה תכניות חלות על המקרקעין	חובה
ע-3	המערכת מזהה פסיקה שמצוטטת במסמכים	חובה
ע-4	המערכת מציגה סיכום חומרים לחיים לפני כתיבה	חובה

שלב 3: הזנת תוצאה (man-in-the-middle)

מזהה	דרישה	עדיפות
ת-1	חיים מזין את התוצאה שדפנה קבעה: דחייה / קבלה / קבלה חלקית	חובה
ת-2	חיים מזין נימוק (אם דפנה נתנה) — טקסט חופשי	חובה
ת-3	אם אין נימוק — המערכת מפעילה שלב סיעור מוחות (שלב 4א). גם אם יש נימוק — חיים יכול לבקש סיעור מוחות כאופציה	חובה

שלב 4א: סיעור מוחות (כשאין נימוק)

מזהה	דרישה	עדיפות
ס-1	המערכת מציגה את הטענות המרכזיות מהחומר	חובה
ס-2	המערכת מציעה 2-3 כיוונים אפשריים לנימוק (לא המלצה אחת)	חובה
ס-3	חיים והמערכת מנהלים שיח עד שמגיעים לכיוון מוסכם	חובה
ס-4	התוצר: מסמך כיוון — נימוקים מרכזיים, סדר, פסיקה רלוונטית	חובה
ס-5	לא מתחילים לכתוב דיון לפני שיש כיוון מאושר	חובה

שלב 4ב: כתיבת טיוטה

מזהה	דרישה	עדיפות
כ-0	המערכת ממלאת אוטומטית בלוקים א-ד (כותרת, הרכב, צדדים, "החלטה") ויב (חתימות) ממטא-דאטה של התיק	חובה
כ-1	המערכת כותבת בלוק אחרי בלוק לפי סדר: ה → ו → ז → ח → ט → י → יא	חובה
כ-2	כל בלוק נכתב בסגנון דפנה — טון, ביטויי מעבר, מבנה	חובה
כ-3	סגנון הכתיבה מותאם לסוג הערר (חם לרישוי, קר להשבחה)	חובה
כ-4	בלוק ח נכתב רק אם היו הליכים מעבר לדיון פשוט (סיור/השלמות)	חובה
כ-5	בלוק ט — רישום תכניות תמיד. פרק נפרד רק כשמורכבות תכנונית מצדיקה	חובה
כ-6	בלוק י — CREAC: מסקנה בפתיחה, כלל, הסבר, יישום, מסקנה	חובה
כ-7	בלוק י — מענה לכל טענה שהוצגה בבלוק ז	חובה
כ-8	כלל ברזל: המערכת מצטטת רק מה שסופק כמסמך	חובה
כ-9	רקע ניטרלי (בלוק ו) — ניטרליות לקסיקלית (אין מילות שיפוט) וגם מבנית (סדר הצגת עובדות מאוזן, אורך יחסי של סעיפים לא מטה, בחירת עובדות לא סלקטיבית)	חובה
כ-10	ללא כפילות (בלוק י) — הפניות לבלוקים קודמים, לא חזרה	חובה
כ-11	משקלות בלוקים לפי יחסי הזהב (סוג ערר × תוצאה)	חובה
כ-12	שמירת מצב ביניים — אחרי כל בלוק שנכתב, המצב נשמר ב-DB. חיים יכול להפסיק ולהמשיך מחר	חובה
כ-13	recovery — אם המערכת נופלת, חיים ממשיך מהבלוק האחרון שנשמר	חובה
כ-14	חזרה אחורה — חיים יכול לחזור לבלוק קודם ולכתוב אותו מחדש. בלוקים תלויים מתעדכנים בהתאם	חובה
כ-15	ניהול גרסאות — כל בלוק שומר היסטוריית גרסאות. חיים יכול לחזור לגרסה קודמת של בלוק ספציפי	רצוי

שלב 5: פלט

מזהה	דרישה	עדיפות
פ-0	בדיקת QA אוטומטית לפני ייצוא — ולידציה של: כל הפניה מוולדת (grounding), כל טענה נענתה, רקע ניטרלי, משקלות בטווח, מספור רציף. אם נכשל — לא מייצא, מציג דוח שגיאות	חובה
פ-1	ייצוא DOCX מעוצב — גופן David, RTL, כותרות, מספור סעיפים רציף	חובה
פ-2	מקומות תמונה מסומנים (GIS, תשריט, סיור)	רצוי
פ-3	הגדרות "להלן" מופיעות לפני השימוש הראשון	חובה

שלב 6: הגהת דפנה ותיקונים

מזהה	דרישה	עדיפות
ה-1	חיים שולח את ה-DOCX לדפנה (מייל / שיתוף קובץ — מחוץ למערכת)	חובה
ה-2	דפנה מגיהה ומתקנת ב-Word — עם track changes	חובה
ה-3	חיים מעלה את הגרסה הסופית (DOCX שדפנה חתמה) בחזרה למערכת	חובה
ה-4	המערכת מזהה שזו גרסה סופית (לא טיוטה) ומפעילה את לולאת הלמידה	חובה
ה-5	שמירת הגרסה הסופית ב-DB עם קישור לטיוטה המקורית	חובה

שלב 7: לולאת למידה

מזהה	דרישה	עדיפות
ל-1	קליטת גרסה סופית (שדפנה חתמה) בחזרה למערכת	חובה
ל-2	השוואת טיוטה לגרסה סופית — זיהוי מה שונה	חובה
ל-3	חילוץ לקחים — ביטויי מעבר חדשים, דפוסי כתיבה שהשתנו, שגיאות חוזרות	חובה
ל-4	עדכון בסיס הידע: הוספת ביטויים חדשים ל-transition_phrases, עדכון יחסי זהב, עדכון דוגמאות ב-RAG	חובה
ל-5	מנגנון עדכון: לא fine-tuning אלא עדכון RAG index + few-shot examples + prompt engineering. הגרסה הסופית הופכת לדוגמה שה-prompt מפנה אליה	חובה
ל-6	מנגנון rollback — אם עדכון מדרדר איכות (אחוז שינוי עולה), חזרה למצב קודם	חובה

---

סעיף 7: דרישות לא-פונקציונליות

מזהה	קטגוריה	דרישה	עדיפות
לפ-1	שפה	כל הממשק, הפלט והשיח בעברית	חובה
לפ-2	שפה	תמיכה מלאה ב-RTL — בממשק, ב-DOCX, ובטבלאות	חובה
לפ-3	ביצועים	טיוטה שלמה תוך שעות (לא ימים) — יעד: יום עבודה אחד כולל סיעור מוחות	חובה
לפ-4	ביצועים	חיפוש תקדימים (RAG) — תשובה תוך 10 שניות	רצוי
לפ-4א	ביצועים	כתיבת בלוק בודד — עד 5 דקות לבלוקים ה-ט, עד 15 דקות לבלוק י (opus + thinking)	רצוי
לפ-4ב	ביצועים	כתיבה אסינכרונית — חיים מפעיל כתיבת בלוק וממשיך לעבוד. התראה כשהבלוק מוכן	רצוי
לפ-5	דיוק	מנגנון grounding — כל הפניה לפסיקה/חקיקה/מסמך מקושרת למסמך מקור ספציפי עם citation tracking	חובה
לפ-5א	דיוק	ולידציה אוטומטית — כל ציטוט/הפניה נבדק מול המסמכים שסופקו. הפניה שלא עוברת ולידציה = נחסמת (לא נכנסת לטיוטה)	חובה
לפ-5ב	דיוק	מדד: 0% הפניות לא מוולדות — לא שאין הזיות, אלא שכל הזיה נתפסת לפני שנכנסת לטיוטה	חובה
לפ-6	דיוק	ציטוטים — נאמנות מוחלטת למקור. לא לשנות מילים, לא לקצר בלי לציין	חובה
לפ-7	אבטחה	חומרי התיקים חסויים — לא נשלחים לשירותים חיצוניים מלבד Anthropic API	חובה
לפ-8	אבטחה	ניהול סודות דרך Infisical — לא hardcoded	חובה
לפ-9	זמינות	המערכת רצה על שרת Nautilus — זמינה 24/7	רצוי
לפ-10	תחזוקה	גיבוי DB יומי אוטומטי	חובה
לפ-11	ממשק	מינימום ממשק — עבודה דרך Claude Code (CLI), לא דרך web UI	חובה
לפ-12	מעקב	כל פעולה מתועדת — מי הזין, מתי, מה שונה	רצוי

---

סעיף 8: MVP — גרסה מינימלית

אין MVP — מוצר מלא בלבד

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

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

מגבלת scope גרסה ראשונה

הגרסה הראשונה מכסה רישוי ובנייה (1xxx) והיטל השבחה (8xxx) בלבד.

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

קריטריונים להרחבה לפיצויים:

• לפחות 3 החלטות סופיות מסוג 9xxx נקלטו ופורקו
• parser מכויל לסוג הזה
• יחסי זהב מוגדרים

תוכנית השקה — לא MVP אלא מבחן הסמכה

במקום "MVP → שיפור" — תהליך של מבחן הסמכה לפני שימוש אמיתי:

שלב	תוכן	קריטריון מעבר
שלב א — פיתוח	בניית כל 42 הדרישות	כל הדרישות ממומשות
שלב ב — מבחן על תיק שהושלם	המערכת כותבת החלטה לתיק שכבר יש לו החלטה סופית (למשל הכט)	השוואת הטיוטה להחלטה הסופית — פער קטן מ-10%
שלב ג — מבחן על תיק חי	המערכת כותבת טיוטה לתיק אמיתי שדפנה טרם כתבה	דפנה בודקת — אם שינתה פחות מ-10% → עובר
שלב ד — שימוש מבצעי	שימוש שוטף עם לולאת למידה	יעד: 98% ללא שינוי

---

סעיף 9: מדדי הצלחה (KPIs)

מדד	תקין	הצלחה	מדידה
אחוז שינוי — כמה דפנה משנה מהטיוטה	עד 10%	עד 5%	ראה הגדרה מתמטית למטה. יתכייל אחרי 5 החלטות

הגדרה מתמטית: אחוז שינוי

שיטת מדידה: word-level edit distance (Levenshtein על מילים, לא תווים)

נוסחה:

אחוז_שינוי = (מספר_מילים_שהשתנו / סך_מילים_בטיוטה_המקורית) × 100

מה נספר כ"שינוי":

• הוספת מילה = 1 שינוי
• מחיקת מילה = 1 שינוי
• החלפת מילה = 1 שינוי
• הוספת סעיף שלם = מספר המילים בסעיף החדש
• מחיקת סעיף שלם = מספר המילים בסעיף שנמחק

מה לא נספר:

• שינויי פיסוק (נקודה, פסיק) = 0
• שינויי רווח/שורה חדשה = 0
• שינוי סדר סעיפים (ללא שינוי תוכן) = 0

דוגמה:

• טיוטה: 5,000 מילים
• דפנה שינתה 400 מילים (200 מחיקות, 100 הוספות, 100 החלפות)
• אחוז שינוי: 400/5,000 × 100 = 8% → עומד ביעד (≤10%) | זמן לטיוטה — מרגע העלאת חומרים עד DOCX | יום עבודה | חצי יום | מדידת זמן מקצה לקצה | | הפניות לא מוולדות — ציטוטים/מקורות שלא עברו ולידציה מול מסמכים שסופקו | 0% | 0% | ולידציה אוטומטית עם grounding — כל הפניה מקושרת למסמך מקור | | מענה לכל טענה — כל טענה בבלוק ז מקבלת מענה בבלוק י | 100% | 100% | בדיקת קישור טענה ← מענה | | משקלות בלוקים — בטווח יחסי הזהב ±10% | עומד | עומד | ספירת מילים אוטומטית | | רקע ניטרלי — בלוק ו ללא מילות שיפוט או ציטוטי צדדים | עובר ולידציה | עובר ולידציה | סקריפט ולידציה אוטומטי |

---

סעיף 10: סיכונים ומגבלות

סיכון	חומרה	הסתברות	מנגנון הגנה
הזיית מקור — המערכת מצטטת פסק דין שלא קיים	קריטית	בינונית	כלל ברזל: רק מה שסופק. ולידציה אוטומטית של כל הפניה
רקע לא ניטרלי — מילות שיפוט ברקע	גבוהה	בינונית	סקריפט ולידציה + רשימת מילים אסורות
טענה ללא מענה — טענה מבלוק ז שלא נענתה בבלוק י	גבוהה	בינונית	קישור אוטומטי טענה ← מענה + בדיקת כיסוי
שאננות אוטומציה — דפנה מפסיקה לבדוק טיוטות	גבוהה	גבוהה	מדידת אחוז שינוי בלולאת למידה — אם יורד מתחת ל-1% → התראה
הטיית אוטומציה — חיים מאמץ תקדים שגוי	גבוהה	בינונית	הצגת 3-5 חלופות, לא המלצה אחת
סגנון לא מתאים — המערכת כותבת בסגנון חיים ולא בסגנון דפנה	גבוהה	גבוהה בהתחלה	למידה מ-7 החלטות סופיות + לולאת למידה מתמשכת
שינוי פסיקה — תקדים שהמערכת מסתמכת עליו בוטל/שונה	גבוהה	נמוכה	המערכת מסתמכת רק על מה שסופק — לא מחפשת באינטרנט
תלות ב-API — Anthropic API לא זמין	בינונית	נמוכה	אין workaround — המערכת לא עובדת בלי API
חוסר בנתוני אימון — אין החלטות לפיצויים (9xxx)	בינונית	ודאי	צריך להמתין עד שיהיו החלטות מהסוג הזה
מורכבות חריגה — תיק עם 10+ צדדים או 50+ מסמכים	בינונית	נמוכה	אין מגבלה טכנית אבל אין ניסיון — צריך בדיקה
חריגת context window — תיק מורכב עם חומרים רבים שחורגים מ-context window	קריטית	בינונית-גבוהה	מדידת גודל חומרים בטוקנים לפני עיבוד. אסטרטגיית chunking/summarization למסמכים ארוכים. סף התראה כשמתקרבים ל-80% מה-context. סדר עדיפויות: מסמכים קריטיים (ערר, תשובה) לפני נספחים
prompt injection ממסמכי מקור — מסמכים מצדדים חיצוניים יכולים להכיל טקסט שמשפיע על ה-LLM	גבוהה	נמוכה	הפרדה בין הוראות מערכת לתוכן מסמכים. סניטיזציה של קלט. flagging של דפוסים חשודים

מגבלות ידועות

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