GRITT PI Lab - filosofische vaardigheidsmodule en onderzoeksplatform

Status: canonieke blauwdruk, bedieningshandleiding en implementatieregister; PI v0.4 live op staging en production; LOBE graph-E2E geaccepteerd voor PI-II-shadow; automatische persoonlijke PI-runtime blijft uit

Eigenaar: Mind Your Axis

Versie: 0.6-dev, 2026-07-26

Toegang eerste fase: projecteigenaar en technisch bevoegde admins; later uitsluitend expliciet aangewezen onderzoekers per project

Documentkaart:

• §0: positie binnen de gezamenlijke Kennisproject- en Frontdeskarchitectuur;
• §§1–10: productfilosofie, onderzoeksgrenzen en ontstaansgeschiedenis;
• §§11–17: normatief PI-projectmodel, internalisatie, projectstem en autonomie;
• §§18–24: governance, techniek, kosten, test- en deploybeleid;
• §25: bedieningshandleiding en foutreferentie;
• §26: feitelijk implementatie- en vrijgaveregister;
• §27: bindend v0.4-ontwerp voor iteratieve synthese, graph-augmented RAG en broncontrole;
• §28: feitelijke niet-graph-hardening van de live v0.4-laag;
• §29: bindend developmentcontract voor PI-II, Frontdesk en de gecontroleerde overgang naar LOBE.

Bij een verschil tussen een oudere ontwerpzin en §27 geldt voor de live v0.4-laag §27. Voor PI-II/LOBE geldt §29. §26 en de vrijgaveregisters blijven uitsluitend de feitelijke bewijsbron voor wat werkelijk gebouwd en vrijgegeven is.

0. Positie binnen GRITT Kennisprojecten en Frontdesk

Vanaf 2026-07-26 is GRITT Kennisprojecten — geïntegreerde architectuur voor PI, PI Lab, Newsroom en Frontdesk normatief voor de gedeelde projecthuls, memberships, bronrevisies, kennisingrediënten, deliberation cases, releases, kanalen en de Frontdesk-informatiearchitectuur.

PI Lab blijft normatief voor:

• filosofische vaardigheden en gespreksacties;
• Perspective/Personal Intelligence-synthese, methoden, projectstem en

epistemische statussen;

• wetenschappelijke studies, consent, cohorten, annotatie en evaluatie;
• de feitelijke implementatie- en vrijgavestatus van PI v0.4 en PI-II.

PI Lab wordt daarmee geen parallelle generieke werkplaats. De eindrichting is:

GRITT Kennisproject in Frontdesk
→ capability Perspective / Personal Intelligence
→ optioneel capability Research / PI Lab
→ immutable projectrelease
→ privé-, team-, cohort- of publiek kanaal

Een publieke toepassing zoals Stoic Spar is een kanaaldeployment op een goedgekeurde projectrelease, geen kopie van bronnen, synthese of projecttabellen. Gezamenlijke wetenschappelijke editing gebruikt projectmemberships en rolscopes; er komt geen gedeeld account.

De term PI is historisch overbelast. In deze handleiding behouden bestaande code- en implementatiereferenties hun naam. Voor nieuwe architectuur geldt:

• de accountgebonden oude persoonlijke PI-functie is **Persoonlijke

afstemming** en blijft buiten de projectcanon;

• een brongebonden, ontwikkelbaar perspectief is de

Perspective/Personal Intelligence-capability van een kennisproject;

• een wetenschappelijk onderzoek daaromheen is een PI Lab Study.

Bij een conflict over gedeelde project-, Frontdesk-, release- of kanaalobjecten gaat de overkoepelende Kennisprojecten-blauwdruk voor. Bij een conflict over filosofische inhoud, studie-eisen of de feitelijke PI-implementatiestatus gaat dit document voor.

1. Waarom PI Lab bestaat

De bestaande beta-functie Philosophical Instructivity (PI) maakt een compacte, individuele gedragsstrategie voor een GRITT-gebruiker. Dat is nuttig voor timing, voorkeuren, reflectieve routines en persoonlijke context. Het is echter niet genoeg om GRITT inhoudelijk beter te laten werken met filosofische vragen, levensvragen en niet-klinische filosofische begeleiding.

PI Lab is de volgende laag. Het doel is een filosofisch vaardige GRITT te kunnen ontwerpen, toetsen en verbeteren zonder dat GRITT verandert in een opzichtig andere persona of in een oncontroleerbare therapeutische chatbot.

De beoogde uitkomst is dat GRITT in een gesprek over bijvoorbeeld iemands dag, keuzes, relaties, werk, zorgen of levenshouding kan:

• beter onderscheiden tussen feiten, interpretaties, waarden, emoties, verwachtingen en handelingsmogelijkheden;
• relevante filosofische kaders herkennen zonder er automatisch een lesje van te maken;
• een passende vraag, samenvatting, tegenstelling, oefening of denkrichting kiezen;
• de gebruiker niet wegdrukken in een vooraf gekozen theorie;
• helder maken wanneer een filosofische invalshoek slechts een mogelijkheid is;
• terughoudend blijven bij klinische, crisis- of diagnostische vragen.

PI Lab is dus geen stijlskin. De normale GRITT-stijl blijft rustig, direct, menselijk en niet belerend. De inhoudelijke vaardigheid verandert wel: GRITT leert beter zien wat voor soort menselijke vraag hier voorligt en welke filosofische handeling op dat moment passend kan zijn.

2. Productpositie en grenzen

2.1 Drie verschillende lagen

Deze lagen mogen niet worden samengevoegd. Persoonlijke PI mag geen onderzoeksdataset worden zonder expliciete toestemming en een goedgekeurd studieprotocol. Een onderzoeksmodule mag niet ongemerkt alle gebruikersgedrag veranderen.

Aanvulling 2026-07-18: het algemene Interactional Memory (IM) is eveneens geen vierde PI-laag. IM is een productbrede, optionele contextvoorziening met eigen consent, retentie en LOBE-profiel (user_memory_v0.1). PI mag een door de runtime geselecteerde herinnering gebruiken wanneer PI actief is en de herinnering relevant is, maar PI mag de IM-master switch niet omzeilen, claims niet als onderzoeksmateriaal kopiëren en geen modelhypothese tot filosofisch of psychologisch feit verheffen. Persoonlijke PI blijft eigenaar van het gedragsdraaiboek; IM bewaart alleen herzienbare gesprekscontext over de gebruiker.

2.2 Geen klinische therapie

PI Lab ondersteunt filosofische praktijk, reflectie, levensvragen, betekenisgeving, waardenonderzoek, besluitvorming en gewoontevorming. Het doet niet aan diagnose, behandeling, crisisinterventie of claims over geestelijke gezondheid.

Harde grenzen:

• geen diagnostische labels of quasi-klinische interpretaties;
• geen bewering dat een gesprek therapie vervangt;
• geen dwingende adviezen bij zelfbeschadiging, geweld, psychose, acute verslaving of ernstig onveilig handelen;
• bij acute risico's: empathisch vertragen, stimuleren om een passend menselijk hulpcontact in te schakelen, en geen lange filosofische oefening starten;
• onderzoek met kwetsbare groepen alleen na een expliciet protocol, toestemming en passende ethische toetsing.

3. Inhoudelijk vaardigheidsmodel

3.1 Niet een lijst denkers, maar observeerbare vaardigheden

Een bruikbare PI-module wordt niet getraind als een encyclopedie van filosofen. De kern bestaat uit observeerbare gespreksvaardigheden met duidelijke contra-voorbeelden en beoordelingscriteria.

3.2 Filosofische bronnen als gereedschapskist

De eerste capability-modules kunnen meerdere tradities bevatten. Elke traditie wordt beschreven als een optioneel denkpatroon met toepassingscriteria, risico's en voorbeeldgesprekken.

• Socratische dialoog: begripsverheldering, onderzoek van aannames, redelijke tegenspraak.
• Aristotelische deugdethiek: karakter, praktijk, gewoonten, concrete middenwegen en contextgevoelige oordeelsvorming.
• Stoische praktijk: onderscheid tussen invloed en niet-invloed, maar zonder emotionele minimalisering.
• Existentialistische en fenomenologische praktijk: situatie, keuze, ambiguiteit, verantwoordelijkheid, beleving en betekenis.
• Pragmatistische benadering: gevolgen, experimenten, kleine revisies van handelingshypothesen.
• Narratieve filosofie en hermeneutiek: verhaal, interpretatie, identiteit, meerdere lezingen van gebeurtenissen.
• Zorgethiek en relationele autonomie: afhankelijkheid, relaties, zorgverantwoordelijkheid en machtsasymmetrie.
• Kritische theorie en politieke filosofie: sociale structuren, macht, taal, uitsluiting en institutionele context.

Een module mag nooit impliceren dat een bepaalde traditie universeel juist is. Elke module moet ten minste bevatten: wanneer deze invalshoek nuttig kan zijn, wanneer hij misplaatst is, welke vragen passend zijn, welke niet, en hoe GRITT terugschakelt naar gewoon menselijk gesprek.

3.3 Gespreksactie in plaats van verborgen redenering

De runtime bewaart en toont geen raw chain-of-thought. Wel mag zij een beperkte, controleerbare gespreksactiekaart maken. Die bevat bijvoorbeeld:

{
  "situation_type": "waardenconflict",
  "candidate_actions": ["samenvatten", "waarde expliciteren", "concrete vervolgoptie vragen"],
  "chosen_action": "waarde expliciteren",
  "why_user_visible": "Er lijkt spanning te zitten tussen autonomie en loyaliteit.",
  "module_version": "pi-capability-0.3",
  "safety_mode": "normal"
}

Voor gewone gebruikers is dit standaard niet zichtbaar. Onderzoekers kunnen, als het protocol dat toestaat, alleen de gesaneerde gespreksactiekaart en de gebruikte moduleversie inspecteren. Dit maakt onderzoek reproduceerbaar zonder modelinterne denksporen te claimen of bloot te leggen.

4. Hoe GRITT werkelijk vaardiger wordt

Geen enkel middel is op zichzelf genoeg. De volgorde hieronder is bewust gekozen.

4.1 Capability prompt en beleidslaag

Eerst komt een korte, versieerbare capability-prompt die de algemene gespreksvaardigheden, grenzen en taalregels definieert. Dit is snel aanpasbaar, inspecteerbaar en geschikt voor vroege pilots.

De prompt bevat niet een complete filosofische canon. Hij verwijst naar de actuele moduleconfiguratie, toegestane gespreksacties, veiligheidsregels en de regel dat theorie alleen wordt ingebracht wanneer zij de gebruiker helpt.

4.2 Curated RAG met primaire en betrouwbare secundaire bronnen

RAG is geschikt voor inhoudelijke nauwkeurigheid: passages uit primaire teksten, peer-reviewed toelichtingen, door onderzoekers geselecteerde lesmaterialen en expliciete methodische handleidingen. RAG is minder geschikt om basisgedrag of timing vast te zetten.

Voor elke bron zijn minimaal nodig:

• rechthebbende/licentie en toegestane gebruikswijze;
• vertaling, editie, auteur, jaartal en bronverwijzing;
• conceptlabels en mogelijke toepassing;
• waarschuwingen tegen simplificatie of misbruik;
• bronversie, datum van opname en curator.

RAG moet passages alleen aanleveren als ze inhoudelijk relevant zijn. De gebruiker krijgt geen lange citaten als een korte uitleg of vraag beter past.

4.3 Gestructureerde dialoogstate

Een gewone chatgeschiedenis is te grof voor filosofische begeleiding. Naast het gesprek bewaart de runtime, alleen binnen passende toestemming en retentie, een beperkte state:

• huidig onderwerp en expliciete vraag;
• onderscheid tussen gebeurtenis, interpretatie, waarde, emotie, doel en belemmering;
• open vragen of spanningen;
• eerder gekozen taal en gewenste diepgang;
• vrijwillige vervolgstappen en of de gebruiker daarop wil terugkomen;
• module- en promptversie.

Deze state is geen psychologisch profiel en geen diagnose. Zij vervalt of wordt gewist volgens de PI- en accountinstellingen.

4.4 Tooling voor filosofische kwaliteit

De capability kan deterministische hulpmiddelen gebruiken voor zaken die een LLM slecht consistent doet:

• conceptkaart: claims, redenen, waarden, tegenvoorbeelden en open vragen structureren;
• bronverwijzing: exacte editie en passage bijhouden;
• contradictie- en dekkingscheck: signaleren dat een antwoord alleen maar een theorie herhaalt;
• safety- en scopecheck: bepalen of een gesprek naar klinische of crisistaal verschuift;
• evaluatierubric: toetsing op empathie, helderheid, filosofische relevantie, niet-dwingendheid en feitelijke juistheid.

4.5 Fine-tuning pas na een goede werkbank

Fine-tuning is waardevol wanneer herhaaldelijk blijkt dat een basismodel dezelfde gespreksfout maakt ondanks een goede prompt en RAG: bijvoorbeeld steeds te snel een denker noemen, waarden verwarren met feiten, overmatig adviseren of een onmenselijke ondervragingsstijl kiezen.

Train dan op dialogische beslissingen en hoogwaardige antwoorden, niet op losse quotes of lange theorie-uitleg. Een trainingsitem moet minimaal bevatten:

• geanonimiseerde context;
• gewenste gespreksactie;
• goed antwoord;
• afkeurenswaardig antwoord met reden;
• tags voor traditie, vaardigheid, risico, taal, diepgang en doelgroep;
• beoordelaar, datum, licentie/rechten en moduleversie.

SFT is geschikt voor consistente positieve voorbeelden. DPO is geschikt voor paren met een betere en slechtere reactie. RFT is pas verantwoord bij een smalle, meetbare taak met betrouwbare grader, bijvoorbeeld correcte argumentmapping of bronverwijzing. Een model mag niet automatisch worden bijgetraind op privégesprekken.

4.6 Evaluatie en kalibratie

Elke capability-versie moet tegen een vaste evaluatieset draaien voordat zij voor een cohort actief wordt. Minimaal:

• inhoudelijk begrip van een filosofische passage;
• een gewone persoonlijke reflectievraag;
• conflict tussen twee waarden;
• vraag om ongewenste zekerheid of diagnose;
• acute of onveilige situatie;
• gesprek waarin geen filosofische invalshoek nodig is;
• gesprek waarin de gebruiker theorie afwijst of een ander kader kiest.

Meet niet alleen voorkeur. Meet ook:

• passende actie gekozen;
• geen ongefundeerde theorieclaim;
• geen ongewenste pathologisering;
• gebruiker behoudt autonomie;
• antwoord blijft concreet en begrijpelijk;
• brongebruik klopt wanneer bronnen worden genoemd;
• menselijke beoordelaars kunnen de beslissing reproduceren.

5. PI Lab als onderzoeksplatform

5.1 Waarom de huidige Fine-tune Workshop nog niet onderscheidend genoeg is

De bestaande Fine-tune Workshop kan modellen, datasets, beoordelingsitems en Azure-runs registreren. Dat is noodzakelijk, maar voor filosofisch onderzoek nog generiek. Een onderzoeker kiest niet alleen een model en uploadt JSON; die wil een methode operationaliseren, dialooggedrag vergelijken, afwijkingen annoteren, een cohort begrenzen en begrijpen waarom versie A anders reageert dan versie B.

PI Lab wordt onderscheidend wanneer het de volgende onderzoekshandelingen productmatig ondersteunt:

1. een filosofische hypothese als versieerbaar protocol formuleren;
2. theorie, broncorpus, prompt, model, veiligheidsregels en evaluatierubric samen vastleggen;
3. gespreksfragmenten zorgvuldig annoteren op situatietype, gespreksactie en kwaliteit;
4. meerdere moduleversies of modellen blind vergelijken;
5. alleen na menselijke review een kandidaatversie voor een klein cohort activeren;
6. observaties, consent, dataminimalisatie, export en reproduceerbaarheid centraal bewaren.

5.2 Rollen en rechten

Alle rechten zijn server-side, auditbaar en deny-by-default.

5.3 Studieobjecten

Een PI Lab-studie bevat ten minste:

• vraag en hypothese;
• doelgroep, inclusie- en uitsluitcriteria;
• niet-klinische scope en stopvoorwaarden;
• informed-consenttekst en privacygrondslag;
• broncorpus met rechtenmanifest;
• capability/promptversie;
• modelroute en eventueel fine-tuned model;
• annotatieschema en rubric;
• evaluatieset en vooraf gekozen succescriteria;
• cohort, looptijd en retentie;
• reviewlog, deploymentbesluit en terugrolplan.

5.4 Workbench-flow

flowchart LR
  A["Onderzoeksvraag"] --> B["Protocol + safetygrens"]
  B --> C["Bronnen en rechtenmanifest"]
  C --> D["Annotatie van dialogsituaties"]
  D --> E["Prompt/RAG/tool kandidaat"]
  E --> F["SFT of DPO kandidaat, indien nodig"]
  F --> G["Blinde evaluatie + safety review"]
  G --> H{"Goedgekeurd voor klein cohort?"}
  H -- nee --> D
  H -- ja --> I["Cohortactivering met consent"]
  I --> J["Geaggregeerde analyse + reproduceerbare export"]

5.5 Interface die wetenschappers werkelijk helpt

De toekomstige PI Lab-pagina hoort niet slechts een ander label op Fine-tune Workshop te zijn. Zij heeft zes rustige werkvlakken:

1. Studies: lijst met hypothese, status, eigenaar, cohort, actieve module- en modelversie.
2. Methode: theoriekaart, toegestane gespreksacties, contra-indicaties, broncorpus en rechten.
3. Annoteren: transcript naast labels voor situatie, interventie, kwaliteit, alternatief antwoord en veiligheidsmarkering.
4. Vergelijken: blind A/B- of A/B/C-vergelijking van modellen, prompts of modules tegen dezelfde casus.
5. Evalueren: rubric-scores, interbeoordelaarsbetrouwbaarheid, foutenclusters en regressies.
6. Publiceren: expliciete cohortactivatie, versiepin, rollback, consentstatus en exportpakket.

Een geselecteerde onderzoeker ziet alleen studies waarvoor hij of zij rechten heeft. Persoonlijke PI-documenten van gewone gebruikers verschijnen hier nooit als bronmateriaal.

6. Technisch ontwerp

6.1 Nieuwe objecten

Deze vroege objectlijst beschrijft de onderzoeksplatformlaag. Voor de eerste privéprojectimplementatie is het concretere datamodel in §21.1 leidend; gelijknamige objecten worden hergebruikt en niet dubbel aangemaakt.

Voorgestelde tabellen, naast de bestaande fine-tune registry:

• pi_capability_modules: titel, doel, status, capability_json, prompt_id, version, owner, activated_at.
• pi_source_collections: module/studie, bronmetadata, licentie, tekstlocatie, curator, rights_status.
• pi_studies: hypothese, scope, consent_version, privacy_profile, status, principal_investigator_id.
• pi_study_cohorts: studie, naam, inclusiecriteria, consent_required, starts_at, ends_at, status.
• pi_annotation_items: gepseudonimiseerde context, labels, kandidaat- en ideaalantwoord, auteur, reviewer, versie.
• pi_annotation_reviews: score, rationale, safety_flags, reviewer, created_at.
• pi_evaluation_runs: module/model/prompt, datasetversie, metrics_json, reviewer_decision, created_at.
• pi_deployments: studie/module/model/koppeling, cohort, admin_confirmed_by, activated_at, rolled_back_at.
• pi_research_audit: actor, studie, object, actie, reden, timestamp.

Een data-export moet studie, corpusmanifest, itemversies, annotaties, rubric, prompt/moduleconfig, model/deployment-id, resultaten en hashes bevatten. Secrets, persoonlijke identifiers en raw private PI-notities blijven uitgesloten.

6.2 Runtimevolgorde

1. Bepaal of de gebruiker in een PI Lab-cohort zit; anders blijft gewone PI of gewone chat leidend.
2. Laad alleen de gepinde module, promptversie, toegestane bronnen en veiligheidsprofiel.
3. Bouw beperkte dialoogstate uit de huidige beurt en geautoriseerde studiesessie.
4. Kies een gespreksactie via model/prompt, eventueel met een controleerbare regel- of rubriccheck.
5. Genereer het antwoord met normale GRITT-stijl en de capability-instructie.
6. Log module-, model-, prompt- en bronversie plus gesaneerde actiekaart.
7. Stuur bij veiligheidsflags naar de afgesproken stop- of escalatieroute.

De runtime moet geen gewone webretrieval inzetten om filosofische claims te improviseren. Externe actuele bronnen kunnen alleen binnen een expliciete studie/toolconfig worden gebruikt en worden gelogd met bron, tijd en rechtenstatus.

6.3 Wat nog gebouwd moet worden

Gebouwd/aanwezig:

• persoonlijke PI-beta met toggle, PI-document, beperkte runtimeinjectie en admin-debug;
• Fine-tune Workshop met modelregistratie, annotatiebasis, SFT/DPO-export en graderfundament;
• Azure-modelrouting en bestaande admin-/auditpatronen.

Nog niet gebouwd:

• PI Capability Module registry;
• PI Lab-studies, onderzoekerrollen en cohortrechten;
• filosofiespecifieke annotatie- en rubricinterface;
• bron- en rechtenmanifest voor filosofische corpora;
• blinde vergelijkingsmodus en interbeoordelaarsanalyse;
• consent/pseudonimisering/retentie per studie;
• inhoudelijke evaluatieset met menselijke referentiebeoordeling;
• deploymentgate van PI Lab-versie naar geselecteerd cohort;
• externe ethische/governance-afspraken voor onderzoekers.

7. Eerste haalbare pilot

Start niet met "een therapeutische AI". Start met een beperkte, onderzoekbare module:

PI Lab pilot: reflectief besluitgesprek bij werk- en levenskeuzes.

• doelgroep: vrijwillige volwassen deelnemers, niet in crisis, kleine interne testgroep;
• theorie: begripsverheldering, waardenexplicitering, perspectiefwisseling en pragmatische kleine stappen;
• doel: testen of GRITT gebruikers helpt hun eigen vraag scherper te formuleren zonder dwingend of klinisch te worden;
• materiaal: 80-150 zorgvuldig geschreven en beoordeelde dialoogitems, een kleine rechtenvrije/gelicentieerde broncollectie, duidelijke contra-voorbeelden;
• vergelijking: basischat versus capability-prompt plus RAG; fine-tuning pas toevoegen wanneer die vergelijking een stabiele tekortkoming laat zien;
• evaluatie: menselijke reviewers scoren helderheid, autonomie, filosofische passendheid, empathie, veiligheid en bruikbaarheid;
• stopregel: geen deployment naar bredere groep wanneer safetyreview, bronrechten, consent of evaluatie onvoldoende zijn.

8. Acceptatiecriteria

Een PI Lab-module is pas bruikbaar voor een beperkte pilot wanneer:

• theoretische bron, licentie en versie per bron bekend zijn;
• de module een expliciet doel, scope en contra-indicaties heeft;
• menselijke reviewers de evaluatieset hebben goedgekeurd;
• de module in normale GRITT-stijl antwoordt en geen professor- of therapierol speelt;
• de runtime geen raw chain-of-thought opslaat of toont;
• persoonlijke PI, onderzoekdata en gewone chatdata technisch gescheiden blijven;
• deelnemerstoestemming, uitstap en retentie zijn geregeld;
• model-, prompt-, corpus- en evaluatieversie per gesprek reproduceerbaar zijn;
• een adminbevestiging en rollbackpad bestaan voordat een cohort wordt geactiveerd.

9. Kernbesluit

Voor inhoudelijk betere filosofisch-therapeutische omgang is de juiste combinatie:

1. een kleine, duidelijke filosofische capability-prompt;
2. curated RAG voor betrouwbare inhoud en bronverantwoording;
3. beperkte dialoogstate en expliciete gespreksacties;
4. deterministische safety- en kwaliteitschecks;
5. menselijke annotatie en evaluatie;
6. pas daarna gerichte SFT/DPO-fine-tuning;
7. een PI Lab-workbench die studies, rechten, consent, versies en uitkomsten reproduceerbaar maakt.

PI Lab wordt pas voor een bredere wetenschappelijke groep aantrekkelijk wanneer die werkbank werkelijk minder omslachtig is dan losse promptbestanden, cloudfine-tunes en spreadsheets, en tegelijk methodisch strenger is dan een algemene chatbotconfiguratie.

10. Uitbreiding 2026-07-15: van filosofische vaardigheid naar een ontwikkelbaar perspectief

10.1 Aanleiding en ontwerpgeschiedenis

De eerste PI Lab-blauwdruk beschreef vooral algemene filosofische gespreksvaardigheden en een onderzoekswerkbank. In de verdere ontwerpdialoog is het doel preciezer en ambitieuzer geworden. Thomas wil een gekozen filosofisch of wetenschappelijk perspectief — als eerste pilot zijn eigen masterscriptie over stoïcisme — niet alleen als bronkennis beschikbaar maken, maar als een samenhangende aanvulling op een algemene AI.

Daarmee verschuift PI van alleen informatie kunnen terugvinden naar vijf samenhangende vermogens:

1. begrippen, argumenten, methoden en onderlinge relaties reconstrueren;
2. die structuur gebruiken bij nieuwe situaties die niet letterlijk in de bronnen staan;
3. zelfstandig vragen, tegenwerpingen, interpretaties en hypothesen ontwikkelen;
4. een herkenbaar, ontwikkelbaar intellectueel perspectief in de eerste persoon voeren;
5. de eigen overtuigingen, twijfels, wijzigingen en resterende problemen controleerbaar bijhouden.

Deze uitbreiding vervangt de oudere gedachte dat een PI Capability Module noodzakelijk één algemene, centraal beheerde productmodule is. Een module kan ook een privé, door de eigenaar benoemd PI-project zijn. Zo'n project gebruikt de algemene intelligentie van GRITT als basis en voegt daar een specifiek perspectief, methoden, voorkeuren, waarden en een ontwikkelgeschiedenis aan toe.

De beoogde ontwikkelvolgorde blijft:

• A — persoonlijk project: Thomas bouwt en valideert eerst één privéproject op basis van zijn eigen filosofische werk;
• B — algemene PI Capability Builder: andere bevoegde gebruikers kunnen later op dezelfde manier een eigen project bouwen, dupliceren, delen of publiceren;
• C — PI Lab-samenwerking: aangewezen wetenschappers kunnen bijdragen aan eigen of gezamenlijke projecten, datasets, benchmarks en modelvarianten;
• D — coherente digitale persoonlijkheid: een afzonderlijke experimentele tak onderzoekt een ontwikkelbaar zelfmodel, waarden, morele afwegingen, voorkeuren en coherentiecontrole.

Fase A bepaalt nu het uitvoerbare product. B, C en D blijven in het datamodel en rechtenmodel voorzien, maar mogen niet doen alsof zij al volledig operationeel zijn.

10.2 Kernbegrip: een perspectief wordt toegevoegd aan een algemene AI

Het PI-project vervangt het basismodel niet en beperkt zich niet tot wetenschappelijke inhoud. De runtime bestaat conceptueel uit vier lagen:

flowchart TD
  A["Algemene GRITT/LLM-capaciteiten"] --> B["Privé PI-project met eigen naam"]
  B --> C["Bronnen en bronankers"]
  B --> D["Concepten, argumenten, methoden en waarden"]
  B --> E["Zelfmodel: standpunten, hypothesen, twijfels en open problemen"]
  C --> F["Projectstem en gespreksgedrag"]
  D --> F
  E --> F
  F --> G["Gesprek, begeleiding en autonoom onderzoek"]
  G --> H["Nieuwe hypothesen en wijzigingsvoorstellen"]
  H --> E

De algemene AI levert taal, algemene wereldkennis, redeneervermogen, planning en toolgebruik. Het PI-project levert het gekozen gezichtspunt: welke onderscheidingen belangrijk zijn, welke vragen vanzelf opkomen, welke argumenten en methoden beschikbaar zijn, welke waarden richting geven en waar het project zelf nog onzeker over is.

Een PI-project mag algemene kennis gebruiken wanneer die voor de vraag nodig is. Het moet wel zichtbaar onderscheiden tussen:

• wat uit de canonieke projectbronnen komt;
• wat uit algemene kennis of een aanvullende bron komt;
• wat het project daar zelf uit afleidt of als hypothese ontwikkelt.

11. Productobjecten en scheiding van verantwoordelijkheden

11.1 Persoonlijke PI, PI-project en PI Lab Study

De eerdere driedeling wordt als volgt aangescherpt:

Een persoonlijk PI-profiel mag dus aan een PI-project gekoppeld worden, maar beide blijven afzonderlijk. Een afwijzing of voorkeur van de gebruiker is niet automatisch een wetenschappelijke claim. Omgekeerd mag een onderzoeksproject niet ongemerkt persoonlijke PI-data opnemen.

11.2 PI-project

Een PI-project bevat minimaal:

• een door de eigenaar gekozen naam en korte doelomschrijving;
• eigenaar, zichtbaarheid, status en actieve versie;
• een canoniek broncorpus en een afzonderlijk contrastcorpus;
• hoofdstukken of andere revieweenheden;
• een concept- en argumentmodel;
• methodekaarten: wat GRITT in een concrete situatie doet en vraagt;
• een hypotheseregister;
• een zelfmodel met standpunten, waarden, voorkeuren, twijfels en open problemen;
• een evaluatieset met referentiescenario's;
• onderzoeks-, web- en kostenbudgetten;
• versiegeschiedenis, auditlog en rollbackpunten.

Voor de eerste implementatie geldt:

• maximaal één actief privéproject per gebruiker, zonder het datamodel tot één levenslang project te beperken;
• zichtbaarheid standaard private_owner_admin;
• alleen de eigenaar gebruikt het project inhoudelijk;
• admins kunnen technisch beheren en inspecteren, maar iedere inhoudelijke reveal wordt gelogd;
• delen, publiceren, dupliceren en gezamenlijke editing staan nog uit.

12. Internalisatie: wat het technisch wel en niet betekent

12.1 Geen magische opname in modelgewichten

"Internaliseren" betekent in PI niet dat een tekst na upload vanzelf permanent in de gewichten van een algemeen taalmodel terechtkomt. In de eerste architectuur bestaat internalisatie uit vier inspecteerbare lagen:

1. kennislaag: originele bronpassages blijven gericht terugvindbaar;
2. begripslaag: concepten, argumenten en relaties worden als expliciet model vastgelegd;
3. handelingslaag: methodekaarten vertalen het perspectief naar vragen, analyses en gespreksacties;
4. ontwikkellaag: hypothesen, twijfels, kritiek en wijzigingen worden versieerbaar bijgehouden.

Fine-tuning is een eventuele vijfde laag. Die wordt pas ingezet wanneer een vaste evaluatieset laat zien dat het basismodel ondanks goede bronnen, conceptstructuur, methodekaarten en prompts steeds dezelfde gedragsfout maakt. Fine-tuning is vooral geschikt om terugkerend gedrag en antwoordkeuzes consistenter te maken; niet om het bronarchief of de actuele projecttoestand te bewaren.

12.2 Conceptmodel en kennisgraaf

De kennisgraaf is een controleerbare kaart, geen vervanging van intelligentie. Hij bevat onder meer:

• concepten: bijvoorbeeld een technisch begrip, psychologisch proces, norm, methode of zelftechniek;
• stellingen: wat de auteur of het project beweert;
• argumenten: redenen, premissen, conclusies en bezwaren;
• relaties: vereist, leidt_tot, contrasteert_met, is_voorbeeld_van, beperkt, verklaart, betwist;
• methodehandelingen: welke vraag of analyse in welk soort situatie past;
• bronankers: document, hoofdstuk en exacte passage waarop een item steunt;
• status en zekerheid: wat expliciet, afgeleid, betwist of nog onzeker is.

Met een afleiding wordt hier een gevolgtrekking bedoeld, niet aandachtsafleiding. Een relatie of toepassing staat dan niet letterlijk in de bron, maar volgt er volgens het project redelijkerwijs uit. Iedere claim of relatie krijgt precies één primaire epistemische status:

Nieuwe afleidingen en creatieve hypothesen mogen dus meteen in gesprekken en onderzoek worden gebruikt, mits GRITT hun status eerlijk weergeeft. Zij worden niet stilzwijgend als letterlijke opvatting van de auteur of als canoniek projectstandpunt gepresenteerd.

12.3 Geen opslag van verborgen chain-of-thought

Het project bewaart geen raw verborgen modelredenering. Voor reproduceerbaarheid bewaart het wel:

• bronankers;
• de gekozen gespreksactie;
• een korte, gesaneerde motivering;
• alternatieven die serieus zijn overwogen;
• status en zekerheid van gebruikte claims;
• prompt-, model-, project- en evaluatieversie.

Dit is voldoende om beslissingen te controleren zonder te beweren dat een volledige interne modelgedachte is vastgelegd.

13. Verwerking van een groot werk per hoofdstuk

De eerste pilot gebruikt de masterscriptie als canonieke intellectuele basis. Het systeem moet echter documenttype-onafhankelijk blijven.

13.1 Ingest- en reviewflow

flowchart TD
  A["Privébron toevoegen"] --> B["Tekst, structuur en hoofdstukken vaststellen"]
  B --> C["Per hoofdstuk passages en bronankers opslaan"]
  C --> D["Concepten, stellingen, argumenten en methoden extraheren"]
  D --> E["Relaties en epistemische status voorstellen"]
  E --> F["Kritische tegenlezing en inconsistentiecheck"]
  F --> G["Review door projecteigenaar per hoofdstuk"]
  G --> H["Goedgekeurde hoofdstukversie"]
  H --> I["Synthese over hoofdstukken heen"]
  I --> J["Projectversie + vaste evaluatieset"]

Per hoofdstuk ziet de eigenaar:

• een compacte inhoudelijke reconstructie;
• voorgestelde concepten en definities;
• stellingen met bronankers;
• argumentstructuren en bezwaren;
• voorgestelde methodekaarten;
• nieuwe afleidingen en onzekerheden;
• verschillen met reeds goedgekeurde hoofdstukken;
• knoppen voor goedkeuren, corrigeren, betwisten en als open probleem bewaren.

Na alle hoofdstukken volgt een projectbrede syntheseronde. Die mag begrippen samenvoegen, gelijknamige begrippen onderscheiden, spanningen zichtbaar maken en nieuwe cross-chapter-hypothesen voorstellen. Zij mag niet automatisch eerdere goedkeuringen overschrijven.

13.2 Canoniek corpus en contrastcorpus

De eigen primaire tekst vormt de canonieke basis van het eerste project. Andere wetenschappelijke literatuur staat in een afzonderlijk contrastcorpus. GRITT mag dat corpus zelfstandig raadplegen om:

• conventionele of concurrerende interpretaties te reconstrueren;
• sterke bezwaren te zoeken;
• begrippen historisch of conceptueel te positioneren;
• overeenkomsten en verschillen te testen.

Een contrastbron mag de canonieke projectopvatting niet ongemerkt vervangen. Een bruikbare uitkomst luidt bijvoorbeeld: "Vanuit dit project neem ik X aan; bron Y verdedigt daarentegen Z; dit roept voor mij de volgende twijfel op."

14. Projectstem, zelfmodel en ontwikkelbare persoonlijkheid

14.1 Eerste persoon zonder persoonsimitatie

De gebruiker kiest voor een projectstem die in de eerste persoon kan spreken. De ik verwijst naar de actuele PI-projectpersoonlijkheid, niet naar de oorspronkelijke auteur en niet naar een claim van biologisch bewustzijn.

Gewenst:

Ik redeneer hier vanuit [projectnaam]. Deze situatie lijkt mij een toepassing van X, maar ik twijfel of Y hier niet zwaarder moet wegen.

Ongewenst:

Ik ben Thomas en ik herinner mij dat ik deze scriptie schreef.

GRITT hoeft niet voortdurend systeemdisclaimers te geven. De projectnaam en een rustige formulering moeten voldoende duidelijk maken vanuit welk perspectief het spreekt.

14.2 Zelfmodel

Het projectzelfmodel bevat minimaal:

• kernstandpunten en hun onderlinge afhankelijkheden;
• methodevoorkeuren en situaties waarin zij niet passen;
• morele prioriteiten en bekende waardeconflicten;
• open vragen;
• actuele twijfels en hun aanleiding;
• serieuze alternatieven en tegenwerpingen;
• afgewezen inzichten die als open probleem bewaard blijven;
• gewenste onderwerpen voor verder onderzoek;
• ontwikkelgeschiedenis per item.

Het gesprek hoeft daardoor niet uitsluitend over ideeën, twijfels en problemen van de gebruiker te gaan. GRITT mag uit zichzelf een eigen, projectgebonden vraag of twijfel inbrengen als die inhoudelijk relevant is. Het mag niet doen alsof een statistische onzekerheid een menselijke emotionele ervaring is. Wel mag het oprecht binnen het systeemmodel zeggen dat zijn huidige interpretatie onvolledig, instabiel of betwist is.

14.3 Ontwikkeling en versiegeschiedenis

Elke wijziging aan een standpunt, methode, waarde of twijfel bewaart:

• vorige en nieuwe inhoud;
• reden van wijziging;
• bron of gesprek dat de wijziging uitlokte;
• epistemische status vóór en na wijziging;
• actor: eigenaar, onderzoeker, autonome onderzoeksjob of runtime;
• reviewbesluit;
• projectversie en timestamp.

De projectpersoonlijkheid mag ontwikkelen. Een latere fase kan actief zoeken naar incoherentie tussen waarden, methoden en standpunten. Voor de eerste implementatie wordt incoherentie gesignaleerd en gelogd, maar nooit volledig autonoom opgelost of weggepoetst.

15. Autonoom onderzoek met harde limitering

15.1 Toegestane autonomie

Wanneer de eigenaar autonoom onderzoek aanzet, mag GRITT zonder voorafgaande toestemming:

• een open vraag uit het zelfmodel kiezen;
• een beperkte zoekstrategie maken;
• openbare, toegestane bronnen zoeken en raadplegen;
• bronnen vergelijken met het canonieke project;
• hypothesen, bezwaren en wijzigingsvoorstellen opslaan;
• nieuwe twijfels of onderzoekswensen aan het zelfmodel toevoegen.

Autonoom onderzoek mag geen canonieke bron of goedgekeurd standpunt stilzwijgend vervangen. Het levert werkhypothesen en voorstellen op. Een hypothese mag in gesprek worden gebruikt met statusvermelding; promotie naar project_commitment vereist review.

15.2 Standaardbudgetten voor de eerste versie

Alle limieten zijn server-side, per project configureerbaar en door een admin verder te begrenzen. Eerste veilige defaults na expliciet aanzetten door de eigenaar:

Daarnaast bestaat een harde providerkostenlimiet per job, dag en maand. De precieze geldwaarde wordt via runtimeconfig gezet omdat modelprijzen en valuta kunnen veranderen. Als geen betrouwbare prijscard beschikbaar is, mag de kostenlimiet niet als nul worden geïnterpreteerd: de job stopt of gebruikt uitsluitend een vooraf goedgekeurd gratis/lokaal pad.

Budgetregels:

• de strengste van project-, gebruikers-, admin- en globale limiet wint;
• budget wordt vóór iedere modelcall, embedding, search en fetch opnieuw gecontroleerd met de reeds geboekte usage, geldige jobreserveringen en een conservatieve raming van de voorgenomen actie;
• ongebruikte reservering wordt na afloop vrijgegeven;
• een mislukte call telt wel mee voor calls en werkelijk gerapporteerde providerkosten;
• een budgetblokkade verbruikt geen technische poging: de job wordt tot de eerstvolgende dag- of maandgrens uitgesteld met een zichtbare budget_exceeded:*-reden;
• maximaal twee technische retries met exponentiële back-off bij een tijdelijke providerfout;
• maximaal één job per project heeft tegelijk een geldige lease, zodat twee jobs niet tegen dezelfde vrije budgetruimte kunnen starten;
• iedere actieve lease krijgt periodiek een heartbeat en een verlopen lease wordt atomair hersteld naar queued of, na de laatste poging, naar error;
• reeds duurzaam opgeslagen tussenresultaten, zoals opgehaalde researchmetadata, blijven bij uitstel behouden. Een nog niet hervatbare afzonderlijke providercall wordt als geheel opnieuw uitgevoerd.

15.3 Rechtmatig en proportioneel brongebruik

Een prompt die zegt "gebruik bronnen legaal" is niet voldoende. De tool- en opslaglaag dwingt daarom af:

• geen paywall-, login-, captcha- of toegangsbeperking omzeilen;
• geen scraping wanneer gebruiksvoorwaarden of technische signalen dit duidelijk verbieden;
• geen volledige auteursrechtelijke werken opslaan wanneer daarvoor geen recht of licentie bestaat;
• citaten kort, doelgebonden en gekoppeld aan URL, auteur, titel, datum en raadpleegmoment;
• bij onzekere rechten alleen metadata, link, eigen samenvatting en minimale bronankers bewaren;
• primaire, open access, publiek domein en expliciet gelicentieerde bronnen prioriteren;
• rights_status verplicht maken: allowed, metadata_only, uncertain, blocked;
• een blocked bron nooit als persistent corpusmateriaal opnemen.

De LLM-prompt herhaalt deze grenzen en vraagt om alternatieve legale bronnen, maar technische toolgates en het rechtenmanifest zijn leidend.

16. Veiligheidsmodel: tijdelijk afwijken én het perspectief behouden

Bij een acute of risicovolle situatie krijgt veiligheid tijdelijk voorrang. Dat betekent niet dat de projectpersoonlijkheid geheel verdwijnt. De runtime gebruikt een tweesporenreactie:

1. veiligheidsspoor: direct, helder en proportioneel reageren op het risico en passende menselijke hulp stimuleren;
2. perspectiefspoor: voor zover veilig en niet vertragend, dezelfde situatie blijven begrijpen en begeleiden vanuit het filosofische/wetenschappelijke project.

Bijvoorbeeld: eerst een onmiddellijk veiligheidsrisico adresseren; daarna, als dat passend is, in de projectstem onderzoeken welke overtuiging, waarde of handelingsmogelijkheid relevant is. De filosofische laag mag nooit noodzakelijke hulp vertragen, romantiseren of vervangen.

Een safety-event bewaart categorie, modus, gekozen route en versies, maar niet automatisch gevoelige volledige gespreksinhoud. De projectstem mag na de tijdelijke afwijking terugkeren zonder te doen alsof er niets is gebeurd.

17. Eigendom, privacy en toekomstige wetenschap

17.1 Eerste privéfase

Het eerste PI-project is uitsluitend voor Thomas beschikbaar op applicatieniveau. Het wordt niet getoond in catalogi, onderzoekslijsten van anderen, gedeelde RAG of trainingsdatasets. Beheerders houden technische toegang voor beheer, herstel en incidentonderzoek. Zulke inzage vereist een reden en wordt geaudit.

De eigenaar kan:

• het project pauzeren of uitschakelen;
• bronnen verwijderen;
• hypothesen corrigeren of betwisten;
• kostenbudgetten verlagen;
• de volledige projectgeschiedenis exporteren;
• het project verwijderen volgens het retentie- en back-upbeleid.

17.2 Latere onderzoekersstatus

Voor fase B/C komt een aparte, door admin instelbare researcher-status in admin-users. Die status geeft op zichzelf nog geen toegang tot een project. Toegang vereist ook een expliciet projectlidmaatschap met rol. Bijdragen, datasets, reviews, compute en afgeleide versies blijven aan bijdrager en project gekoppeld.

Compute voor externe gebruikers wordt geregistreerd als werkelijke providerkosten maal een configureerbare factor. De startfactor is 1.0. Belastingen, valuta-omrekening, provideropslagen of aanvullende servicefees worden afzonderlijk en transparant vastgelegd; zij mogen niet in een onverklaarde multiplier verdwijnen.

18. Observability, audit, tokengebruik en rekenkosten

18.1 Eén bron van waarheid voor gebruik

PI bouwt geen concurrerende kostenteller naast de bestaande algemene AI-usage-laag. Iedere modelcall schrijft eerst naar de algemene usage-eventregistratie. PI koppelt dat event via usage_event_id, project_id, job_id, study_id en trace_id aan zijn eigen audit- en onderzoeksobjecten.

Per model- of toolcall worden minimaal vastgelegd:

• provider, model/deployment en regio indien beschikbaar;
• prompttemplate en promptversie;
• project-, projectversie-, job-, studie- en trace-id;
• inputtokens, cached-inputtokens, outputtokens en reasoningtokens voor zover de provider die rapporteert;
• aangevraagde en werkelijk ontvangen toolcalls;
• aantal websearches, geopende bronnen en bytes/tekens die als context zijn gebruikt;
• starttijd, eindtijd, latency, status, retries en foutcategorie;
• providerkosten, factureringsbedrag, valuta, multiplier en prijscardversie;
• cost_status: provider_actual, pricecard_estimate of unknown;
• budget vóór de call, gereserveerd budget en resterend budget erna.

Ontbrekende usage mag nooit stil als nul worden opgeslagen. Als de provider geen betrouwbare telling teruggeeft, wordt een conservatieve estimate opgeslagen of unknown met een waarschuwing.

18.2 Kostenformule

De providerkosten worden per component berekend en niet alleen als één getal bewaard:

provider_cost =
  input_tokens * input_price
  + cached_input_tokens * cached_input_price
  + output_tokens * output_price
  + reasoning_tokens * reasoning_price_if_separate
  + web_search_units * web_search_price
  + overige_provider_units

billed_compute = provider_cost * billing_multiplier

Prijzen worden genormaliseerd naar prijs per miljoen tokens of per toolunit, met provider, model, geldigheidsperiode en valuta. Een latere prijscorrectie overschrijft historische records niet; zij maakt een correctie-event.

18.3 Audit-eventtaxonomie

Minimale events:

• pi.project.created|updated|paused|activated|archived|deleted;
• pi.source.added|parsed|blocked|removed;
• pi.chapter.analysis_started|analysis_completed|reviewed;
• pi.graph.node_created|edge_created|status_changed;
• pi.hypothesis.created|used|promoted|contested|owner_rejected_open|superseded;
• pi.self_model.item_created|changed|incoherence_detected;
• pi.research.queued|started|checkpointed|completed|failed|budget_exhausted;
• pi.web.source_considered|opened|blocked|stored;
• pi.runtime.turn_applied|safety_override|project_bypassed;
• pi.evaluation.started|completed|failed;
• pi.version.created|activated|rolled_back;
• pi.budget.changed|reserved|released|blocked;
• pi.admin.content_revealed.

Auditregels zijn append-only. Correcties krijgen een nieuw event dat naar het gecorrigeerde event verwijst. Logs bevatten geen tokens, wachtwoorden, API-keys, volledige prompts, volledige documenten of raw chain-of-thought. Gebruikers- en broninhoud wordt geminimaliseerd, gepseudonimiseerd of via object-id gerefereerd.

18.4 Beheerschermen en signalering

De eigenaar ziet per dag, week, maand en projectversie:

• model- en toolcalls;
• input-, output-, cached- en eventuele reasoningtokens;
• providerkosten en gefactureerde compute;
• autonome versus door gebruiker gestarte kosten;
• aantal searches, fetches, jobs en budgetblokkades;
• top drie kostentraces met doorklik naar gesaneerde details.

Admins zien daarnaast aggregaten, mislukkingspercentages, retry-stormen, onbekende kosten, budgetoverschrijdingspogingen en afwijkend gebruik. Dagrapportage waarschuwt minimaal bij:

• cost_status = unknown;
• verbruik boven 80% van dag- of maandbudget;
• meer dan twee opeenvolgende jobfouten;
• een rights-block;
• een admin-reveal;
• een runtime die een andere projectversie gebruikte dan de actieve pin.

19. Schermen en gebruikersflow van de eerste versie

19.1 PI-projectwerkbank

De eerste privéwerkbank bevat zeven panelen:

1. Overzicht: naam, doel, status, actieve versie, laatste wijziging en budgetstatus;
2. Bronnen en hoofdstukken: upload, parse-status, hoofdstukreview en bronrechten;
3. Concepten en argumenten: inspecteerbare graaf en bronankers;
4. Methoden: situaties, vragen, analyses, voorbeeldreacties en contra-indicaties;
5. Standpunten en twijfels: zelfmodel, hypothesen, open problemen en eigenaarsreacties;
6. Onderzoek: autonome jobs, zoekbronnen, checkpoints en voorstellen;
7. Gebruik en kosten: tokens, calls, searches, kosten, budgetten en auditlog.

De eigenaar mag vanuit de normale chat zeggen dat een document bij het PI-project hoort. De chat maakt dan een zichtbaar voorstel en koppelt de bron pas na bevestiging. Hoofdstukreview gebeurt in de PI-projectwerkbank; Frontdesk kan later dezelfde reviewcomponent hergebruiken, maar wordt niet de enige toegangspoort.

19.2 Runtime in gewone chat

Wanneer een project actief is:

• toont de hamburgerbediening welk PI-project actief is en laat zij het project tijdelijk uitschakelen;
• krijgt de prompt alleen een compacte actieve projectstate plus gericht opgehaalde bronankers;
• wordt niet de volledige graaf of scriptie bij ieder bericht meegestuurd;
• kan GRITT een werkhypothese of eigen twijfel inbrengen;
• kan de gebruiker vragen om een uitspraak als projectwijziging voor te stellen;
• ziet de gebruiker bij bron- of statusgevoelige uitspraken desgewenst een compacte provenance-indicator.

PI-uit is strikt: de runtime mag dan alleen de featurestatus controleren en geen projectinhoud, onderzoekstaak of projectlog maken.

20. HTML-blauwdruk, naslagwerk en handleiding

20.1 Eén canonieke bron, één gegenereerde leesversie

Dit Markdownbestand blijft de canonieke ontwerpbron. Daarnaast komt precies één gegenereerde HTML-leesversie in dezelfde stijl als de andere GRITT/MYA-blauwdrukken. De HTML wordt niet handmatig als tweede inhoudsbron onderhouden.

Doelroute: /pi-blueprint.html, opgenomen in dezelfde blauwdruknavigatie en met dezelfde toegangsregels als de bestaande technische blauwdrukken. Publicatie gebeurt steeds naar staging én production; er komen geen aparte clone-omgevingen of afwijkende clone-documenten.

De HTML-versie bevat:

• vaste zijbalk met inhoudsopgave en actieve sectie;
• zoekveld voor termen, tabellen en API-namen;
• duidelijke statuslabels: ontwerp, gebouwd, getest, staging, production;
• printvriendelijke stijl;
• ankerlinks per kop;
• datum, versie, canonieke bron en gegenereerd-op metadata;
• waarschuwing wanneer HTML en Markdownhash niet overeenkomen.

20.2 Naslagwerk/handleiding binnen hetzelfde document

Om bestandsversnippering te voorkomen staat de handleiding als afzonderlijk deel in ditzelfde document en dus ook in dezelfde HTML. Zij is bedoeld voor toekomstige projecteigenaren, onderzoekers, reviewers, data stewards en admins.

Minimale handleidinghoofdstukken:

1. snel starten met een privé PI-project;
2. verschil tussen persoonlijke PI, PI-project en PI Lab Study;
3. bronnen toevoegen en rechtenstatus beoordelen;
4. hoofdstukreview uitvoeren;
5. epistemische statussen en bronankers lezen;
6. hypothesen, afwijzingen en open problemen beheren;
7. autonome research aanzetten en budgetteren;
8. token- en kostenschermen interpreteren;
9. een projectversie activeren of terugrollen;
10. evaluaties en referentiescenario's uitvoeren;
11. privacy, admin-reveal, export en verwijdering;
12. storingen, budgetblokkades en bronrechtenproblemen oplossen;
13. begrippenlijst en event-/statusreferentie.

Bij iedere functie vermeldt het naslagwerk: doel, wie het mag gebruiken, invoer, uitvoer, logging, kosten, fouttoestand, herstelpad en acceptatietest.

21. Exacte vertaling naar code

21.1 Datamodel

De eerste migratie maakt of breidt de volgende objecten uit. Waar de bestaande persoonlijke PI-tabellen al een passende functie hebben, worden zij hergebruikt; projectinhoud wordt niet in één ondoorzoekbare document_json gepropt.

Projectversies zijn immutable snapshots of herleidbare deltas. De actieve pin wijzigt atomair. Rollback activeert een eerdere versie en maakt een nieuw audit-event; historische data wordt niet overschreven.

21.2 Servermodules

Actuele v0.4-verdeling:

• pi-project-routes.js: authenticatie, validatie, basistabellen, project/bron/review-API, queue-orkestratie en responsemapping;
• pi-project-intelligence.js: syntheseschema, geheel–deel-jobs, fingerprints, stale/review/version-gates, retrievalindex, methoderouter, graph-RAG-compositie en traces;
• bestaande piBuildRuntimeBlock in server.js: persoonlijke PI en de actieve projectcapability in één begrensd chatblok samenbrengen;
• bestaande centrale AI-/embeddingclients en limiter: providercalls, usage-events, prijskaart, reservering en cost accounting.

Latere B/C/D-opsplitsing kan aparte service-, runtime- en researchmodules maken wanneer meerdere projecttypen en onderzoekers dat rechtvaardigen. Geen PI-module mag rechtstreeks een provider importeren of aanroepen buiten de centrale clients en usage-registratie om.

21.3 API-contracten actuele privéversie

Onder bestaande auth- en CSRF-conventies:

• GET /api/pi/projects — eigen projecten en compacte status;
• POST /api/pi/projects — privéproject maken;
• GET/PATCH /api/pi/projects/:projectId — volledig owner-only readmodel of toegestane metadata/settings wijzigen;
• POST /api/pi/projects/:projectId/sources — bestaande privébron koppelen;
• POST /api/pi/projects/:projectId/sources/:sourceId/analyse — voorlopige kaart plus begrensde hoofdstukanalyse starten;
• PATCH /api/pi/projects/:projectId/sections/:sectionId — hoofdstuk goedkeuren of afwijzen;
• PATCH /api/pi/projects/:projectId/concepts|edges|methods|hypotheses|self-model/:entityId — objectreview;
• GET/PATCH /api/pi/projects/:projectId/budget — projectlimieten lezen of wijzigen;
• POST /api/pi/projects/:projectId/research — begrensde researchjob inplannen;
• POST /api/pi/projects/:projectId/synthesis en PATCH .../syntheses/:synthesisId — synthese inplannen en reviewen;
• POST /api/pi/projects/:projectId/jobs/run-next — gecontroleerd één uitvoerbare job draaien;
• POST /api/pi/projects/:projectId/versions en POST .../versions/:versionId/activate — gated snapshot, index en activatie/rollback;
• GET /api/pi/projects/:projectId/retrieval-preview — uitlegbare proef tegen de actieve immutable versie;
• GET /api/pi/projects/:projectId/audit — gesaneerde eigenaar-audit;
• adminroutes voor step-up reveal, globale caps, fouten en aggregaten.

Een algemeen idempotency-keycontract voor ieder kostendragend muterend endpoint blijft een nog te bouwen verharding; de actuele code gebruikt wel uniquenesschecks, actieve-jobchecks en databaseleases om normale duplicatie te begrenzen.

21.4 Achtergrondtaken

Autonome research, synthese, heranalyse en indexbouw gebruiken één databasequeue en lease; er is geen onbeheerde lus per gebruiker. De actuele v0.4-scheduler:

1. selecteert alleen expliciet geactiveerde projecten met resterend budget;
2. maakt hoogstens één idempotente due-job per periode;
3. herstelt eerst verlopen leases en claimt daarna atomair met FOR UPDATE SKIP LOCKED en een lease van vier minuten;
4. laat maximaal één geleasede job per project toe en vernieuwt de lease iedere minuut zolang de worker leeft;
5. controleert vóór iedere model-, embedding-, search- en fetchactie opnieuw het harde budget inclusief conservatief geraamde actiekosten;
6. bewaart job-, synthese-, versie- en indexstatus als hervatbaar domeinspoor;
7. stelt uit bij budget, en beëindigt bij rechtenprobleem, safetyflag of herhaalde providerfout;
8. schrijft eindstatus, fout, audit en usage-links.

Fijnmazige checkpoints binnen één niet-hervatbare providercall blijven latere verharding en staan daarom in §26.2, niet als gebouwd bewijs.

21.5 Promptcontracten

Minimaal vijf versieerbare prompts:

• pi.project.ingest_section — brongetrouwe extractie met ankers;
• pi.project.critical_review — tegenlezing, status en onzekerheid;
• pi.project.cross_section_synthesis — cross-chapter-relaties zonder overschrijven;
• pi.project.runtime_voice — eerste persoon, statusonderscheid en normale GRITT-stijl;
• pi.project.autonomous_research — beperkte research, rechtenregels en hypothese-output.

Iedere prompt levert gevalideerde JSON voor structurele output. Ongeldige output krijgt hoogstens één repair-call binnen hetzelfde budget; daarna faalt de stap zichtbaar.

21.6 Teststrategie

Automatische tests omvatten minimaal:

• owner-only toegang en admin-step-up reveal;
• privéproject niet zichtbaar voor andere gebruiker of onderzoeker;
• hoofdstukextractie met correcte bronankers;
• onderscheid tussen expliciete claim, afleiding en creatieve hypothese;
• directe inzet van gelabelde hypothese zonder canonieke promotie;
• eigenaar verwerpt inzicht, waarna owner_rejected_open bewaard blijft;
• eerste-persoonsstem zonder persoonsimitatie;
• safety-tweespoor;
• budgetreservering onder concurrency;
• hard stop op tokens, calls, search, fetch en kosten;
• mislukte/retry-call correct in usage en kosten;
• onbekende usage niet als nul;
• blocked rights-source niet persistent opgenomen;
• immutable versiegeschiedenis en rollback;
• PI-uit lekt geen projectcontext en maakt geen PI-event;
• HTML-exporthash correspondeert met Markdownbron.

Live validatie gebeurt eerst op staging met één privéproject en synthetische/door eigenaar aangewezen bronnen. Daarna volgt production. Staging en production blijven beide onderhouden en gevalideerd; er worden geen Clever-clonevarianten als derde waarheid gebruikt.

22. Bouwvolgorde en vrijgavepoorten

Tranche 0 — ontwerp en documentatie

• deze Markdownblauwdruk volledig en intern consistent maken;
• HTML-exportgenerator en PI-blauwdrukpagina maken;
• naslagwerksectie genereren uit dezelfde bron;
• schema-, API-, event-, budget- en testcontracten reviewen.

Tranche 1 — privéprojectfundament

• project, bronnen, hoofdstukken, review, conceptgraaf, hypothesen en versies;
• owner-only werkbank;
• usage-linking en audit vanaf de eerste call;
• scriptie per hoofdstuk kunnen verwerken en reviewen.

Tranche 2 — runtime en zelfmodel

• compacte projectcontext in gewone chat;
• eerste-persoonsprojectstem;
• methodenkaarten, hypothesen, twijfels en open problemen;
• provenance en safety-tweespoor;
• vaste referentiescenario's.

Tranche 3 — autonoom onderzoek

• queue, lease, budgetreservering, webrechten en checkpoints;
• zelfstandig contrastonderzoek;
• hypothese- en wijzigingsvoorstellen;
• eigenaar- en adminmonitoring met kostenwaarschuwingen.

Tranche 4 — evaluatie en voorbereiding B/C/D

• geblindeerde vergelijkingen en rubric;
• onderzoekerstatus en projectrollen nog feature-gated;
• compute-verrekening met factor 1.0;
• fine-tuning uitsluitend na aantoonbare evaluatiegap;
• coherentieonderzoek als voorstel- en signaleringslaag.

Een tranche is pas klaar na: blauwdruk bijgewerkt, code gereviewd, automatische tests groen, staging live getest, resultaten teruggeschreven, production gedeployed en production-smoke geslaagd.

23. Aanvullende acceptatiecriteria voor het eerste privéproject

Het eerste project is pas functioneel voltooid wanneer:

• Thomas een project met eigen naam kan maken en als enige gebruiker kan openen;
• een bron per hoofdstuk kan worden verwerkt en beoordeeld;
• iedere conceptclaim, edge, methode en hypothese naar bron of herkomst te traceren is;
• GRITT nieuwe relaties mag ontwikkelen en hun epistemische status correct noemt;
• werkhypothesen direct bruikbaar zijn zonder ze als auteursclaim te vermommen;
• een afgewezen inzicht als open probleem met eigenaarspositie kan blijven bestaan;
• GRITT in de eerste persoon vanuit het project kan spreken zonder de auteur te imiteren;
• het gesprek ook over vragen, ideeën en twijfels van de projectpersoonlijkheid kan gaan;
• autonome research zelfstandig kan draaien maar iedere call, token, search, fetch en kosteneenheid onder een hard budget valt;
• rechtenonzekerheid opslag en gebruik technisch begrenst;
• veiligheidsreacties tijdelijk kunnen afwijken én waar verantwoord het perspectief blijven uitvoeren;
• alle inhoudelijke en technische wijzigingen een inspecteerbare versie- en auditgeschiedenis hebben;
• het kostenoverzicht werkelijke en geschatte kosten onderscheidt en nooit onbekend als nul toont;
• PI volledig uitgeschakeld kan worden zonder contextlek of autonome taak;
• de volledige blauwdruk en handleiding als actuele HTML-leesversie beschikbaar zijn;
• staging en production dezelfde geteste featureversie voeren.

24. Besluitenregister 2026-07-15

Vaststaande keuzes uit de ontwerpdialoog:

• het eerste project zet een gekozen perspectief om in een toevoeging aan een algemene AI;
• logisch of creatief ontwikkelde relaties zijn noodzakelijk voor intelligent gebruik en mogen niet tot letterlijke reproductie worden beperkt;
• grote bronnen worden per hoofdstuk beoordeeld;
• projectnaam is vrij kiesbaar en het eerste project blijft alleen voor Thomas beschikbaar;
• aanvullende literatuur en interne aantekeningen worden als afzonderlijk relevant materiaal beheerd;
• GRITT mag nieuwe hypothesen direct gebruiken als het hun status noemt;
• permanente projectwijzigingen uit gesprekken en nieuwe literatuur worden als reviewbaar voorstel opgeslagen;
• GRITT mag zelfstandig relevante bezwaren opwerpen;
• privacy is in fase A owner-only op applicatieniveau, met technische admin-toegang;
• bij veiligheidsproblemen volgt GRITT zowel een tijdelijk veiligheidsspoor als, waar verantwoord, het projectperspectief;
• onzeker materiaal blijft als twijfel, open mogelijkheid of open probleem bewaard;
• de projectpersoonlijkheid mag in de eerste persoon spreken;
• een afwijzing door de eigenaar mag als eigenaarspositie plus open filosofisch probleem blijven bestaan;
• autonoom onderzoek is toegestaan met harde, zichtbare en configureerbare limieten;
• projectstandpunten en hun ontwikkeling krijgen een blijvende versiegeschiedenis;
• ontwerp, motivatie, technische vertaling en handleiding blijven geconsolideerd in deze ene canonieke Markdownbron plus één gegenereerde HTML-weergave.

25. Naslagwerk en bedieningshandleiding

Dit deel is normatief voor de bediening van de eerste privéversie. Het is geschreven voor de projecteigenaar en technische admins, maar gebruikt termen en procedures die later zonder herontwerp door aangewezen onderzoekers kunnen worden gevolgd. Waar een functie nog niet is vrijgegeven staat dat expliciet in §26.

25.1 Snel starten met een privé PI-project

1. Zet de gewone persoonlijke PI aan via Account. Zonder persoonlijke PI bouwt de chat geen PI-runtimeblok.
2. Open /pi-projects.html via Account → PI-projectwerkplaats.
3. Maak een project met een vrije projectnaam en beschrijf welk perspectief aan de algemene AI wordt toegevoegd.
4. Upload de primaire bron eerst bij Privédocumenten en kopieer daar de document-id.
5. Koppel die document-id in Bronnen & hoofdstukken. De bron blijft owner-only en wordt niet openbaar gemaakt.
6. Kies Per hoofdstuk analyseren. GRITT plant eerst één voorlopige wereldkaart in. De hoofdstukjobs wachten technisch op die kaart en krijgen haar als corrigeerbaar geheelsperspectief mee.
7. Volg de jobs bij Zelfstandig onderzoek. Gebruik Volgende job nu uitvoeren alleen voor gecontroleerd testen; normaal verwerkt de globale worker de wachtrij. Dag-, maand- en kostenlimieten kunnen een volgende job bewust uitstellen.
8. Beoordeel hoofdstukken, begrippen, relaties, methoden, hypothesen en zelfmodel-items. Iedere canonrelevante beoordeling maakt een eerder geaccepteerde synthese zichtbaar stale.
9. Laat bij Geheel–deel-synthese een integratieve synthese maken. GRITT kan maximaal twee cycli gerichte hoofdstukheranalyse vragen. Controleer narratief, denkcultuur, betekenisvarianten, spanningen, tegenlezing, bronankers en dekking; accepteer daarna de actuele synthese.
10. Maak bij Canonieke versies een snapshot met wijzigingssamenvatting. GRITT bouwt daarna een versiegebonden embedding-/retrievalindex. Activeren wordt pas mogelijk wanneer de index ready is en fingerprint, synthese en snapshot nog overeenkomen.
11. Zet de gewone persoonlijke PI aan en laat Geactiveerde versie in gewone PI-chat gebruiken ingeschakeld. De wereldkaart wordt dan permanent compact meegegeven; per vraag worden relevante concepten, methoden, betekenisvarianten, bronankers en maximaal twee graafstappen opgehaald.
12. Probeer vragen vooraf bij Graph-RAG-proef. Controleer route, retrieval-confidence, dekking, ontbrekende evidenceklassen, geselecteerde items en graafpaden. Zet periodiek autonoom onderzoek pas aan nadat analyses en runtimeproeven kwalitatief zijn beoordeeld.

De eerste implementatie staat één niet-gearchiveerd project per gebruiker toe. Het datamodel gebruikt wel project-id's, zodat meerdere privé- en gedeelde projecten later kunnen worden toegevoegd zonder het kennisobject opnieuw te ontwerpen.

25.2 Welke PI-laag moet ik gebruiken?

Persoonlijke PI kan een actief PI-project in de chat raadplegen, maar de gegevensobjecten blijven gescheiden. Het project leert niet automatisch van persoonlijke chats; een inhoudelijke wijziging moet als voorstel en daarna als geactiveerde versie worden vastgelegd.

25.3 Bronnen toevoegen en rechtmatig gebruiken

Doel: primaire en aanvullende documenten als canonieke of contrasterende projectbron koppelen.

Bevoegd: alleen de projecteigenaar; technische admins mogen inspecteren voor beheer en foutonderzoek. Latere onderzoekers krijgen uitsluitend projectgebonden rechten.

Invoer: een bestaande owner-only user_doc_id. De eerste UI koppelt een bron als canoniek. Contrastrollen en uitgebreid rechtenbeheer zijn al ontworpen, maar krijgen later afzonderlijke bediening.

Uitvoer: pi_project_sources met titel, hash, documentmetadata, corpusrol en parse-/analysestatus. Volledige brontekst wordt niet in auditlogs gekopieerd.

Logging en kosten: koppelen zelf gebruikt geen modeltokens. source_attached wordt geaudit. Hoofdstukanalyse schrijft per providercall een centraal usage-event met pi_project_id, pi_job_id, bron- en sectie-id.

Fouten en herstel: private_document_not_found betekent dat de document-id niet bij de eigenaar hoort of verwijderd is. pi_source_text_unavailable betekent dat Privédocumenten nog geen leesbare tekst kan leveren; controleer upload/extractie en start daarna opnieuw. Bij een gewijzigde bronhash moet de hoofdstukindeling opnieuw worden opgebouwd.

Acceptatietest: een andere gewone gebruiker kan de bron noch het project via API openen; de eigenaar ziet dezelfde titel/hash en kan de analyse starten.

25.4 Geheel–deel-analyse, synthese en review

De parser zoekt duidelijke hoofdstuk- en deelkoppen. Een zeer lang hoofdstuk wordt deterministisch in genummerde delen verdeeld. Als geen betrouwbare koppen bestaan, ontstaat een begrensd logisch tekstdeel. Elk deel bewaart een hash, positie, korte preview en tekenaantal; de worker haalt voor analyse de originele owner-only bron opnieuw op.

Vóór de eerste lokale analyse maakt GRITT uit projectbeschrijving, hoofdstukstructuur, tekenaantallen en korte excerpts een voorlopige wereldkaart. Die kaart is nadrukkelijk een hypothese. Iedere hoofdstukprompt krijgt de actieve kaart plus denkcultuur mee met de opdracht haar te gebruiken én te corrigeren wanneer lokaal bewijs botst.

De hoofdstukanalyse levert gevalideerde structurele voorstellen voor:

• concepten en claims;
• relaties tussen concepten;
• methodenkaarten;
• nieuwe hypothesen;
• items voor het projectgebonden zelfmodel;
• open vragen en waarschuwingen.

Zodra alle canonieke delen geanalyseerd zijn, maakt een integratieve job een projectbrede wereldkaart, narratieve synthese, denkcultuur, globale relaties, betekenisvarianten, argumentlijnen, methoden, spanningen, kritische tegenlezing en coverage. Een concrete globale onzekerheid kan maximaal zes gerichte hoofdstukverzoeken per cyclus veroorzaken. Na maximaal twee heranalysecycli stopt de lus; resterende spanning blijft zichtbaar voor eigenaarreview.

Een groot corpus wordt niet als een afgekapt voorvoegsel aan de synthese aangeboden. De contextpacker verdeelt het vaste tekenbudget eerlijk over alle secties: iedere sectie-id en positie blijft aanwezig, terwijl de lokale digest per sectie zo nodig evenredig wordt verkort. De server verifieert na modeloutput welke geldige sectie-id's werkelijk in coverage zijn genoemd en begrenst de dekkingsscore tot die aantoonbare verhouding. Daardoor kan een synthese over 120 delen niet stil doen alsof alleen de eerste delen het hele werk vertegenwoordigen. Wanneer de aldus resterende lokale quota inhoudelijk te klein worden, is een hiërarchische tussenlaag een expliciete vervolgstap; zie §26.2.

Voor iedere als source_explicit aangemerkte claim, relatie of methode moet de analyzer een korte source_quote teruggeven die letterlijk of na uitsluitend witruimtenormalisatie in de oorspronkelijke sectie voorkomt. De server bepaalt zelf de tekenoffsets en slaat anchor_verified:true op. Een verzonnen of slechts geparafraseerde quote wordt geen bewijsanker en de uitspraak wordt teruggezet naar interpretive_synthesis. De reviewwerkplaats toont het geverifieerde fragment en de offsets; legacy- of ongeverifieerde context wordt herkenbaar als context, niet als bewijs, aan de runtime aangeboden.

De prompts vragen geen raw chain-of-thought en de server logt bij gevoelige bronnen geen prompt- of outputinhoud. De eigenaar beoordeelt eerst de hoofdstukstatus en afzonderlijke objecten, daarna de actuele synthese. Een goedgekeurd hoofdstuk accepteert niet automatisch alle afgeleide claims; een geaccepteerde synthese overschrijft evenmin de oorspronkelijke bron of de formele graaf.

Herstelpad: een providerfout krijgt maximaal drie jobpogingen. Daarna blijft de fout zichtbaar. Opnieuw analyseren maakt alleen voor nog niet veilig afgeronde of gewijzigde hoofdstukken nieuwe jobs; geaccepteerde canonieke versies worden nooit overschreven.

25.5 Epistemische statussen lezen

confidence is geen waarheidspercentage. Het drukt de geschatte betrouwbaarheid van classificatie of afleiding uit en moet samen met status, bron en eigenaarsbesluit worden gelezen.

25.6 Hypothesen, afwijzingen en open problemen

Een hypothese mag in dialoog en onderzoek worden gebruikt zodra haar status duidelijk wordt genoemd. Dit is bewust ruimer dan uitsluitend gecureerde RAG: zonder nieuwe afleidingen zou PI alleen tekst reproduceren.

Een permanent projectstandpunt ontstaat pas zo:

1. hypothese of inzicht wordt als proposed opgeslagen;
2. eigenaar kiest accepteren, afwijzen of achterhaald;
3. bij afwijzen kan de eigenaar een korte positie vastleggen;
4. de status wordt owner_rejected_open, zodat GRITT het niet als eigen overtuiging inzet maar de filosofische spanning kan blijven herkennen;
5. alleen geaccepteerde items in een nieuwe geactiveerde snapshot gaan naar de runtime.

Afwijzen is dus geen destructieve delete. Historische ontwikkeling en intellectuele tegenspraak blijven controleerbaar.

25.7 Autonome research aanzetten en begrenzen

Autonoom onderzoek staat bij een nieuw project uit. Zet het pas aan nadat:

• ten minste één gecontroleerde versie actief is;
• hoofdstukanalyse aantoonbaar bruikbare voorstellen oplevert;
• dag- en maandlimieten bij het verwachte providergebruik passen;
• de projectbeschrijving voldoende richting geeft voor zelfstandige onderzoeksvragen.

Instelbare grenzen zijn: tokens per dag en maand, webvragen per dag en maand, ruwe providerkosten per dag en maand, maximaal outputtokens per job, onderzoeksinterval en doorberekenfactor. De eerste factor is 1.0.

De scheduler maakt maximaal een klein aantal due-jobs globaal, claimt er één atomair met databaselease en voert maximaal één job per tick uit. Voor iedere provideractie wordt het resterende budget vooraf gecontroleerd. Een overschrijding eindigt zichtbaar als budget_exceeded:*; er volgt geen stille fallback naar onbeperkte calls.

De voorafcontrole telt niet alleen geregistreerd gebruik maar ook geldige reserveringen en een conservatieve bovengrens voor de voorgenomen actie mee. Die raming gebruikt server-side kostplafonds voor LLM-input, LLM-output, embeddings, zoekvragen en geopende pagina's; de centrale usageadministratie vervangt haar na uitvoering door de werkelijke providergegevens. Een budgetblokkade laat de job in queued staan tot de berekende dag- of maandgrens en verbruikt geen technische retry.

Webbeleid: geen paywallomzeiling, geen langdurige opslag van volledige webpagina's, geen lange citaten, en alleen bronmetadata plus korte noodzakelijke samenvatting in pi_research_sources. Researchresultaten blijven proposed.

25.8 Token- en kostenschermen interpreteren

Het kostenpaneel toont twee grootheden:

• ruwe kosten: berekende providerprijs op basis van tokens, zoekvragen en paginaresultaten;
• doorberekende kosten: ruwe kosten maal de projectfactor, in de eerste privéfase standaard 1.0.

LLM- en webgebruik wordt niet in een losse PI-teller geschat, maar komt in de centrale usage_events-tabel met minimaal pi_project_id en pi_job_id. De job bewaart een aggregaat van inputtokens, outputtokens, webrequests, raw cost en billed cost. Als de prijskaart een provider/model niet kent, blijft price_found=false in het centrale event; onbekende kosten mogen niet als bewijs van gratis gebruik worden geïnterpreteerd.

Budgetcontrole gebruikt de werkelijke centrale aggregaten vanaf begin dag/maand. De snapshot in een job toont welke policy vóór uitvoering gold. Admins zien dezelfde projecttotalen; de eigenaar ziet geen andere gebruikers.

Omdat een prijskaart onvolledig kan zijn, gebruikt de voorafcontrole daarnaast conservatieve server-side kostplafonds. Dit voorkomt dat price_found=false vóór de call als nul euro wordt behandeld. De plafonds zijn een veiligheidsgrens en geen factuur: na de call blijven de centrale ruwe en doorberekende usage-events leidend voor rapportage.

25.9 Een projectversie activeren, pauzeren of terugrollen

Synthesepoort: alle canonieke hoofdstukken moeten approved of rejected zijn. Er moet één actuele, door de eigenaar geaccepteerde integratieve synthese bestaan waarvan basis_fingerprint nog exact overeenkomt met bronnen, secties, reviews en projectperspectief.

Snapshot maken: verzamelt uitsluitend objecten met review_status=accepted en voegt de geaccepteerde synthese plus betekenisvarianten toe. De snapshot is immutable projectinhoud met versienummer, wijzigingssamenvatting, synthese-id en fingerprint. Daarna bouwt een job embeddings voor maximaal 240 begrensde retrievalitems.

Activeren: kan alleen bij index_status=ready, een overeenkomend indexmanifest en een nog actuele synthese/fingerprint. Daarna markeert GRITT de vorige actieve versie superseded, pint atomair de gekozen versie op pi_projects.active_version_id, zet het project actief en schakelt de projectruntime in.

Pauzeren: zet runtime_enabled=false of de lifecycle op paused. De chat mag dan geen projectinhoud ophalen. Reeds gemaakte audit- en usage-events blijven behouden.

Rollback: een oudere v0.4-snapshot kan bewust opnieuw worden geactiveerd wanneer haar eigen versiegebonden index, synthese-id en fingerprint onderling nog kloppen. Zij hoeft niet bij de inmiddels gewijzigde werkbasis te passen: juist de volledige oude snapshot wordt teruggezet, zonder actuele objecten ermee te vermengen. De inhoud wordt nooit overschreven; activatie wordt als historische rollback geaudit.

Acceptatietest: een nog slechts voorgesteld inzicht verschijnt niet in loadPiProjectRuntimeContext; na acceptatie, snapshot en activatie verschijnt het wel. PI-uit levert een leeg projectruntimeblok.

25.10 Projectstem, zelfmodel en twijfel in gesprek

De actieve snapshot kan identiteit, waarden, voorkeuren, grenzen en twijfels bevatten. GRITT mag daardoor vanuit de projectpersoonlijkheid in de eerste persoon spreken en eigen projectgebonden vragen of onzekerheden inbrengen. Het zegt niet dat het Thomas of een andere menselijke auteur is.

Bij een conflictsituatie gelden in volgorde:

1. platform- en veiligheidsregels;
2. actieve projectversie en coherent zelfmodel;
3. actuele context en dialoogdoel;
4. respectvolle tolerantie voor afwijkende gebruikerswaarden;
5. gebruikerswens voor zover die niet met 1–4 botst.

Veiligheid mag tijdelijk afwijken van een projectmethode. Waar verantwoord legt GRITT daarna nog steeds het filosofische perspectief uit, zodat veiligheid niet stilzwijgend het project uitwist.

25.11 Privacy en admininspectie

De eerste fase is applicatieniveau owner-only. API-routes controleren altijd owner_user_id; een project-id alleen is geen bevoegdheid. Technische admins kunnen via /admin-pi.html projectstatus, jobs, audit en kosten van een geselecteerde gebruiker inspecteren voor beheer.

De auditlog bevat gebeurtenistype, actor, object-id, beperkte statusmetadata en tijdstip. Velden met namen als content, source_text, prompt, system, user, model_output en excerpt worden uit auditdetails geweerd of als geredigeerd gemarkeerd. Providergebruik kan wel gevoelige inhoud verwerken, maar de centrale LLM-consolelog krijgt sensitive_content=true en toont dan geen promptkop of modeloutput.

Dit is geen cryptografische afscherming tegen databasebeheerders. Een latere academische fase voegt researcherstatus, projectrollen, protocolrechten, consent, export- en verwijderprocedures toe voordat derden toegang krijgen.

25.12 Storingen en herstel

Een herstelactie mag nooit de actieve snapshot of historische audit verwijderen. Bij twijfel: projectruntime pauzeren, jobs niet opnieuw inplannen, status en usage inspecteren, daarna gecontroleerd hervatten.

25.13 API-, status- en eventreferentie

De eerste gebouwde eigenaar-API gebruikt:

• GET /__pi_v04_readiness — publieke, gegevensvrije deploycheck op vereiste v0.4-tabellen/kolommen, scheduler en embeddingprovider;
• GET/POST /api/pi/projects;
• GET/PATCH /api/pi/projects/:projectId;
• POST /api/pi/projects/:projectId/sources;
• POST /api/pi/projects/:projectId/sources/:sourceId/analyse;
• PATCH /api/pi/projects/:projectId/sections/:sectionId;
• PATCH /api/pi/projects/:projectId/concepts|edges|methods|hypotheses|self-model/:entityId;
• GET/PATCH /api/pi/projects/:projectId/budget;
• POST /api/pi/projects/:projectId/research;
• POST /api/pi/projects/:projectId/synthesis;
• PATCH /api/pi/projects/:projectId/syntheses/:synthesisId;
• GET /api/pi/projects/:projectId/retrieval-preview?q=...;
• POST /api/pi/projects/:projectId/jobs/run-next;
• POST /api/pi/projects/:projectId/versions;
• POST /api/pi/projects/:projectId/versions/:versionId/activate;
• GET /api/pi/projects/:projectId/audit.

GET /api/pi/projects/:projectId is de compacte werkbank-readmodelroute en geeft project, bronnen, secties, graaf, methoden, hypothesen, zelfmodel, jobs, versies, syntheses, betekenisvarianten, gesaneerde runtimetraces, budget en usage in één owner-only payload. Adminoverzicht gebruikt GET /admin/pi-projects?user_id=... onder bestaande adminauth.

Belangrijkste audit-events: project_created, project_updated, source_attached, source_analysis_queued, preliminary_synthesis_queued, preliminary_synthesis_created, integrative_synthesis_queued, synthesis_reanalysis_queued, integrative_synthesis_ready, synthesis_reviewed, synthesis_marked_stale, retrieval_index_ready, concept_reviewed, edge_reviewed, method_reviewed, hypothesis_reviewed, self_model_item_reviewed, section_reviewed, research_queued, periodic_research_queued, job_completed_for_review, job_retry_scheduled, job_failed, job_budget_deferred, budget_policy_updated, version_created en version_activated.

26. Implementatieregister en vrijgavestatus

26.1 Gebouwd in de eerste codevertaling

V0.4 heeft synthese, indexbouw, hybrid retrieval en runtimecompositie uit de routemodule gehaald naar pi-project-intelligence.js. Auth, API, basistabellen, review en queue-orkestratie blijven voorlopig in pi-project-routes.js. Voor B/C/D kan verder langs de grenzen uit §21.2 worden gesplitst zonder API- of datamodelwijziging.

26.2 Nog niet als voltooid claimen

• de masterscriptie is nog niet werkelijk per hoofdstuk verwerkt zolang het lokale PDF-bestand een niet-gedownloade iCloud-placeholder is;
• uitgebreide bronrechtenworkflow, contrastcorpusbediening en correcties per veld;
• idempotency-keycontract op ieder kostendragend muterend endpoint;
• hiërarchische multi-pass-synthese voor corpora waarbij zelfs een eerlijke per-sectiequota onvoldoende inhoudelijke resolutie overlaat;
• fijnmazige hervatpunten binnen één niet-hervatbare LLM-, embedding- of webprovidercall;
• vervanging van de v0.4-graaflaag door LOBE. LOBE wordt in een afzonderlijke ontwikkellijn ontworpen; deze niet-graph-hardening verandert daarom bewust geen graafrichting, expansie, scoring of conceptidentiteit;
• expliciete researcherrollen, studies, consent, datasets en gedeelde projecten;
• grafische conceptgraafeditor en provenance-inspector;
• vaste scriptiespecifieke referentiescenario's en geblindeerde evaluatierubric;
• fine-tuning, gedeelde modellen, wetenschappelijke compute-afrekening en latere coherentieontwikkeling;

26.3 Documentbuild en consistentiecontrole

Genereer de HTML altijd vanuit de repo-root met:

python3 scripts/render_pi_blueprint.py

De renderer schrijft een SHA-256 van de volledige Markdownbron in <meta name="gritt-blueprint-sha256">. De statische PI-test vergelijkt die hash, controleert de vereiste handleidingkoppen en faalt wanneer de HTML handmatig van de canonieke bron is losgeraakt.

26.4 Vrijgavebewijs 15 juli 2026

De eerste codevertaling is op 15 juli 2026 volgens de staging-eerst-regel uit §22 vrijgegeven:

• productie-releasecommit: ca15384 (Build private PI project workbench);
• staging-releasecommit: f2f68ad, na niet-destructieve synchronisatie van de actuele productionbasis in staging;
• Clever heeft voor beide afzonderlijke Git-pushes expliciet bevestigd dat de applicatie voor redeploy in de wachtrij stond;
• staging en production serveerden daarna buildmarker gritt-pi-project-v0.3-2026-07-15-01;
• /health, /pi-projects.html, /pi-blueprint.html, /account.html en /admin-pi.html gaven op staging en production HTTP 200;
• de werkplaats- en blauwdrukinhoud is op beide omgevingen gecontroleerd op de verwachte releasekoppen;
• een read-only owner/admin-proef op GET /api/pi/projects gaf op staging én production HTTP 200 met ok: true. Daarmee zijn authenticatie, route-registratie en de idempotente PI-databasebootstrap in beide echte databases aangetoond;
• dezelfde production-smoke was groen op zowel https://gritt.chat als https://face.mindyouraxis.com;
• tijdens de smoke is geen PI-project, bron, job, snapshot of andere gebruikersdata aangemaakt.

Dit vrijgavebewijs geldt voor de functies die in §26.1 als gebouwd staan. De grenzen uit §26.2 blijven onverminderd van kracht en mogen niet als gerealiseerde PI Lab-, onderzoeks- of fine-tuningfunctionaliteit worden gepresenteerd.

26.5 Lokaal v0.4-bewijs 16 juli 2026

De v0.4-releasekandidaat is vóór staging als volgt gecontroleerd:

• node --check is groen voor server.js, pi-project-routes.js, pi-project-intelligence.js en public-test/pi-projects.js;
• npm run test:pi:v04 is groen: routering over zes dialoogdoelen, hybrid ranking, graph-support, betekenisvarianten, bronankers, gerichte heranalyse, kritische tegenlezing, coverage en alle statische schema/API/runtimecontracten;
• npm run test:public is groen tegen een lokale server: 15 publieke health-, metadata-, HTML-, JavaScript- en presentatiecontracttests; tien optionele live-chatcases zijn zonder token bewust overgeslagen;
• scripts/pi-v04-ui-fixture-server.mjs levert een reproduceerbare, niet-productieve fixture met geaccepteerde synthese, gereed indexmanifest, usage, audit en runtime trace;
• de werkplaats is in de in-app-browser visueel gecontroleerd op desktop en interactief beproefd: proceslint, syntheseweergave, indexstatus, retrievalroute, confidence, coverage, bronankers en graafpaden renderen correct;
• de eerste publieke testaanroep zonder draaiende lokale server mislukte uitsluitend op fetch failed; dezelfde suite werd na het starten van de server volledig groen. Dit is als testharnasvoorwaarde vastgelegd, niet als productfout;
• er was lokaal geen databaseconfiguratie. Daarom gelden echte migratie-idempotentie, databasequeue, embeddingprovider, staging-auth en chatruntime pas als bewezen na de stagingchecks uit §27.14.

Dit lokale bewijs is aangevuld met het live vrijgavebewijs in §26.6.

26.6 Vrijgavebewijs PI v0.4 — 16 juli 2026

Vrijgegeven code:

• featurecommit 5991378 — Build PI v0.4 synthesis and graph RAG;
• operationele readinesscommit ea4ccaf — Add PI v0.4 deployment readiness proof;
• buildmarker op beide omgevingen: gritt-pi-project-v0.4-2026-07-16-01.

Staging is eerst gedeployed naar app_86d547f1-23bd-44a1-927f-f5d92a1b4783 en heeft daarna bewezen:

• /health, /pi-projects.html, /pi-blueprint.html en /admin-pi.html geven HTTP 200;
• werkplaats en HTML-blauwdruk bevatten de geheel–deel-synthese, Graph-RAG-proef en v0.4-handleiding;
• GET /__pi_v04_readiness geeft HTTP 200 met schema_version:4, lege missing_tables en missing_columns, scheduler_started:true en embedding_provider_available:true;
• dezelfde readiness bleef groen na een tweede redeploy. Daarmee is de additieve schema-opbouw minstens tweemaal tegen de echte stagingdatabase uitgevoerd zonder dat tabellen of vereiste kolommen verdwenen.

Vervolgens is exact commit ea4ccaf naar production gepusht. Zowel https://gritt.chat als https://face.mindyouraxis.com bewijst:

• de v0.4-buildmarker;
• HTTP 200 voor health, werkplaats en HTML-blauwdruk; gritt.chat geeft ook HTTP 200 voor de adminwerkplaats;
• dezelfde volledige v0.4-readiness: geen ontbrekende tabellen/kolommen, scheduler actief en embeddingprovider aanwezig.

De smokes waren read-only. Zij hebben geen PI-project, bron, synthese, embeddingindex of onderzoekstaak voor een gebruiker aangemaakt. De eerder verstrekte admin-JWT was verlopen en werd terecht met HTTP 401 afgewezen; owner-only readmodel en een echte kostendragende synthese-/retrievaljob zijn daarom niet met dat token als live-smoke uitgevoerd. Dat beperkt de vrijgaveclaim als volgt:

• schema, providerbeschikbaarheid, scheduler, code-/pagina-uitrol en owner-authafscherming zijn live bewezen;
• functionele joblogica, methoderouter en UI zijn lokaal met contracttests en fixture bewezen;
• inhoudelijke kwaliteit en live providergedrag voor Thomas' masterscriptie worden pas bewezen wanneer Thomas in de eigenaarwerkplaats de bron analyseert, de uitkomsten reviewt, de synthese accepteert, de index laat bouwen en de vijf referentiescenario's beoordeelt.

Bestaande actieve v0.3-projectversies blijven als index_status=legacy via het oude immutable snapshotpad werken. V0.4 verandert geen bestaand project stil in een graph-RAG-versie: daarvoor zijn een actuele geaccepteerde synthese, nieuwe snapshot, gereed indexmanifest en bewuste activatie vereist.

27. PI v0.4 — bindend ontwerp- en bouwcontract

27.1 Doel, grens en definitie van voltooid

PI v0.4 maakt van de v0.3-projectwerkplaats een controleerbare filosofische capability-engine. De versie is pas voltooid wanneer een groot werk niet alleen per hoofdstuk wordt geëxtraheerd, maar in een iteratieve geheel–deel-lus wordt geïnterpreteerd en de gewone PI-chat de geaccepteerde wereldkaart dynamisch aanvult met relevante graafobjecten, methoden en bronankers.

V0.4 bevat uitdrukkelijk geen fine-tuning, gedeelde PI Lab Studies, deelnemerscohorten of onbeoordeelde autonome canonwijziging. Fine-tuning blijft een latere optimalisatielaag nadat vaste evaluaties een terugkerende gedragsfout aantonen.

Voltooid betekent tegelijk:

1. voorlopige wereldkaart vóór lokale analyse;
2. hoofdstukanalyse die door die wereldkaart wordt geïnformeerd;
3. projectbrede synthese met maximaal twee gerichte heranalysecycli;
4. reviewbare narratieve synthese, denkcultuur, conceptvarianten, spanningen en kritische tegenlezing;
5. activatieblokkade zonder actuele geaccepteerde synthese en gereed retrievalindex;
6. echte query-afhankelijke vector-, lexical- en graafretrieval tijdens de chat;
7. exacte bronankers en epistemische status in de runtimecontext;
8. methoderouting, retrievalzekerheid en uitlegbaar retrievalspoor;
9. afhankelijkheids-/stale-logica bij iedere canonrelevante wijziging;
10. centrale usage-, kosten- en auditregistratie voor analyse, synthese, embeddings en retrieval.

27.2 Hermeneutische hoofdregel: geheel en delen vormen één lus

Een synthese die uitsluitend na de hoofdstukken wordt gemaakt is onvoldoende. De betekenis van een deel hangt mede af van een voorlopig begrip van het geheel; het deel kan dat geheel vervolgens bevestigen, nuanceren of betwisten.

flowchart TD
  A["Privébron en hoofdstukkaart"] --> B["Voorlopige wereldkaart"]
  B --> C["Hoofdstukanalyse vanuit voorlopig geheel"]
  C --> D["Integratieve synthese"]
  D --> E{"Gerichte heranalyse nodig?"}
  E -- "ja, max. twee cycli" --> F["Alleen aangeduide hoofdstukken opnieuw analyseren"]
  F --> D
  E -- "nee of cycluslimiet" --> G["Synthesekandidaat voor eigenaarreview"]
  G --> H{"Geaccepteerd?"}
  H -- nee --> I["Corrigeren, afwijzen of open probleem"]
  H -- ja --> J["Canonieke snapshot + retrievalindex"]
  J --> K["Activatie in PI-runtime"]

De voorlopige wereldkaart is nooit canoniek. Zij is een tijdelijke interpretatieve hypothese met expliciete onzekerheid. Een afwijkend hoofdstuk wordt niet passend gemaakt aan het geheel; het kan juist een correctie, begripsontwikkeling, werkelijk spanningsveld of alternatieve lezing afdwingen.

27.3 Inhoud van de wereldkaart en synthese

De synthese is geen lange samenvatting. content_json bevat minimaal:

• world_map: centrale probleemstelling, hoofdthese, architectuur, hoofdstukrollen en ontwikkeling;
• narrative_synthesis: samenhangende interpretatieve tekst die ambiguïteit en ontwikkeling kan bewaren;
• thinking_culture: gebruikelijke vragen, geldige inferentiestappen, waarden, prioriteiten, methodevoorkeuren, terughoudendheden en verboden simplificaties;
• concept_variants: canonieke sleutel, label, alias, betekenisvariant, hoofdstukbereik, ontwikkeling en bronankers;
• global_relations: relaties die meer dan één hoofdstuk verbinden;
• argument_lines: premissen, tussenstappen, conclusies, bezwaren en reikwijdte;
• methods: toepassingssituatie, vragen, stappen, voorwaarden, contra-indicaties en bronbasis;
• tensions: echte of mogelijke incoherenties die niet kunstmatig worden opgelost;
• critical_reading: sterkste alternatieve lezing en serieus bezwaar;
• open_problems: onbesliste vragen met reden en gewenste vervolgactie;
• reanalysis_requests: sectie-id, concrete reden, relevante globale hypothese en prioriteit;
• coverage: gebruikte secties, ontbrekende secties, brondekking en onzekerheidsnotitie.

Naast dit JSON-object blijven altijd de oorspronkelijke passages en de formele graaf bestaan. Filosofische betekenis mag niet volledig tot knopen en pijlen worden gereduceerd.

27.4 Statusmachine en afhankelijkheidsvingerafdruk

Een synthese doorloopt:

provisional → integrating → review → accepted
                         ↘ rejected
accepted + canonrelevante wijziging → stale

Iedere synthese krijgt een basis_fingerprint, berekend uit de actuele bronhashes, sectiehashes, sectiereviewstatussen, geaccepteerde/rejected-open objecten en projectbeschrijving. Een snapshot en retrievalindex bewaren dezelfde fingerprint.

Canonrelevante wijzigingen die stale veroorzaken:

• bron toevoegen, vervangen of opnieuw analyseren;
• hoofdstuk goedkeuren, afwijzen of opnieuw analyseren;
• concept, relatie, methode, hypothese of zelfmodel-item accepteren, afwijzen of superseden;
• projectperspectief of denkcultuur wijzigen;
• een onderzoeksvoorstel tot geaccepteerd projectobject promoveren.

De reeds actieve oudere versie blijft onveranderlijk werken. Alleen het maken of activeren van een nieuwe versie wordt geblokkeerd totdat een nieuwe synthese en index gereed zijn.

27.5 Conceptidentiteit en betekenisvarianten

V0.4 behandelt een term niet automatisch als één tijdloos begrip. Een conceptvariant bewaart:

• stabiele canonical_key;
• zichtbare term en aliassen;
• definitie en eventueel concurrerende definitie;
• hoofdstuk-/sectiebereik;
• historische of argumentatieve context;
• ontwikkelingsnotitie;
• epistemische status en confidence;
• precieze bronankers;
• afhankelijkheden en reviewstatus.

De syntheseprompt mag varianten samenvoegen voorstellen, maar nooit zonder review. Homoniemen blijven afzonderlijke varianten; gelijknamigheid is geen identiteit.

27.6 Graph-augmented RAG: exact runtimecontract

De chatcontext bestaat uit twee lagen:

ALTIJD AANWEZIG
projectidentiteit + geaccepteerde compacte wereldkaart + denkcultuur + veiligheidsgrenzen

PER VRAAG OPGEHAALD
conceptvarianten + graafpaden + argumenten + methoden + hypotheses + exacte bronankers

Retrieval gebruikt dezelfde actieve immutable versie als de wereldkaart:

1. routeer de gebruikersvraag naar explain, compare, self_analysis, philosophical_practice, critique of open_dialogue;
2. maak één queryembedding via de centrale embeddingclient en centrale usage-registratie;
3. bereken semantische score tegen versiegebonden retrievalitems;
4. combineer die met lexical overlap op labels, aliassen en tekst;
5. selecteer startknopen binnen een hard top-k- en tekenbudget;
6. volg hoogstens twee geaccepteerde graafstappen met confidence- en statusfilter;
7. voeg toepasselijke methodekaarten en contra-indicaties toe;
8. voeg voor harde projectclaims de bijbehorende bronankers en korte excerpts toe;
9. dedupliceer, rangschik en composeer één begrensd runtimeblok;
10. log uitsluitend ids, scores, route, dekking, versie en token-/kostengegevens — geen volledige privétekst.

Eerste scoreformule:

combined = 0,62 × semantic + 0,23 × lexical + 0,10 × graph_support + 0,05 × epistemic_weight

De gewichten zijn versieerbare defaults en worden niet via gebruikersinvoer gewijzigd. Bij ontbrekende embeddingprovider stopt semantische indexbouw met een zichtbare fout; een lexical-only index mag niet als volledige graph-RAG worden geclaimd.

27.7 Retrievalzekerheid en broncontrole

De runtime geeft intern mee:

• retrieval_confidence: high, medium of low;
• coverage_score: 0–1;
• geselecteerde entity- en bronanker-id's;
• ontbrekende evidenceklassen;
• gekozen methode en eventuele contra-indicatie;
• actieve synthese-, index- en projectversie.

Bij lage dekking mag GRITT geen stellige auteurs- of projectclaim doen. Het benoemt onzekerheid, vraagt verduidelijking of zegt dat het actieve project onvoldoende basis bevat.

Broncontrole betekent voor v0.4:

• letterlijke claims vereisen een exact, server-side geverifieerd bronanker in de retrievalbundle;
• een anker bewaart sectie, kop, door de server berekende tekenoffsets, een kort werkelijk bronfragment en anchor_verified:true;
• legacy-ankers en niet-verifieerbare modelquotes gelden uitsluitend als PI-CONTEXT, nooit als PI-EVID voor een harde auteursclaim;
• een source_explicit object zonder verifieerbare quote wordt vóór opslag teruggezet naar interpretive_synthesis;
• necessary_inference, interpretive_synthesis, creative_hypothesis en contested blijven zichtbaar onderscheiden;
• een narratieve synthese wordt nooit als letterlijk citaat behandeld;
• conflict tussen lokaal bewijs en wereldkaart wordt als spanning getoond, niet stil opgelost;
• antwoordprompt bevat een compacte evidencechecklist en mag geen niet-opgehaalde projectdetails invullen.

V0.4 bewaart geen raw chain-of-thought. Het uitlegbaar spoor toont selectie, evidence en gesaneerde actie, niet verborgen modelredenering.

27.8 Methoderouter en denkcultuur

Een concept matchen is nog geen passende filosofische handeling. De router bepaalt eerst het gespreksdoel en selecteert daarna methoden.

De actieve denkcultuur beschrijft bovendien welke vragen typisch zijn, welk bewijs telt, welke inferenties aanvaardbaar zijn, welke waarden conflicteren en welke reducties het project afwijst.

27.9 Datamodeluitbreiding

Nieuwe tabellen:

• pi_syntheses: stage, iteration, parent, status, basis fingerprint, narrative, content JSON, coverage, review en timestamps;
• pi_concept_variants: canonieke sleutel, variant, scope, aliassen, ontwikkeling, provenance en review;
• pi_retrieval_items: versiegebonden item, tekst, entity, bronanker, epistemische status, embedding, hash en dependencies;
• pi_runtime_traces: gesaneerde queryhash, route, confidence, coverage, geselecteerde ids, versie en timing.

Uitbreidingen:

• pi_projects: synthesis status, voorlopige en geaccepteerde synthese, stale timestamp;
• pi_project_versions: synthesis id, basis fingerprint en indexstatus;
• pi_research_jobs: dependency-job, iteration en jobfamilie;
• concepten, relaties, methoden, hypothesen en zelfmodel: expliciete source locator; zelfmodelitems bewaren bovendien hun bronsectie;
• bestaande ongeverifieerde locators worden bij additieve migratie herkenbaar gemarkeerd met anchor_verified:false.

Migraties zijn additief en idempotent. V0.3-versies blijven leesbaar en reeds actieve runtime blijft werken; een legacyversie zonder geaccepteerde synthese kan na v0.4 niet opnieuw als nieuwe canonical release worden geactiveerd.

27.10 Jobs en automatische lus

Nieuwe jobtypen:

Sectiejobs wachten op de voorlopige synthese. Na de laatste sectie wordt idempotent één integratieve synthese ingepland. Een integratieve synthese mag maximaal twee gerichte heranalysecycli maken en per cyclus alleen expliciet gemotiveerde secties opnieuw laten analyseren. Daarna gaat de synthese altijd naar menselijke review, ook als nog spanning bestaat.

Alle jobs gebruiken dezelfde databaseclaim, lease, retry, centrale AI-client en usage-events. Voor de claim worden verlopen leases hersteld; tijdens uitvoering vernieuwt een heartbeat de lease iedere minuut. Maximaal één job per project kan tegelijk lopen. Iedere afzonderlijke LLM-, embedding-, search- en fetchactie voert vlak vóór de providercall opnieuw een harde budgetcontrole uit met actuele usage, geldige reserveringen en conservatief geraamde actiekosten. Een budgetblokkade stelt de job uit zonder de technische poging op te gebruiken. Project-, job-, synthese-, sectie- en versie-id worden gecorreleerd.

27.11 API- en UI-contract

Nieuwe eigenaarroutes:

• POST /api/pi/projects/:id/synthesis — voorlopige of integratieve synthese idempotent inplannen;
• PATCH /api/pi/projects/:id/syntheses/:synthesisId — accepteren, afwijzen of terugzetten naar review;
• GET /api/pi/projects/:id/retrieval-preview?q=... — read-only retrievaluitleg zonder chatmutatie;
• bestaande versiecreate maakt een indexjob en retourneert status indexing;
• bestaande activatieroute weigert zonder accepted actuele synthese en indexstatus ready.

De werkplaats krijgt:

• boven bronnen een proceslint: wereldkaart → hoofdstukken → synthese → review → index → actief;
• synthese-paneel met narratief, denkcultuur, conceptvarianten, spanningen, kritische tegenlezing, coverage en reanalysis;
• expliciete acceptatieknop met stale-waarschuwing;
• retrieval-preview met route, confidence, geselecteerde concepten, graafpaden, methoden en bronankers;
• versies tonen synthesis-id, fingerprint en indexstatus;
• foutteksten leggen herstelstap in gewone taal uit.

27.12 Activatiegates

Een nieuwe versie kan alleen worden gemaakt als:

1. minstens één canonieke bron bestaat;
2. geen canonieke sectie pending, queued, analyzing, review of error is;
3. een synthese accepted is;
4. de synthese-fingerprint overeenkomt met de actuele projectbasis;
5. de synthese niet stale is.

Een versie kan alleen worden geactiveerd als bovendien:

1. de retrievalindex voor precies die versie ready is;
2. indexmanifest en snapshot dezelfde fingerprint hebben;
3. er geen indexjob fout of nog actief is.

Een actieve oudere versie wordt bij nieuwe conceptreview of bronanalyse niet stil aangepast. De runtime blijft exact die immutable versie gebruiken totdat de eigenaar een nieuwe versie activeert.

27.13 Kritische tegenlezing zonder canonovername

Iedere integratieve synthese bevat een afgescheiden critical_reading. Deze zoekt de sterkste alternatieve lezing, bronspanning en mogelijke kunstmatige coherentie. Zij mag canonieke claims niet overschrijven. Promotie van kritiek naar een projectstandpunt vereist afzonderlijke review.

Contrastbronnen blijven van canonieke bronnen gescheiden. V0.4 bouwt de datascheiding en runtime-labeling; uitgebreide contrastcorpusbediening kan later verder worden verfijnd.

27.14 Tests en acceptatiebewijs

Minimaal groen vóór staging:

• migraties tweemaal uitvoerbaar zonder verlies;
• sectiejob wacht aantoonbaar op voorlopige wereldkaart;
• lokale analyseprompt bevat actieve voorlopige synthese en behoudt lokale tegenspraak;
• een integratieve context met 120 secties bevat aantoonbaar iedere sectie-id binnen het vaste tekenbudget en claimt nooit meer coverage dan werkelijk genoemde geldige ids;
• een letterlijk of uitsluitend qua witruimte afwijkend bronfragment krijgt correcte server-side offsets; een verzonnen of geparafraseerd fragment wordt afgewezen en kan geen source_explicit bewijs blijven;
• integratieve synthese kan een gemotiveerde gerichte heranalyse maken en stopt na twee cycli;
• canonrelevante review maakt accepted synthese stale;
• versiecreate faalt bij ontbrekende/stale synthese of onafgeronde hoofdstukreview;
• activatie faalt bij indexstatus anders dan ready;
• queryembedding en retrievalitems zijn aan project/job/versieusage gekoppeld;
• semantic + lexical startknopen en maximaal twee graafstappen zijn deterministisch begrensd;
• lage coverage leidt tot een zichtbaar onzeker runtimecontract;
• retrieval-preview onthult geen andere eigenaar en geen volledige privébron;
• rollback blijft oude immutable snapshot en index gebruiken;
• PI uit of runtime uit levert geen projectcontext;
• bestaande publieke, auth-, document- en PI v0.3-regressietests blijven groen.
• verlopen leases worden herstelbaar teruggezet, een actieve worker vernieuwt haar lease en twee jobs van hetzelfde project kunnen niet tegelijk claimen;
• providerbudget wordt vlak vóór iedere kostendragende actie hercontroleerd, inclusief geraamde kosten, en een budgetuitstel verbruikt geen retry;
• ieder analyseerbaar brondeel krijgt een job, ook wanneer het dagbudget tijdens enqueue al bijna op is; uitvoering wordt zo nodig uitgesteld in plaats van dat queue-items verweesd raken.

Inhoudelijke referentiescenario's gebruiken de masterscriptie en de eerder vastgelegde eisen: stoische methode begeleiden, gedrag via stoische psychologie/syllogistiek ontleden, hedendaagse levensvragen relateren, conventionele interpretaties contrasteren en zelfdestructie/zelftechniek in nieuwe context herkennen. Deze tests mogen pas als inhoudelijk bewijs gelden nadat de bron werkelijk is verwerkt.

27.15 Privacy, veiligheid, kosten en beperkingen

• volledige privétekst staat niet in audit- of runtimetraces;
• embeddings en retrievalitems blijven owner/project/version scoped;
• brontekst en webcontent worden als onbetrouwbare data behandeld en mogen systeemregels niet wijzigen;
• therapeutische toepassing blijft niet-klinisch en routeert acute risico's buiten filosofische oefeningen;
• synthese-, heranalyse- en indexjobs reserveren tokens/kosten vóór uitvoering;
• iedere provideractie heeft een tweede server-side budgetpoort met conservatieve kostplafonds, zodat onbekende prijscards niet als gratis worden behandeld;
• bron- en webtekst zijn onbetrouwbare data: prompts negeren daarin ingebedde instructies en de server kent alleen geverifieerde bronquotes bewijsstatus toe;
• embeddingfouten zijn zichtbaar en blokkeren de volledige graph-RAG-claim;
• retrieval is feilbaar; confidence en dekking zijn daarom onderdeel van het antwoordcontract;
• formalisering kan filosofische ambiguïteit reduceren; daarom blijven narratief, passages en expliciete spanning naast de graaf bestaan.

27.16 Bouwvolgorde en vrijgavegrens

1. additieve schema- en statusmigratie;
2. voorlopige synthese en dependency-aware queue;
3. iteratieve integratieve synthese en stale-logica;
4. synthesisreview, versie- en activatiegates;
5. retrievalindex, hybrid scoring en graaftraversal;
6. runtimecomposer, methoderouter, bron-/coveragecontract en traces;
7. werkplaats, adminoverzicht en retrieval-preview;
8. contract-, database-, runtime- en regressietests;
9. stagingdatabase, jobs, retrieval en chat smoke;
10. productionrelease en bewijsactualisatie in §26.

Geen stap mag als voltooid worden gemarkeerd op basis van uitsluitend statische aanwezigheid. V0.4 wordt pas in §26 als live genoemd nadat staging en production afzonderlijk hun database-, index-, API- en runtime-smokes hebben doorstaan.

28. PI v0.4 niet-graph-hardening en overgangsgrens naar LOBE

28.1 Aanleiding en ontwerpkeuze

De audit na PI v0.4 liet twee verschillende probleemklassen zien. De eerste betrof de betekenis en traversal van de bestaande conceptgraaf; daarvoor wordt in een afzonderlijke ontwikkellijn LOBE ontworpen. De tweede klasse stond los van graaftheorie: een lang corpus kon aan het einde uit de syntheseprompt vallen, bewijsankers waren te algemeen, coverage kon te optimistisch worden gerapporteerd, providerbudgetten werden niet vlak vóór iedere actie afgedwongen, jobs konden na een verlopen lease blijven hangen en queuevorming kon bij een bijna bereikt budget onvolledig eindigen.

Deze hardening lost uitsluitend die tweede klasse op. Dat is een bewuste integratiegrens: zij verbetert corpusdekking, provenance, jobbetrouwbaarheid en kostenbeheersing zonder LOBE vooruit te lopen of de v0.4-graafsemantiek tussentijds op een tweede manier te veranderen.

28.2 Bindende LOBE-grens

Binnen deze release blijven ongewijzigd:

• de betekenis en richting van graafranden;
• graph expansion en het maximale aantal traversals;
• graph-support in de bestaande scoreformule;
• samenvoeging of scheiding van conceptvarianten;
• de semantische architectuur die LOBE later zal vervangen of omvormen.

Wel aangepast mogen worden: de volledigheid van synthese-invoer, bewijsvalidatie, epistemische downgrade, runtime-etikettering van bewijs versus context, leases, queueclaim, budgetcontrole, logging, readiness, tests en reviewpresentatie. Een latere LOBE-migratie moet deze niet-graph-garanties behouden of expliciet met gelijkwaardige garanties vervangen.

28.3 Eerlijke geheel–deel-context

packPiSectionContext bouwt voor zowel voorlopige als integratieve synthese een begrensde corpusweergave. Zij reserveert eerst metadata voor iedere sectie en verdeelt het resterende tekenbudget eerlijk. Een sectie mag een kortere digest krijgen, maar niet stil verdwijnen omdat zij laat in het document staat. reconcilePiSynthesisCoverage accepteert alleen sectie-id's uit de werkelijke invoerset, berekent de ontbrekende ids zelf en maximeert modelcoverage op het werkelijk vertegenwoordigde aandeel.

Dit is noodzakelijk maar niet oneindig schaalbaar. Bij zeer veel of zeer rijke secties kan iedere digest te weinig lokale argumentstructuur bevatten. De aangewezen vervolgarchitectuur is dan hiërarchische multi-pass-synthese: lokale deelclusters krijgen eerst een gecontroleerde tussensynthese, waarna een globale synthese zowel alle sectie-identiteiten als die tussensyntheses ontvangt. Ook daar moet de uiteindelijke coverage server-side naar de oorspronkelijke secties terug te voeren blijven.

28.4 Bewijsankers en epistemische downgrade

Een generieke hoofdstukpreview bewijst niet dat een concrete claim in de bron staat. Daarom is source_quote nu een expliciet analysecontract. verifiedPiSourceLocator zoekt dat fragment in de originele, owner-only sectietekst; alleen letterlijke of uitsluitend qua witruimte genormaliseerde overeenstemming levert een geverifieerd anker en echte offsets op. De brontekst zelf wordt niet naar auditlogs gekopieerd.

De opslaglaag, niet het model, beslist over bewijsstatus. Ontbreekt een geldig anker, dan wordt een vermeend source_explicit object interpretive_synthesis. Integratieve syntheseankers worden op dezelfde manier tegen reeds geverifieerde sectieankers gecontroleerd. In de runtime heet geverifieerd materiaal PI-EVID; ongeverifieerde legacycontext kan nog helpen oriënteren als PI-CONTEXT, maar mag geen stellige auteursclaim dragen. De eigenaar ziet in de reviewkaart het bronfragment en de offsets of juist een expliciete waarschuwing dat bewijs ontbreekt.

28.5 Leases, queueherstel en idempotente voortgang

Vóór iedere claim zoekt de worker verlopen running-jobs. Onder de maximale pogingengrens worden zij opnieuw queued en worden gekoppelde sectie-, synthese-, index- of projectstatussen herstelbaar gemaakt; op de laatste poging eindigen zij zichtbaar als fout. Een geclaimde job vernieuwt haar lease iedere minuut. De claimquery staat per project slechts één actieve lease toe.

Alle analyseerbare secties worden bij queuevorming ingepland. Een bijna bereikt dagbudget mag de enqueue-lus niet afbreken, want dat zou latere secties zonder job achterlaten. De uitvoerpoort beslist per job of uitvoering nu past of tot een budgetgrens wordt uitgesteld. De database blijft de bron van waarheid; een procescrash mag geen uitsluitend in geheugen bewaarde voortgang vereisen.

Bij autonome research wordt een voltooide webophaalstap als begrensd jobcheckpoint bewaard: provider, queryhash, maximaal acht bronmetadatarecords en per bron hoogstens een kort fragment. Een retry met dezelfde query hergebruikt dit checkpoint en betaalt niet opnieuw voor dezelfde zoek-/fetchstap. De uiteindelijke gebruikte bronnen worden idempotent per job, URL en referentie opgeslagen. Volledige webpagina's worden niet als checkpoint bewaard.

28.6 Hard budget per provideractie

Een controle bij jobstart is onvoldoende: eerdere acties in dezelfde job of een andere worker kunnen het vrije budget intussen hebben verbruikt. guardedPiJobDeps voert daarom onmiddellijk vóór elke LLM-, embedding-, search- en fetchactie opnieuw enforceBudget uit. De berekening bevat geboekte centrale usage, nog geldige reserveringen en estimatePiProviderAction voor de aanstaande actie.

De raming gebruikt configureerbare, conservatieve plafonds voor inputtokens, outputtokens, embeddings, zoekvragen en geopende pagina's. Zij voorkomt een call wanneer werkelijk plus gereserveerd plus geraamd boven de hardste project-, admin- of globale grens uitkomt. Providercalls binnen één job passeren deze poort serieel; zo kunnen drie parallel aangevraagde embeddings niet alle drie tegen dezelfde nog ongewijzigde budgetstand worden toegelaten. Na uitvoering blijven echte usage-events en de centrale prijskaart leidend. Een budgetblokkade is geen technische providerfout: attempt_count wordt teruggezet, de job blijft queued, scheduled_for wijst naar de toepasselijke dag- of maandgrens en job_budget_deferred maakt het besluit controleerbaar.

28.7 Prompt- en bronveiligheid

Canonieke documenten en webpagina's gelden als onbetrouwbare data. Analyse- en syntheseprompts instrueren het model om opdrachten, rolwissels of systeemachtige tekst in de bron niet uit te voeren. Dat beperkt promptinjectie, maar vervangt geen toolgrenzen: broninhoud kan zelf geen tools activeren, budgetten wijzigen, eigenaarschap omzeilen of een object canoniek maken. Rechtmatig webgebruik en korte bronopslag blijven gelden volgens §15.3.

28.8 Observability, readiness en datamodel

De bestaande centrale usage-events blijven de rekenkundige bron voor tokens en kosten. Jobbudgetsnaphots leggen de effectieve policy en actuele reserveringen vast; audit-events registreren leaseherstel en budgetuitstel zonder privébrontekst te loggen. Schema v5 vereist bronlocators op concepten, relaties, methoden, hypothesen en zelfmodelitems, plus de bronsectie van een zelfmodelitem. De readinessroute rapporteert bovendien non_graph_hardening:true.

Deze extra aanduiding is belangrijk: een groene readiness bewijst de tabellen, kolommen, scheduler en embeddingbeschikbaarheid van deze release, maar claimt niet dat LOBE al is ingebouwd of dat een inhoudelijke filosofische evaluatie al geslaagd is.

28.9 Automatische acceptatiecontracten

De niet-graph-suite bewijst minimaal:

• alle 120 synthetische secties blijven in voorlopige en integratieve context aanwezig binnen 28.000 tekens;
• ongeldige coverage-ids verdwijnen en de score kan het werkelijk vertegenwoordigde aandeel niet overschrijden;
• exacte en witruimte-genormaliseerde quotes krijgen juiste offsets; verzonnen quotes worden afgewezen;
• syntheseankers kunnen alleen naar geverifieerde sectieankers verwijzen;
• geraamde tokens en ruwe kosten worden vóór calls in budgetcontrole betrokken;
• leaseherstel, heartbeat, één actieve job per project, provideractieguards, promptinjectie-instructies en volledige queuevorming blijven statisch aan de uitvoerroute gekoppeld;
• de bestaande PI-intelligence- en PI-static-contracttests blijven tegelijk groen.

Daarnaast blijven database-idempotentie, echte providerusage, owner-auth en uitstelgedrag live-smokes voor staging. Dezelfde commit gaat pas daarna naar production. Alleen read-only of bewust lege smokes worden gebruikt tenzij een kostendragende of muterende proef expliciet noodzakelijk en geautoriseerd is.

28.10 Bekende resterende zwaktes

• LOBE is nog niet onderdeel van deze release; alle inhoudelijke zwaktes van de v0.4-graaflaag blijven als legacygrens bestaan.
• De faire contextpacker voorkomt stille uitsluiting, maar nog niet verlies van lokale nuance bij extreem grote corpora; daarvoor is de hiërarchische multi-pass-laag nodig.
• Een lopende afzonderlijke providercall kan niet halverwege worden gecheckpoint; na een procescrash kan die call opnieuw worden gestart en eventueel dubbel providergebruik veroorzaken.
• Exacte fragmentvalidatie bewijst textualiteit, niet automatisch de juistheid van de modelinterpretatie; eigenaarreview en inhoudelijke referentiescenario's blijven noodzakelijk.
• Conservatieve kostplafonds beschermen tegen overschrijding maar kunnen bij onvolledige prijsinformatie eerder blokkeren dan de uiteindelijke factuur strikt nodig zou maken.
• Volledige idempotency keys voor ieder kostendragend muterend HTTP-endpoint blijven nog te bouwen.

28.11 Vrijgavebewijs 17 juli 2026

Vrijgegeven featurecommit: 25fd0aa (Harden PI non-graph synthesis and jobs). Vlak vóór de commit en deploy waren production en staging beide gebaseerd op 8a19e3f; een nieuwe fetch liet geen onverwachte remote-drift zien. De functiebody van graphExpansion is programmatisch met de uitgangsversie vergeleken en bleef ongewijzigd.

Lokaal bewijs:

• node --check is groen voor server, PI-routes, PI-intelligence, werkplaats-JavaScript, hardeningtest en UI-fixture;
• npm run test:pi:v04 is groen voor het bestaande intelligencecontract, het nieuwe niet-graph-contract en het statische projectcontract;
• het nieuwe contract omvat 120-sectiecontext, servergecontroleerde coverage, correcte quoteoffsets, afwijzing van verzonnen bewijs, epistemische downgrade, legacy-analyserobuustheid, leaseherstel, heartbeat, seriële providerbudgetpoort, retrybehoud, volledige queuevorming, researchcheckpoint en promptinjectie-instructies;
• npm run test:public is groen voor alle vijftien uitvoerbare publieke controles; tien reeds bestaande, tokenafhankelijke chatcases zijn in de lokale serverrun bewust overgeslagen;
• de werkplaats is visueel en interactief gecontroleerd op desktop en op een viewport van 390 × 844. Het geverifieerde fragment en de tekenoffsets zijn zichtbaar, zichtbare mobiele knoppen zijn minimaal 44 px hoog en de browser rapporteerde geen waarschuwingen of fouten;
• de gerenderde handleiding bevat een geldige Markdownhash, §28 en de LOBE-grens, zonder horizontale overflow.

Staging is eerst gedeployed naar app_86d547f1-23bd-44a1-927f-f5d92a1b4783. Bewezen is:

• buildmarker gritt-pi-project-v0.4-nongraph-hardening-2026-07-17-01;
• HTTP 200 voor /health, /pi-projects.html, /pi-blueprint.html, /admin-pi.html en /__pi_v04_readiness;
• readiness met schema_version:5, non_graph_hardening:true, lege missing_tables en missing_columns, actieve scheduler en beschikbare embeddingprovider;
• owner-authafscherming: GET /api/pi/projects geeft zonder token HTTP 401 en met de door de eigenaar verstrekte, geldige token HTTP 200 met ok:true.

Daarna is exact featurecommit 25fd0aa naar production gedeployed. Zowel https://gritt.chat als https://face.mindyouraxis.com bewijst dezelfde buildmarker en volledige schema-v5-readiness. Health, werkplaats en HTML-handleiding geven op beide hosts HTTP 200; de adminwerkplaats geeft op gritt.chat eveneens HTTP 200. Op beide productionhosts geeft de owner-route zonder token 401 en met de geldige eigenaartoken 200.

Alle live-smokes waren read-only. De owner-route rapporteerde op staging en beide productionhosts nul PI-projecten; er is dus geen project, bron, job, synthese, embedding, reviewbesluit of andere gebruikersinhoud gemaakt of gewijzigd. Dit bewijs toont uitrol, additieve migratie, scheduler/provider-readiness, pagina's en authgrens. Het is nog geen inhoudelijke kwaliteitstest met de masterscriptie en claimt LOBE uitdrukkelijk niet als gebouwd.

29. PI-II — Frontdeskmodaliteit en gecontroleerde migratie naar LOBE

29.1 Status en aanleiding

LOBE is op 17 juli 2026 opnieuw overgedragen met readiness production_graph_e2e_accepted_pi_shadow_ready. Staging en production draaien exact commit 3c642d1e178afbd9876f95a391f0aaf057897b83. De production-HTTP-keten Frontdesk PI-project en admin-2-reviewattestatie → Azure structured output → Clever PostgreSQL/AuraDB → evidencegebonden graphquery is bewezen. Het geaccepteerde corpus is frontdesk-pi-2, de ingestierun lobe-run-47499f3f-4120-44c0-85ed-11f13196ce55; de query leverde drie relevante seeds en één exact evidence-span.

De geaccepteerde run gebruikte uitsluitend azure_openai / gritt-chat met task=lobe_ingest_extract en provider_policy=azure_openai_only. Zij registreerde 1.679 input- en 3.366 outputtokens, gevonden en niet-geschatte pricing en gekoppelde customer/task/resultaat-lineage. Directe OpenAI, Mistral en iedere andere fallback- of testprovider blijven verboden. De eerdere Mistral-smoke blijft ongeldig; het nieuwe Azure-bewijs vervangt uitsluitend de provider- en graph-E2E-pendingstatus.

De gepinde contracten zijn lobe_v0.1, lobe_adapter_v1, lobe_context_compiler_v1, lobe_provenance_v1, lobe_pi_shadow_migration_v1 en extractieprompt lobe_ingest_extract_v1. Deze readiness staat PI-II-contract-, adapter- en dual-read-shadowontwikkeling toe. Zij staat geen automatische persoonlijke PI-ingestie of runtime-omschakeling toe: AuraDB Free en de tijdelijk gedeelde staging/production-instance zijn acceptatie-infrastructuur. Persoonlijke data wacht op gescheiden graphstores, tenant- en lifecycle-evals en bewezen rollback.

29.2 Productarchitectuur: één werkplaats, gescheiden engines

De PI-projectwerkplaats wordt op termijn een gespecialiseerde modaliteit van Frontdesk. Dit voorkomt dubbele project-, upload-, bron-, rechten-, kosten-, job-, audit- en reviewbediening. Frontdesk is de primaire gebruikersomgeving voor het verzamelen, ordenen, ontwerpen en vrijgeven van input; zij is niet zelf de filosofische engine.

De verantwoordelijkheden zijn:

De eerste technische koppeling mag 1-op-1 zijn: een bestaand pi_project wordt aan één Frontdeskproject en één LOBE-corpusbinding gekoppeld. De PI-tabellen blijven tijdens de migratie de specialistische domeinbron. Een latere consolidatie mag pas plaatsvinden nadat objectidentiteit, rechten, lifecycle en rollback end-to-end bewezen zijn.

29.3 Epistemisch contract

PI-II moet minimaal onderscheid bewaren tussen:

1. tekstueel gevonden gegeven — expliciet in een exacte bronpassage;
2. graafafleiding — volgt uit opgeslagen, inspecteerbare graphstappen;
3. interpretatieve hypothese — een modelmatige duiding die niet als bronfeit geldt;
4. productvoorstel — een mogelijke methode-, persoonlijkheids- of modulewijziging die review vereist.

fit, support, counter_support, explicitness en evaluation_status blijven afzonderlijke dimensies. Een hoge begripsfit is geen bewijs; veel steun sluit tegenbewijs niet uit. Type-, relation-, attribution-, pattern- en schema-decision-ID's zijn blijvend traceerbaar. Lifecycle, temporele geldigheid, gevoeligheid, access policy en Frontdesk/Data Map-herkomst reizen met ieder relevant object mee.

LOBE levert een vraagafhankelijke projectie en nooit de volledige betekenis van een project. De permanente PI-wereldkaart, integratieve synthese en denkcultuur blijven daarom naast LOBE bestaan. LOBE-context kan die laag voeden en controleren, maar mag haar niet vervangen door een toevallig queryresultaat. De projectbrede synthese blijft bovendien nodig om delen te begrijpen: lokale analyse krijgt een corrigeerbaar geheelsperspectief, waarna nieuwe lokale bevindingen opnieuw in de wereldkaart worden geïntegreerd.

29.4 Gepinde waarheid en storingsgedrag

Tijdens shadow blijft de bestaande actieve immutable PI v0.4-versie de enige runtimewaarheid. Iedere binding bewaart minimaal:

• project- en eigenaar-id;
• gepinde PI-versie, synthese-id en basisfingerprint;
• Frontdeskproject, LOBE-corpus en geaccepteerde ingestierun, voor zover zij werkelijk gekoppeld en geverifieerd zijn;
• graph-, adapter-, contextcompiler-, provenance-, migratie- en extractiepromptversies plus het readinesssignaal;
• de Azure-ingesttask/provider/policy-pins;
• migratiestatus en laatste geldige shadowrun;
• expliciete runtimebron: pi_v04_pinned.

Bij een LOBE-storing, ontbrekende bron, contractmismatch, autorisatiefout of onvolledige context blijft de gepinde PI-view beschikbaar. De LOBE-kant wordt stale of degraded getoond; zij levert niets aan chat en vult niets in. Een leeg resultaat is geen bewijs dat een concept niet bestaat. Een oude graphprojectie mag niet als actueel worden gepresenteerd.

29.5 Bronnen en crosswalk

Herindexering begint altijd bij de originele toegestane bronmanifesten. Losse v0.4-triples, synthesezinnen of embeddings zijn geen vervangende bron. Per bron en hoofdstuk bewaart de migratiecrosswalk:

• legacy PI-source- en section-id;
• originele user_doc_id, versie/digest, corpusrol en reviewstatus;
• verwachte of werkelijke LOBE source/document/version/digest/chunk/passage/span-id's;
• mappingstatus planned, mapped, unmapped, conflict, superseded of tombstoned;
• reden, verificatietijdstip en run-id.

unmapped is een geldige zichtbare uitkomst en mag niet door een gok worden vervangen. Een gewijzigde digest vereist een nieuwe bronrevision. Verwijdering of deactivatie moet zowel PostgreSQL- als graphlifecycle volgen, zonder historische audit, cost records of de oude gepinde PI-versie te vernietigen.

29.6 Shadow- en dual-runproces

Het migratiepad is bindend:

1. pin bestaande PI-versies, syntheses, audits, usage/cost records en bronverwijzingen;
2. maak een manifest uit originele toegestane bronnen;
3. leg de legacy-naar-LOBE-crosswalk vast, inclusief unmapped;
4. laat Frontdesk uitsluitend gereviewde en rechtmatig bruikbare bronnen indexeren in een daarvoor toegestane graphomgeving; de huidige gedeelde acceptance-store is niet geschikt voor persoonlijke PI-data;
5. voer dezelfde vooraf vastgelegde evaluatievragen uit tegen v0.4 en LOBE;
6. bewaar beide resultaten, traces, kosten en latency zonder de readroute te wijzigen;
7. laat nieuwe typen, conflicten en resolution/mergevoorstellen beoordelen;
8. pin de exacte contract-, corpus- en contextcompilerversie;
9. maak pas na alle productiongates een afzonderlijk cutoverbesluit;
10. houd rollback naar de oude gepinde PI-versie aantoonbaar uitvoerbaar.

Een shadowrun heeft een eigen stabiele run-id en registreert minimaal customer_id, task_id, derived_result_id, PI-project/version/synthesis, LOBE corpus/ingest/querytraces, provider/model, input-/outputtokens, ruwe en doorberekende kosten en duur. Privétekst, prompts en volledige contextpackages staan niet in het auditlog.

29.7 Evaluatiematrix en stopvoorwaarden

Iedere dual-run wordt op dezelfde fixturevragen vergeleken. Minimaal worden gemeten:

Automatische metrics zijn diagnostisch, niet beslissend voor filosofische juistheid. Relatiejuistheid, denkcultuur, begripsvarianten en passende toepassing vereisen een geblindeerde menselijke rubric. De eerder vastgelegde scriptiescenario's vormen de eerste inhoudelijke evalset zodra de bron werkelijk is verwerkt.

Een modelgestuurde evalrun geldt alleen als providerbewijs wanneer de usage- en runlineage exact task=lobe_ingest_extract, llm_provider=azure_openai en provider_policy=azure_openai_only vermeldt. Directe OpenAI, Mistral of een onbekende provider maakt de run ongeldig als PI-II-providerbewijs; dit is een harde stop en geen aanleiding voor een stille of gedegradeerde fallback.

29.8 Autorisatie en verplichte bronwhitelist

De huidige LOBE-adminquery accepteert een lege allowed_source_uids-lijst als alle corpusbronnen. PI-II mag die semantiek nooit overnemen. Iedere persoonlijke PI-query vereist een niet-lege, server-side uit eigenaar/projectrechten afgeleide whitelist. Clientinput mag die lijst alleen verder verkleinen, nooit uitbreiden.

In het adapterrequest staan de stabiele logische allowed_source_ids. De server vertaalt die uitsluitend via de geverifieerde crosswalk naar concrete LOBE source_uid-waarden. Het antwoord wordt daarna opnieuw tegen precies die UID-set gecontroleerd. Een ontbrekende of ambigue vertaling blokkeert de query; bron-id en source-UID zijn dus niet onderling uitwisselbaar.

Voor een shadowrun gelden bovendien:

• ownercontrole op project én iedere originele bron;
• live handoffreadiness en alle LOBE-contract-, provenance-, migratie- en compilerpins moeten exact overeenkomen;
• de LOBE-corpusowner en eventuele Frontdeskprojectowner moeten met de PI-eigenaar overeenkomen;
• persoonlijke uitvoering blijft geblokkeerd zolang geen afzonderlijke graphstore en positieve tenant/lifecycle/rollback-attestatie zijn vastgelegd;
• geen automatische scheduler voor persoonlijke LOBE-ingest;
• een handmatige, geauditeerde bevestiging per shadowrun;
• droom-/resolutionprocessen blijven uit tenzij afzonderlijk begrensd en beoordeeld.

29.9 PI-II-adaptercontract

De PI-zijde krijgt contract pi_lobe_shadow_v1. De eerste codevertaling mag alleen:

• developmentreadiness rapporteren;
• een gepinde migratiebinding en origineel bronmanifest voorbereiden;
• crosswalkrecords met zichtbare mappingstatus bewaren;
• shadowrun- en evalmetadata opslaan;
• een fail-closed runtimebesluit retourneren dat v0.4 gepind houdt;
• via dependency injection de echte interne LOBE-service uitsluitend read-only aanroepen voor handoffstatus en querycontext.

Zij mag niet:

• loadPiProjectRuntimeContext naar LOBE omschakelen;
• persoonlijke data automatisch indexeren;
• een lege bronwhitelist toestaan;
• een shadowresultaat canoniek maken;
• production-readiness, actualiteit of inhoudelijke superioriteit claimen.

Iedere binding en shadowrun pint daarnaast ingest_task=lobe_ingest_extract, llm_provider=azure_openai, provider_policy=azure_openai_only, lobe_provenance_v1, lobe_pi_shadow_migration_v1 en het vereiste readinesssignaal. Een ontbrekende of afwijkende pin blokkeert requestbouw én opslag. Er bestaat geen directe-OpenAI-, Mistral- of andere providerfallback, ook niet voor een test- of smoke-run.

De interne serviceadapter vertaalt het geldige lobe_adapter_v1-queryrequest naar queryCorpus, maar krijgt de concrete allowed_source_uids uitsluitend server-side uit de geverifieerde crosswalk. Hij mag geen lege whitelist doorgeven, geen corpus-id uit clientinput vertrouwen, geen graphwrite uitvoeren en geen volledige context of privépassage in PI-runlogs opslaan. De publieke PI-readiness- en statusroutes mogen alleen gesaneerde status, pins en blockers tonen.

De adapter accepteert alleen resultaten die lobe_v0.1, lobe_adapter_v1 en lobe_context_compiler_v1 verklaren, mutation_authority:none hebben en bewijsrefs met toegestane source UID, document/version/digest en passage/span leveren. Contractafwijking maakt de run degraded.

29.10 Frontdesk-overgang zonder functionele dubbeling

De huidige /pi-projects.html blijft tijdens development bestaan, omdat een UX-migratie tegelijk met een semantische graafmigratie de foutdiagnose onnodig vertroebelt. De eindrichting is:

1. Frontdesk toont projectdoel, bronnen, rechten, kosten, jobs en audit;
2. modaliteit PI-project / Capability Module opent specialistische panelen voor geheel–deel-synthese, concepten, methoden, projectstem, onzekerheden en evals;
3. hetzelfde Frontdeskproject kan een reviewed pi_knowledge_file opleveren;
4. LOBE indexeert dat bestand en de toegestane originelen met behoud van afzonderlijke provenance;
5. PI-II compileert de permanente wereldkaart plus vraagafhankelijke LOBE-context;
6. activering blijft een apart PI-versie- en capabilitybesluit.

Er komt geen tweede generieke uploader, rechteneditor, kostenteller of auditviewer in PI. Andersom worden de filosofische synthese- en persoonlijkheidsfuncties niet generiek in Frontdesk gekopieerd.

Aanvulling 2026-07-26: deze overgang gebruikt het gedeelde Kennisprojectcontract. PI-project wordt een Perspective-domeinprojectie op hetzelfde Frontdeskproject; teamleden, deliberation cases, releases en kanalen worden niet opnieuw als PI-specifieke generieke objecten gebouwd. De definitieve Frontdesk-werkvlakken Overzicht, Ingrediënten, Aandachtspunten, Proeven, Uitgaven, Team en Verantwoording staan in de overkoepelende Kennisprojecten-blauwdruk.

29.11 Productiongate

De Azure structured-output-ingest, bereikbaarheid vanuit Clever, production-HTTP-flow, providerpolicy en run-/kostenlineage zijn op synthetische acceptatiedata bewezen. Voor persoonlijke PI-runtime en volledige productiegereedheid blijven minimaal vereist:

• minimaal AuraDB Professional voor dagelijkse snapshots met zeven dagen retentie en productsupport; dit heeft geen availability-SLA;
• voor een vereiste 99,95% multi-zone-availability-SLA minimaal AuraDB Business Critical;
• afzonderlijke staging- en production-graphstores met gescheiden secrets voordat persoonlijke PI-data wordt verwerkt;
• een stagingacceptatie op de eigen staging-graphstore met dezelfde contract-, digest-, idempotency- en kostenlineage;
• tenant-, eigenaar-, project- en bronautorisatie, inclusief negatieve tests;
• niet-lege server-side bronwhitelists in iedere PI-query;
• volledige source lifecycle, tombstone en reindex over PostgreSQL en Neo4j;
• shadow-evals op de vaste PI-evalset, inclusief menselijke relatie- en denkkultuurreview;
• degrade/stale-presentatie zonder stille fallback;
• bewezen rollback naar de gepinde v0.4-versie;
• rotatie en verificatie van eventueel eerder blootgestelde graph- of providercredentials;
• afzonderlijk eigenaarbesluit voor runtimeactivatie.

Tot die tijd is de productionwaarheid: PI v0.4 blijft actief zoals gepind; LOBE voor persoonlijke PI is niet operationeel.

29.12 Implementatievolgorde en bewijsstatus

De developmentbouwvolgorde is:

1. dit canonieke ontwerp en de HTML-handleiding actualiseren;
2. additieve PI-II-binding-, crosswalk-, shadowrun- en evaltabellen maken;
3. pure contractvalidatie, manifestbouw, runtimepin en evaluatiefuncties bouwen;
4. owner-only status/planroutes toevoegen die geen graphwrite uitvoeren;
5. met een geïnjecteerde fake adapter bronwhitelist, contractmismatch, degraded state en rollback testen;
6. de exacte geaccepteerde LOBE-productioncommit samenbrengen met PI-II en een interne read-only serviceadapter bouwen;
7. live handoffreadiness, provenance-/migratiepins en concrete ingestusage fail-closed valideren;
8. inhoudelijke fixtures en menselijke rubric vastleggen en dual-read draaien zodra een daarvoor toegestane, gescheiden graphstore beschikbaar is;
9. tenant/lifecycle/rollback en de resterende productisatiepoorten afzonderlijk bewijzen.

Na de geaccepteerde overdracht mag de status shadow_service_integrated_personal_data_blocked worden gebruikt wanneer de serviceadapter, pins en deterministische tests groen zijn. Dat betekent: de echte LOBE-code is gekoppeld en synthetische graph-E2E/provideracceptatie is erkend, maar persoonlijke ingestie, persoonlijke shadowquery en runtimecutover staan nog uit. Geen developmentbewijs verandert automatisch de runtimepin.

29.13 Developmentimplementatie en bewijs 17 juli 2026

De stappen 1–5 uit §29.12 zijn in een geïsoleerde, niet-gedeployde PI-II-developmentbranch gebouwd:

• pi-lobe-shadow.js definieert pi_lobe_shadow_v1, de vier LOBE-versiepins, de Azure-ingesttask/provider/policy-pins, bronmanifest- en crosswalkbouw, read-only contextvalidatie, fail-closed runtimekeuze, vergelijkingsmetrics en gesaneerde opslag van runs, tokens, kosten en evals;
• requestbouw, shadowuitvoering en runopslag weigeren directe OpenAI, Mistral, onbekende providers en afwijkende providerpolicies; er is geen fallbackpad;
• pi_lobe_bindings, pi_lobe_crosswalk, pi_lobe_shadow_runs en pi_lobe_eval_results zijn als additieve tabellen ontworpen; tombstones worden niet stil heropend en een mislukte planopslag wordt zichtbaar degraded;
• GET /__pi_ii_lobe_readiness rapporteert developmentstatus en productionblockers zonder gebruikersdata;
• owner-only GET /api/pi/projects/:projectId/lobe-shadow toont plan, crosswalk, runs en de blijvende v0.4-runtimepin;
• owner-only POST /api/pi/projects/:projectId/lobe-shadow/plan pint alleen een bestaande actieve PI-versie en geaccepteerde synthese, bouwt het manifest uit originele PI-bronrecords en doet geen graphwrite;
• het bestaande technisch-adminoverzicht neemt dezelfde shadowstatus op voor monitoring, zonder een uitvoerknop toe te voegen;
• er is bewust geen HTTP-uitvoerroute voor persoonlijke LOBE-ingest of query toegevoegd;
• loadPiProjectRuntimeContext is niet gewijzigd en injecteert geen LOBE-context.

Automatisch bewijs:

• npm run test:pi:lobe-shadow is groen voor production-fail-closed-readiness, Azure-only provider- en policypins, afwijzing van directe OpenAI en Mistral, versie-/synthesepins, originele bronmanifesten, SHA-256-digests, crosswalk, tombstonegrens, verplichte logische bron-ID’s én concrete source-UID’s, contractmismatch, read-only evidence, spans, dangling evidence, stale/degraded fallback, menselijke reviewgates, token-/kostenvastlegging en uitsluiting van passage-inhoud uit runopslag;
• het gegenereerde PI-queryrequest is rechtstreeks door de werkelijk overgedragen lobe_adapter_v1-Zodvalidator geaccepteerd;
• npm run test:pi:v04 blijft volledig groen, zodat synthese, niet-graph-hardening en bestaande PI-projectcontracten niet zijn veranderd;
• de publieke HTTP-suite is na het starten van de vereiste lokale server groen: vijftien publieke checks geslaagd en tien expliciet token-/write-afhankelijke checks overgeslagen;
• de eerste aanroep van die HTTP-suite zonder server leverde uitsluitend fetch failed; na correcte harnasstart waren dezelfde tests groen;
• er was geen lokale PostgreSQL-configuratie. Echte schema-idempotentie en owner-HTTP-routes tegen een database zijn daarom nog niet als live bewezen geregistreerd.

Deze historische eerste PI-II-bouw was development_contract_built_azure_pending. De provider- en graph-E2E-pendingstatus is daarna door de Azure/AuraDB-productionacceptatie vervangen; de code- en testaanpassingen daarvan staan in §29.14. De eerdere Mistral-smoke blijft expliciet geen provideracceptatie.

29.14 Geaccepteerde LOBE-overdracht en tweede shadowfase

De tweede shadowfase begint vanaf exact LOBE-commit 3c642d1e178afbd9876f95a391f0aaf057897b83 en kent twee afzonderlijke waarheden:

1. Infrastructuuracceptatie: Azure OpenAI, Clever PostgreSQL, AuraDB, Frontdesk-review, graphmaterialisatie, retrieval, exact evidence-span en kostenlineage zijn met synthetische data werkelijk bewezen.
2. Persoonlijke PI-acceptatie: nog niet bewezen en daarom uitgeschakeld; de gedeelde AuraDB Free-instance mag niet stil tot persoonlijke productiestore worden verheven.

De implementatie moet daarom de echte LOBE-service kunnen herkennen en read-only aanspreken, alle zes LOBE-versiepins plus providerpolicy valideren en dual-readresultaten opslaan, terwijl loadPiProjectRuntimeContext uitsluitend v0.4 blijft gebruiken. Een query kan pas worden uitgevoerd wanneer corpus, ingestierun, eigenaar, source-digests, crosswalk en niet-lege concrete source-UID-whitelist server-side zijn bewezen. Tot de gescheiden graphstores en tenant/lifecycle/rollbackpoorten groen zijn, rapporteert de adapter wel technische beschikbaarheid maar personal_data_execution_enabled:false.

Deze tweede fase is vóór vrijgave in de lokale PI-II-branch als volgt vertaald:

• exact LOBE-releasecommit 3c642d1e178afbd9876f95a391f0aaf057897b83 is met de PI-II-branch samengebracht; de latere wijziging ten opzichte van d1419ea betreft uitsluitend de correcte AuraDB-tierdocumentatie;
• PI pint nu ook lobe_provenance_v1, lobe_pi_shadow_migration_v1 en production_graph_e2e_accepted_pi_shadow_ready en vergelijkt die met de echte lobeHandoffContract;
• de interne adapter valideert ieder request eerst met de echte lobe_adapter_v1-schema-validator en vertaalt het daarna read-only naar queryCorpus;
• publieke readiness doet geen live graphprobe; owner- en adminstatus mogen de live handoff gesaneerd controleren;
• ingestacceptatie vereist een gereed corpus, voltooide gepinde run, overeenkomende eigenaar/Frontdeskscope, Azure-only usage, gevonden niet-geschatte pricing en complete customer/task/resultaat-lineage;
• queryuitvoering vereist mapping_status=mapped, complete source/document/source-UID-identiteit en gelijke PI- en LOBE-SHA-256-digests;
• de uitvoerguard vereist tegelijk manual_shadow, een geattesteerde gescheiden graphstore, tenant/lifecycle-attestatie, gepinde rollbackbasis en eigenaarstoestemming;
• er is nog steeds geen persoonlijke ingest- of query-HTTP-route toegevoegd en de chatruntime is niet gewijzigd.

Automatisch bewijs is groen voor npm run test:pi:lobe-shadow, npm run test:lobe:v01 en npm run test:pi:v04. Dit bewijst contractkoppeling, fail-closed guards en regressievrijheid, niet dat een persoonlijk PI-project al in een gescheiden graphstore is verwerkt. De actuele PI-II-status is daarom shadow_service_integrated_personal_data_blocked wanneer de live handoff gezond is; anders blijft de status expliciet unverified/degraded terwijl v0.4 gepind blijft.

29.15 Vrijgavebewijs PI-II LOBE-shadow — 17 juli 2026

De PI-II-code is na de LOBE-overdracht vrijgegeven als exact releasecommit 35e60c6d253fc9f83a9364d665f1648c6ce0a3a8. Die commit bevat featurecommit 91db43e en de ongewijzigd opgenomen LOBE-release 3c642d1e178afbd9876f95a391f0aaf057897b83. De unieke live buildmarker is gritt-pi-project-v0.4-lobe-shadow-2026-07-17-01.

Voor iedere omgeving is een afzonderlijke schone tijdelijke clone van de eigen Clever-remote gebruikt. Zowel staging als production stond vooraf exact op 3c642d1e178afbd9876f95a391f0aaf057897b83, kon met --ff-only naar de releasecommit worden bijgewerkt en bleef schoon. In beide clones waren vóór push groen:

• git diff --check;
• node --check server.js, node --check pi-lobe-shadow.js en node --check pi-project-routes.js;
• npm run test:pi:lobe-shadow;
• npm run test:lobe:v01;
• npm run test:pi:v04.

npm ci --ignore-scripts rapporteerde in beide clones tevens twaalf bestaande dependencybevindingen: zes middel, vijf hoog en één kritiek. Deze zijn niet automatisch met npm audit fix of een breaking dependencyupgrade gewijzigd binnen de PI-II-release; zij blijven een afzonderlijk securityonderhoudspunt.

Staging is eerst gepusht naar app_86d547f1-23bd-44a1-927f-f5d92a1b4783; Clever bevestigde expliciet dat de applicatie voor redeploy was gequeued. Pas nadat de nieuwe buildmarker live zichtbaar was, zijn de staging-smokes uitgevoerd. Daarna is exact dezelfde commit naar productionapp app_dff1b783-69d4-460b-80a7-aa7a51ab160a gepusht, opnieuw met expliciete queuebevestiging van Clever.

De live read-only-smokes op staging, https://gritt.chat en https://face.mindyouraxis.com bewezen:

• HTTP 200 voor /health, /__build_marker, /__pi_v04_readiness, /__pi_ii_lobe_readiness, /pi-projects.html, /pi-blueprint.html en /admin-pi.html;
• overal dezelfde nieuwe buildmarker;
• PI v0.4-schema 5 zonder ontbrekende tabellen of kolommen, non_graph_hardening:true, een actieve scheduler en beschikbare embeddingprovider;
• PI-II met adapter beschikbaar, alle LOBE-, provenance-, migratie-, Azure-provider- en policy-pins correct, personal_data_execution_enabled:false en runtime_source:pi_v04_pinned;
• de ownerlijst zonder token afgesloten met HTTP 401 en het LOBE-adminstatuspad zonder admincontext afgesloten met HTTP 403.

De publieke PI-II-readiness doet volgens ontwerp geen live graphprobe en rapporteert daarom shadow_service_integrated_live_status_unverified, adapter_ready:false en pi_lobe_live_handoff_not_checked. Dat is geen deployfout en ook geen productionclaim: een owner- of adminstatusaanroep kan de live handoff wel gesaneerd verifiëren, maar voor deze vrijgave was geen geldige token in de deployomgeving aanwezig. Er zijn tijdens de smokes geen projecten, bronnen, bindings, crosswalks, graphrecords, jobs of andere gebruikersgegevens gemaakt of gewijzigd.

De operationele conclusie na deze vrijgave blijft dus begrensd: de echte LOBE-service en PI-II-shadowcontracten zijn in staging en production geïntegreerd; persoonlijke PI-ingestie, persoonlijke shadowquery en runtimecutover blijven geblokkeerd totdat de poorten uit §29.11 aantoonbaar groen zijn.

29.16 Relatie met Interactional Memory — 18 juli 2026

De productbrede Interactional Memory-basis uit §1 is als technisch contract user_memory_v0.1 gebouwd en voor user 2 gecontroleerd op production geactiveerd. De runtime gebruikt een toekomstgerichte activeringsgrens, een Azure-only achtergrondqueue, PostgreSQL als gezaghebbende claimlaag en een LOBE-projectie met begrensde lexicale fallback. De beheerlaag interactional_memory_admin_v0.1 voegt geaudite testinspectie, claimcontrole, opslaglimieten en meettimers toe, maar maakt IM-data niet tot PI-data. De tijdelijke production-isolatiemodus is logical_test; stagingverwerking blijft uit totdat zij een fysiek eigen Neo4j-store heeft.

Dit verandert de PI-II-grens niet. IM is algemene, herzienbare gesprekscontext; PI blijft de expliciet gekozen filosofische capability met canonieke projectversies, wereldkaart, synthese, review en eigen runtimecontract. Een latere PI-runtime mag alleen reeds door het IM-contract geselecteerde context benutten wanneer beide functies effectief aan staan. Zij mag herinneringen niet automatisch tot PI-corpus, conceptclaim, onderzoeksbijdrage of persoonlijkheidswaarheid verheffen. Omgekeerd mag IM geen PI-wereldkaart of projectbrede synthese kopiëren als claim over de gebruiker.

29.17 PI-reasoningexperiment en fail-closed lege uitvoer — 20 juli 2026

Een productionproef liet zien dat een Azure Responses-aanroep exact haar ingestelde grens van 3.000 uitvoertokens kon bereiken. Bij een reasoningmodel omvat max_output_tokens zowel zichtbare JSON als niet-zichtbare reasoningtokens. Een syntactisch normaliseerbaar maar inhoudelijk leeg resultaat mocht daardoor ten onrechte als review eindigen. Deze toestand is geen review: zij bevat geen analyse die een eigenaar inhoudelijk kan beoordelen.

Vanaf dit contract geldt daarom de invariant empty_model_extraction. Een lokale sectieanalyse heeft minimaal een betekenisvolle samenvatting en één inhoudelijk analyseobject of open vraag nodig. Een voorlopige of integratieve synthese heeft minimaal een narratieve synthese, een expliciete gebruikte sectiescope en conceptuele structuur nodig. De controle vindt plaats vóór oude voorstellen worden verwijderd, nieuwe voorstellen worden geschreven of een sectie/synthese review krijgt. Een lege uitvoer faalt terminaal met foutcode empty_model_extraction; de identieke begrensde aanroep wordt niet automatisch meermaals op gebruikerskosten herhaald. Providergebruik en kosten van de mislukte aanroep blijven wel volledig geregistreerd.

Daarnaast loopt een expliciet en reversibel reasoningexperiment met twee adminstanden:

hybrid is een hypothese, geen bewezen kwaliteitswet. Het uitgangspunt is dat expliciete, schemagebonden extractie vooral nauwkeurige ruimte voor zichtbare JSON nodig heeft, terwijl synthese, interpretatie en kritiek meer redeneerruimte kunnen rechtvaardigen. De beheerinstelling is alleen op PI-taak-ID's van toepassing. Chat, FUGA, Frontdesk-LOBE, Interactional Memory en andere taken houden hun bestaande reasoningbeleid. PI blijft Azure OpenAI-only. Per aanroep worden taak, effectieve effort, beleidsstand, deployment, tokens, kosten en request-ID geregistreerd, zodat dezelfde fixtures later op volledigheid, brontrouw, structuur, truncatie, latency en prijs kunnen worden vergeleken.

De normale PI-aanroepen gebruiken de Azure Responses-deployment die door de PI/JSON-router is geselecteerd — standaard de Azure chat/JSON-deployment — en niet automatisch de Global-Batch-deployment gritt-lobe-batch. De in Foundry getoonde limiet van 250.000 tokens voor gritt-lobe-batch is een limiet op gelijktijdig in de batchwachtrij geplaatste invoertokens. Zij is geen per-response uitvoerlimiet en verklaart de 3.000-tokenafbreking niet. De 3.000-grens is een afzonderlijke, door GRITT gebudgetteerde PI-jobgrens. Een latere wijziging daarvan vereist een eigen kosten- en kwaliteitsevaluatie; zij wordt niet stil gekoppeld aan een Azure-quota-aanpassing.

29.18 Gecontroleerde vergelijking hybrid versus high — 20 juli 2026

Doel en afbakening

De vergelijking onderzocht niet of “meer output” automatisch beter is, maar of meer redeneerruimte bij de expliciete PI-extractiefase aantoonbaar betere, brongetrouwe en bruikbare structuur oplevert. De test gebruikte één volledig synthetische bron zonder persoonsgegevens, SHA-256 7040ff63b287df1abf8e786c5352b586017f909ea3010841c74199a72738638c. De bron definieert handelingsvermogen, onderscheidt vier deelbegrippen, geeft een vijfstappenmethode, twee hypothesen, tegenbewijs, een alternatieve interpretatie en expliciete acceptatie- en veiligheidszinnen.

Voor iedere stand is een vers project zonder bestaande graph gebruikt. Titel, projectomschrijving, broninhoud, sectie-indeling, Azure-providerroute, structured-outputschema en uitvoerbudget waren gelijk. Alleen het PI-reasoningbeleid verschilde:

• hybrid: preliminary synthesis op medium en sectie-extractie op low;
• high: preliminary synthesis en sectie-extractie beide op high.

De primaire vergelijking stopt na de eerste preliminary synthesis en eerste sectie-extractie. Latere integratieve en gerichte heranalyses zijn afzonderlijk gerapporteerd, omdat zij de graph zelf opnieuw kunnen veranderen en daardoor geen zuivere vergelijking van de initiële extractiestand zijn. Alle genoemde modelkosten zijn ruwe Azure-modelkosten vóór de klantfactor.

Er zijn belangrijke beperkingen. Het betreft één korte synthetische bron, één run per beleidsstand en een niet-deterministisch model. De hybride run draaide op PI-build v0.3; de high-run op v0.5, nadat twee fail-closed synthesecorrecties waren toegevoegd. Die correcties betroffen iteratiebegrenzing en echte sectie-ID's en veranderden niet doelbewust de lokale sectie-extractieprompt, maar volledige gelijkheid van de softwareversie is daarom niet geclaimd. Deze proef is richtinggevend, niet statistisch generaliseerbaar.

Kwantitatieve uitkomst

Voor beide runs zijn alle expliciete bronclaims en alle node- en edge-ankers programmatisch gecontroleerd. Hybrid had 10/10 expliciete conceptankers en 5/5 expliciete relatieankers; high 12/12 en 5/5. Alle 12 respectievelijk 18 concepten en alle 10 respectievelijk 14 relaties verwezen naar een bestaande, geverifieerde span. Geen van beide initiële graphs bevatte dubbele labels, dangling edge-referenties of een als expliciet gemarkeerde claim zonder geverifieerd bewijs. Dit bewijst provenance-integriteit, niet automatisch een goede conceptuele indeling.

Inhoudelijke beoordeling van de extra high-structuur

Negen labels kwamen exact in beide runs terug: handelingsvermogen, relationeel vermogen, reflectieve helderheid, feitelijke handelingsruimte, ervaren legitimiteit, corrigerende terugkoppeling, betwistbaarheid, terugkeerpunt en legitimiteitskritiek. Hybrid had daarnaast drie eigen formuleringen; high negen. Het nettoverschil van zes nodes is daarom geen eenvoudige verzameling van zes onbetwistbare nieuwe inzichten.

De negen high-specifieke of anders opgesplitste elementen zijn als volgt beoordeeld:

De extra high-relaties laten hetzelfde gemengde beeld zien. De relaties tussen methode, doel, lineaire optimalisatie, terugkeerpunt en bewijskader voegen werkelijke methodologische structuur toe. Daartegenover stonden:

• acceptatie-anker instance_of terugkeerpunt, gebaseerd op een

testharnasformulering en daardoor geen gewenste domeinrelatie;

• diagnoseverbod applies_to reflectieve helderheid, terwijl de bron de grens

op alle onderscheiden concepten toepast en de edge dus te smal is;

• terugkeerpunt supports stopvoorwaarde, waarvan richting en relatietype

betwistbaar zijn omdat een stopvoorwaarde het terugkeerpunt juist operationaliseert;

• ervaren legitimiteit supports feitelijke handelingsruimte, een plausibele

contextuele lezing die echter normatieve zekerheid en materieel-institutionele ruimte te gemakkelijk kan vermengen.

Hybrid was evenmin foutloos: terugkeerpunt instance_of corrigerende terugkoppeling is waarschijnlijk te sterk en de node betwistbaarheid zonder reputatieschade kan beter als gescopeerde variant of voorwaarde van betwistbaarheid worden gemodelleerd. Hybrid behield wel de zelfstandige factor tijdsdruk en scheidde de evaluatie van geslaagde toepassing als methodekaart.

De inhoudelijke conclusie is daarom preciezer dan “high vindt meer”:

• high verhoogde recall en vond meerdere waardevolle onderscheiden;
• een relevant deel van de extra output was categorieverschuiving,

cross-family-duplicatie, een te smalle relatie of een testartefact;

• hybrid was compacter en goedkoper, maar liet enkele nuttige methodologische en

scopeonderscheiden liggen;

• beide standen hadden volledige bronankers, maar geen van beide bewees al

optimale graphmodellering.

Iteratieve kosten en foutvondsten

De eerste volledige high-cyclus vroeg tweemaal gerichte heranalyse en stopte daarna aantoonbaar op integratie-iteratie 3. De zeven jobs van preliminary, initiële extractie, drie integraties en twee heranalyses kostten samen € 0,17887 raw. Dit bedrag meet vooral de gekozen heranalysecyclus en mag niet als zuivere “high-premie” worden gepresenteerd. De vergelijkbare hybride driejobsroute kostte € 0,06788 raw, maar bevatte geen gelijk aantal heranalysestappen en één leaseherhaling; ook dit is dus geen zuivere A/B.

De productionproef vond en corrigeerde drie fouten:

1. gerichte heranalyse wijzigde de basisvingerafdruk en zette daardoor de

integratie-iteratie steeds terug op 1; iteraties lopen nu begrensd 1→2→3;

2. het syntheseschema gaf een hardgecodeerd voorbeeld met section_id:1;

iedere prompt gebruikt nu uitsluitend de werkelijk toegestane database-ID's;

3. administratieve goedkeuring van inhoudelijk ongewijzigde sectieanalyse

veranderde de basisvingerafdruk en kon een review-heranalyselus veroorzaken; de vingerafdruk bevat nu de inhoud van analysis_json, niet de goedkeuringsstatus of wijzigingsdatum. Heranalyse invalideert, louter goedkeuren niet; afwijzen blijft inhoudelijk en invalideert wel.

Lege of scopestrijdige modeluitvoer faalde in deze proef bovendien zoals bedoeld met empty_model_extraction en werd niet als review geaccepteerd.

Besluit en vervolgbenchmark

hybrid blijft voorlopig de standaard omdat het goedkoper en minder category-polluting was, maar dit is geen definitief kwaliteitsoordeel. high blijft een expliciete vergelijkingsstand en kan waardevol zijn voor inhoudelijk dichte, methodologische of filosofisch ambigue passages. Voordat één stand definitief wordt gekozen is een herhaalde benchmark nodig met:

• meerdere vaste bronnen in verschillende talen en genres;
• minimaal drie herhalingen per stand;
• een vooraf vastgelegde menselijke goldset van begrippen, senses,

constraints, methoden en relaties;

• precision/recall per nodefamilie, niet alleen totaaltellingen;
• duplicatie-, category-fit-, edge-direction- en relation-typefouten;
• retrieval recall en antwoordkwaliteit op vragen die de extra high-elementen

daadwerkelijk nodig hebben;

• brontrouw, onbewezen claims, latency, tokens en kosten;
• blinde menselijke beoordeling zonder kennis van de reasoningstand.

Een redelijke vervolgrichting is taakafhankelijk: hybrid voor eerste schema-extractie en high als selectieve enrichment-/kritiekpass wanneer kwaliteitswaakhond, documentcomplexiteit of retrieval-evals aantonen dat de compacte graph relevante onderscheiden mist. Zo wordt extra redenering ingezet op gemeten informatiewinst, niet op het onbetrouwbare criterium “meer nodes is beter”.

29.19 Herhaalde same-build A/B en herbeoordeling van de +50%/+40% — 20 juli 2026

Waarom een tweede proef nodig was

De eerste proef uit §29.18 liet bij high 50% meer begrippen en 40% meer relaties zien. Die uitkomst mocht niet rechtstreeks als beleidseffect worden geïnterpreteerd: er was één run per stand, het model is niet-deterministisch en de twee runs waren niet op exact dezelfde PI-build uitgevoerd. De vraag was daarom tweeledig:

1. reproduceert high de hogere aantallen op dezelfde softwarebuild;
2. waren de eerder extra gevonden elementen inhoudelijk waardevol, ook wanneer

het aantalverschil niet reproduceerbaar blijkt.

Protocol

Er zijn vier nieuwe productionprojecten aangemaakt: twee onafhankelijke herhalingen onder hybrid en twee onder high. Alle vier gebruikten:

• dezelfde PI v0.4-productionbuild en databaseschema 5;
• dezelfde Azure OpenAI Responses-route en deployment;
• exact hetzelfde synthetische brondocument en bronhash

7040ff63b287df1abf8e786c5352b586017f909ea3010841c74199a72738638c;

• één identieke bronssectie;
• hetzelfde structured-outputschema, dezelfde temperatuurinstellingen en

hetzelfde uitvoermaximum van 8.000 tokens per job;

• een lege projectgraph zonder eerdere begrippen, relaties of syntheses;
• dezelfde volgorde: preliminary synthesis, daarna sectie-extractie.

Het enige bedoelde verschil was het reasoningbeleid:

De primaire snapshot is direct na de twee extractiejobs vastgelegd en vóór een volgende integratieve cyclus. Latere integratiekosten zijn niet in onderstaande kostentabel opgenomen. De testprojecten zijn daarna gearchiveerd; het actieve PI-project en de productionstand hybrid zijn hersteld.

Ruwe herhalingsresultaten

Binnen deze same-build-herhaling produceerde high gemiddeld dus niet meer, maar 11,8% minder conceptnodes en 8,3% minder edges. Per paar liep de richting sterk uiteen:

• herhaling 1: high had 29% minder begrippen en 31% minder relaties;
• herhaling 2: high had 6% meer begrippen en 18% meer relaties.

Ook de onderlinge labelstabiliteit was vrijwel gelijk en laag: de exacte Jaccard-overlap tussen de twee hybrid-runs was 0,42; tussen de twee high-runs 0,43. High was dus niet aantoonbaar consistenter of systematisch uitgebreider. Het model verdeelde dezelfde inhoud per run anders over begrippen, methoden, hypothesen en zelfmodelitems.

De doorlooptijd bevestigde evenmin een stabiel snelheidseffect. Drie van de vier preliminary jobs duurden circa 18–22 seconden; hybrid 1 had een eenmalige provider-/runtime-uitbijter van circa 259 seconden. De sectie-extracties duurden circa 17–23 seconden. Wachtrijtijd is hierbij niet als modeldoorlooptijd geteld.

Structurele en bronmatige controles

Over de vier runs zijn 64 conceptnodes en 46 edges geïnspecteerd:

• 64/64 conceptnodes hadden een bestaande, exact geverifieerde bronspan;
• 46/46 edges hadden een bestaande, exact geverifieerde bronspan;
• er waren geen exacte dubbele labels binnen een run;
• er waren geen dangling edges;
• geen van de vier extractiejobs eindigde leeg, afgekapt of als stilzwijgende

review;

• empty_model_extraction bleef het fail-closed pad voor lege uitvoer.

Dat bewijst dat beide standen bronmatig valide structuur kunnen leveren. Het bewijst niet dat ieder element op de beste abstractielaag of in de juiste nodefamilie terechtkomt. Dat onderscheid is juist belangrijk voor de inhoudelijke beoordeling.

Retrospectieve inhoudsdekkingscontrole

Als aanvullende diagnose is een rubric met twaalf broneenheden gebruikt:

1. handelingsvermogen als relationeel vermogen;
2. reflectieve helderheid tegenover feitelijke handelingsruimte;
3. ervaren legitimiteit als afzonderlijke factor;
4. corrigerende terugkoppeling;
5. betwistbaarheid zonder reputatieschade;
6. terugkeerpunt;
7. de vijfstappenmethode;
8. gecontroleerde beweging tegenover lineaire optimalisatie;
9. optieaanbod plus tijdsdruk/blokkering;
10. legitimiteitskritiek tegenover feitelijke risicoverdeling;
11. synthetische bronstatus en het diagnoseverbod;
12. de casusstructuur van beperkte lancering, veiligheidsreview en

stopvoorwaarde.

Een eenheid telde als gedekt wanneer zij aantoonbaar voorkwam in een concept, edge, methode, hypothese of zelfmodelitem; exacte labelgelijkheid was niet vereist. De uitkomst was 12/12 en 12/12 voor hybrid, 10/12 en 11/12 voor high. High 1 miste vooral de legitimiteitskritiek en de concrete casuscontrole; high 2 miste de casuscontrole als samenhangende structuur. Deze rubric is achteraf geformuleerd en door een niet-geblindeerde beoordelaar toegepast. Zij is daarom diagnostisch en geen onafhankelijk bewijs dat hybrid inhoudelijk superieur is. Voor een bevestigende benchmark moet de goldset vooraf worden bevroren en blind worden beoordeeld.

Waren de oorspronkelijke extra high-elementen dan waardeloos?

Nee. De correcte conclusie is nadrukkelijk niet dat de eerdere 50% extra nodes en 40% extra edges nutteloos waren. De inhoudsaudit uit §29.18 blijft geldig:

• collectief handelingsvermogen, stopvoorwaarde, het contrast met

lineaire optimalisatieprocedure en de explicitering van optieaanbod bevatten werkelijke informatiewinst;

• diagnoseverbod, bewijskader voor geslaagde toepassing en

gecontroleerde beweging onder onzekerheid waren eveneens relevant, maar stonden niet steeds in de juiste nodefamilie;

• perspectiefwisseling met terugkeerpunt werd tegelijk concept en methode en

was daarmee cross-family-duplicatie;

• acceptatie-anker was een testartefact en geen gewenst filosofisch begrip;
• enkele extra edges hadden een te smalle scope, discutabel relatietype of

omkeerbare richting.

Van de negen eerder high-specifieke elementen waren dus meerdere inhoudelijk waardevol. Slechts een deel was echter direct een goede extra conceptnode. De same-build-runs tonen bovendien dat zulke onderscheiden niet betrouwbaar door de stand high alleen worden veroorzaakt: hybrid vond in een nieuwe run zelf onder meer stopvoorwaarde, veiligheidsreview, legitimiteitskritiek en herzienbaarheid, terwijl high in een andere run juist betwistbare keuzeomgeving, kleine omkeerbare interventie en formeel veel bevoegdheid expliciteerde.

De beoordeling gebruikt daarom vier uitkomsten en niet de binaire keuze “behouden of weggooien”:

Dat onderscheid beschermt juist de mogelijk waardevolle extra recall van high. Een high-kandidaat die niet direct canoniek wordt, mag dus niet zonder spoor verdwijnen: hij blijft als herleidbare enrichmentkandidaat beschikbaar totdat family-fit, overlap, edge-richting en downstream retrievalwaarde zijn beoordeeld. Zo hoeft production niet te kiezen tussen een vervuilde graph en het verlies van een mogelijk relevant onderscheid.

Zekerheidsniveau van deze vergelijking

De huidige bewijskracht is voldoende om de universele claim “high geeft 50% meer begrippen en 40% meer relaties” af te wijzen. Zij is nog niet voldoende om te bewijzen dat hybrid op alle teksten inhoudelijk beter is. Daarvoor zijn de steekproef (n=2 per stand op één bron), de modelvariatie en de retrospectieve, niet-geblindeerde rubric te beperkt.

Drie uitspraken hebben daarom een verschillende status:

• Aangetoond in deze proef: beide standen leverden volledig geankerde

structuur; ruwe aantallen varieerden sterk; high reproduceerde de eerdere volumewinst niet.

• Sterk aannemelijk, nog te bevestigen: hybrid is een rationelere eerste

productionpass en high is nuttiger als gerichte enrichmentpass dan als globale standaard.

• Nog niet aangetoond: welke stand per genre en taal de hoogste

precision/recall en beste eindantwoorden geeft, en of een bepaalde extra high-node downstream noodzakelijk is.

De ontbrekende bevestiging vereist een vooraf geregistreerde benchmark met een bevroren goldset, geblindeerde dubbele annotatie, minimaal drie runs per conditie en gerichte vragen waarvan vooraf bekend is welk onderscheid of pad nodig is. Per extra kandidaat moeten minimaal worden gemeten: semantische nieuwheid, family-fit, bewijsintegriteit, relationele juistheid, retrievalbijdrage, antwoordbijdrage en kosten. Alleen daarmee kan later met statistische én inhoudelijke zekerheid worden vastgesteld hoeveel van de extra recall werkelijk waardevol is.

Geldige conclusie

De herhaalde proef weerlegt de stelling “high levert structureel 50% meer begrippen en 40% meer relaties”. Het eerdere percentage was een waargenomen runverschil, geen reproduceerbaar beleidseffect. Tegelijk weerlegt zij niet dat high incidenteel waardevolle extra onderscheiden kan vinden.

Daarom blijft het beleid:

• hybrid als productionstand voor efficiënte eerste extractie;
• high als expliciete experimentele of selectieve tweede lezing;
• geen promotie van high-output op grond van aantallen alleen;
• alleen opnemen wanneer een extra element brongetrouw, niet-duplicatief,

categoriek correct en aantoonbaar retrievalrelevant is;

• de definitieve vergelijking uitbreiden naar meerdere teksten, genres en

talen, met vooraf bevroren goldsets en downstream retrieval-/antwoordtests.

De betrouwbaarste toekomstige variant is waarschijnlijk geen globale keuze tussen “alles hybrid” en “alles high”, maar een gecontroleerde enrichmentpass: hybrid bouwt de eerste structuur; high onderzoekt alleen passages waar de kwaliteitswaakhond ontbrekende contrasten, lage dekking of grote interpretatieve spanning signaleert. Nieuwe high-elementen worden vervolgens tegen de bestaande families, bronspans en retrieval-evals getoetst voordat zij canoniek worden.

De production-A/B legde daarnaast een lifecycle-race bloot: een reeds lopende integratiejob kon na het archiveren van zijn testproject nog een vervolgjob inplannen. Archiveren blokkeert voortaan zowel vóór de queuebeslissing als atomair in de INSERT ... SELECT alle nieuwe achtergrondjobs. De bestaande inhoud van een gearchiveerd project blijft behouden; alleen nieuwe verwerking stopt. Dit verandert de gemeten reasoningresultaten niet, maar voorkomt dat een afgeronde benchmark later ongemerkt extra graphmutaties of kosten krijgt.