180 lines
4.8 KiB
Markdown
180 lines
4.8 KiB
Markdown
|
# SIL Engineering Validation Program
|
|||
|
|
|
|||
|
|
> v1.0 = Feature Complete. Nu börjar valideringsfasen.
|
|||
|
|
> 6–8 veckors empirisk validering innan aktivering.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Översikt
|
|||
|
|
|
|||
|
|
| Fråga | Vad vi mäter | Hur vi mäter | Success-kriterium |
|
|||
|
|
|-------|-------------|--------------|-------------------|
|
|||
|
|
| 1. Hjälper SIL människor? | Tid till merge, regressionsbuggar, följsamhet | Logga beslut, jämför med/utan SIL | 20% färre regressionsfel |
|
|||
|
|
| 2. Kan SIL motivera slutsatser? | Provenance completeness, förklaringskvalitet | Granska 50 slumpmässiga analyser | 90% av slutsatser fullt spårbara |
|
|||
|
|
| 3. Robusthet mot förändring? | Graf-stabilitet vid refactoring | Simulerade förändringar | < 10% degradation vid refactoring |
|
|||
|
|
| 4. Fungerar på okänt projekt? | Korrekthet på open source-projekt | Testa på 3 externa projekt | > 70% recall på nya projekt |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Fråga 1: Hjälper SIL verkligen människor?
|
|||
|
|
|
|||
|
|
### Metriker
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
Tid från PR till merge:
|
|||
|
|
Med SIL: X timmar
|
|||
|
|
Utan SIL: Y timmar
|
|||
|
|
Förbättring: (Y-X)/Y
|
|||
|
|
|
|||
|
|
Regressionsbuggar efter merge:
|
|||
|
|
Med SIL: A
|
|||
|
|
Utan SIL: B
|
|||
|
|
Förbättring: (B-A)/B
|
|||
|
|
|
|||
|
|
Följsamhet:
|
|||
|
|
Utvecklare följer SIL:s rekommendation: P%
|
|||
|
|
Utvecklare ignorerar SIL:s rekommendation: Q%
|
|||
|
|
|
|||
|
|
Rätt vs fel:
|
|||
|
|
SIL rätt, utvecklare fel: R%
|
|||
|
|
Utvecklare rätt, SIL fel: S%
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Implementation
|
|||
|
|
|
|||
|
|
- `validation/human-impact.mjs` — Logga och analysera mänsklig interaktion
|
|||
|
|
- `validation/decision-log.jsonl` — Varje beslut med utfall
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Fråga 2: Kan SIL motivera sina slutsatser?
|
|||
|
|
|
|||
|
|
### Checklista per slutsats
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
✅ Vilken regel användes?
|
|||
|
|
✅ Vilka observationer användes?
|
|||
|
|
✅ Vilka artefakter användes?
|
|||
|
|
✅ Vilka noder traverserades?
|
|||
|
|
✅ Hur stor del var verifierad?
|
|||
|
|
✅ Hur stor del var inferens?
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Implementation
|
|||
|
|
|
|||
|
|
- `validation/provenance-audit.mjs` — Granska 50 slumpmässiga analyser
|
|||
|
|
- `validation/provenance-score.mjs` — Betygsätt completeness 0-100%
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Fråga 3: Hur robust är SIL mot förändring?
|
|||
|
|
|
|||
|
|
### Simulerade förändringar
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
1. Byt namn på tjänster
|
|||
|
|
2. Flytta kod mellan paket
|
|||
|
|
3. Dela upp moduler
|
|||
|
|
4. Lägg till nya beroenden
|
|||
|
|
5. Ändra katalogstruktur
|
|||
|
|
6. Introducera avsiktliga arkitekturavvikelser
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Implementation
|
|||
|
|
|
|||
|
|
- `validation/robustness-test.mjs` — Kör simulerade förändringar
|
|||
|
|
- `validation/refactoring-simulator.mjs` — Simulera refactoring-scenarier
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Fråga 4: Kan SIL analysera ett okänt projekt?
|
|||
|
|
|
|||
|
|
### Testprojekt
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
1. Ett medium-stort Node.js-projekt (t.ex. Express)
|
|||
|
|
2. Ett medium-stort Python-projekt (t.ex. FastAPI)
|
|||
|
|
3. Ett medium-stort Go-projekt (t.ex. Gin)
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Process
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
1. SIL bygger graf från kod
|
|||
|
|
2. Identifierar beroenden
|
|||
|
|
3. Analyserar en historisk PR
|
|||
|
|
4. Föreslår tester
|
|||
|
|
5. Uppskattar blast radius
|
|||
|
|
6. Jämför med verklighet
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Implementation
|
|||
|
|
|
|||
|
|
- `validation/external-project-test.mjs` — Testa på open source-projekt
|
|||
|
|
- `validation/cross-project-metrics.mjs` — Jämför metriker mellan projekt
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Två-lagers arkitektur
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
┌─────────────────────────────────────────┐
|
|||
|
|
│ PROBABILISTISKT LAGER │
|
|||
|
|
│ LLM-resonemang, heuristik, │
|
|||
|
|
│ uppskattningar, rekommendationer │
|
|||
|
|
│ Confidence: < 0.99 │
|
|||
|
|
└─────────────────────────────────────────┘
|
|||
|
|
│
|
|||
|
|
▼
|
|||
|
|
┌─────────────────────────────────────────┐
|
|||
|
|
│ DETERMINISTISKT LAGER │
|
|||
|
|
│ Graf, regler, AST, beroenden, │
|
|||
|
|
│ policyer, verifierbara fakta │
|
|||
|
|
│ Confidence: 0.99-1.00 │
|
|||
|
|
└─────────────────────────────────────────┘
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Beslutsmotor redovisar:
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
Slutsats: "Wallet påverkar Stripe"
|
|||
|
|
Confidence: 0.95
|
|||
|
|
|
|||
|
|
Källa:
|
|||
|
|
70% deterministiskt (AST-verifierat beroende)
|
|||
|
|
30% probabilistiskt (heuristik baserad på namnkonvention)
|
|||
|
|
|
|||
|
|
Verifierad: Ja (AST)
|
|||
|
|
Infererad: Nej
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Tidsplan
|
|||
|
|
|
|||
|
|
| Vecka | Fokus |
|
|||
|
|
|-------|-------|
|
|||
|
|
| 1-2 | Fråga 1: Logga mänsklig interaktion, samla baseline |
|
|||
|
|
| 3-4 | Fråga 2: Provenance-granskning, förbättra spårbarhet |
|
|||
|
|
| 5-6 | Fråga 3: Robusthetstester, simulerade förändringar |
|
|||
|
|
| 7-8 | Fråga 4: Externa projekt, tvärsnittsanalys |
|
|||
|
|
| 9 | Sammanställning, go/no-go beslut |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Success-kriterier för v1.0
|
|||
|
|
|
|||
|
|
| Kriterium | Mål |
|
|||
|
|
|-----------|-----|
|
|||
|
|
| Färre regressionsfel | 20% minskning |
|
|||
|
|
| Snabbare merge | 15% förbättring |
|
|||
|
|
| Provenance completeness | > 90% |
|
|||
|
|
| Robusthet vid refactoring | < 10% degradation |
|
|||
|
|
| Recall på nya projekt | > 70% |
|
|||
|
|
| Utvecklarnas förtroende | > 60% följer rekommendationer |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
*Engineering Validation Program*
|
|||
|
|
*"Visa att det fungerar, inte bara att det är snyggt"*
|