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

## מסמך זה
מסמך איפיון מוצר (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 החלטות סופיות לאימון | הסגנון עלול להיות לא מדויק — ישתפר עם כל החלטה שחוזרת מדפנה |
| המערכת לא בודקת עדכניות פסיקה | אם תקדים בוטל — המערכת לא תדע. חיים אחראי לבדוק |
| המערכת לא מחפשת פסיקה באינטרנט | רק מה שסופק כמסמך — יתרון (אין הזיות) וחיסרון (עלולה לפספס) |