Toegang
Authenticatie, RBAC, least privilege en expliciete bevoegdheden worden afgestemd op de echte rollen in het proces.
Bekijk meer →
ENGINEERING & TRUST
Vertrouwen ontstaat uit zichtbare grenzen.
Engineering is voor Qavirio niet alleen code schrijven. Het gaat om eisen expliciet maken, verantwoordelijkheden begrenzen, wijzigingen controleerbaar houden en kunnen aantonen wat een release werkelijk doet. Security, audit, deployment en AI-governance horen daarom bij het ontwerp zelf.
add_filter('template_include', function ($template) {
if (is_admin()) return $template;
$slug = qavirio_requested_route_slug();
if ($slug === 'home') {
$front = QAVIRIO_THEME_DIR . '/front-page.php';
return is_readable($front) ? $front : $template;
}
$map = qavirio_route_template_map();
if ($slug && isset($map[$slug])) {
$candidate = QAVIRIO_THEME_DIR . '/' . $map[$slug];
if (is_readable($candidate)) return $candidate;
}
return $template;
}, 9998);DE BASIS
Vier lagen die niet pas aan het einde mogen verschijnen.
Bij een eenvoudige website zijn deze lagen kleiner dan bij métiersoftware of een departementaal platform, maar de vragen blijven dezelfde: wie mag wat, welke data is leidend, wat moet aantoonbaar zijn en hoe herstellen we wanneer iets misgaat?
Data
Bron, eigenaarschap, retentie en grenzen tussen gebruikers, tenants of contexten worden onderdeel van het ontwerp.
Bekijk meer →Evidence & audit
Belangrijke acties, statussen, releases en beslissingen moeten achteraf controleerbaar zijn zonder onnodig gevoelige inhoud te verzamelen.
Bekijk meer →Deployment
Omgevingsscheiding, backups, health checks, rollback en gecontroleerde releases horen bij het product, niet bij de laatste dag van het project.
Bekijk meer →VAN VRAAG NAAR RELEASE
Eerst vastleggen wat “goed” betekent. Daarna pas bouwen.
Een project begint niet met een frameworkkeuze, maar met een grens: welk probleem lossen we op, voor wie, met welke informatie en binnen welke verantwoordelijkheid? Die grens bepaalt de functionele scope en voorkomt dat software steeds groter wordt zonder dat de waarde evenredig toeneemt.
Voor kritieke functies leggen we acceptatiecriteria vast voordat de release als geslaagd wordt beschouwd. Dat kan gaan om een route die bereikbaar moet zijn, een rol die een bepaalde actie juist níet mag uitvoeren, een formulier dat foutief invoer weigert of een workflow die na een wijziging dezelfde uitkomst moet blijven geven.
- Scope en verantwoordelijkheden expliciet vóór implementatie.
- Acceptatie op gedrag, niet alleen op uiterlijk.
- Wijzigingen klein genoeg houden om te begrijpen en terug te draaien.
Wat hoort erbij — en wat niet?
Een duidelijke grens voorkomt stille scopegroei en maakt technische keuzes toetsbaar.
Wanneer noemen we dit PASS?
Vooraf bekende criteria maken reviews objectiever en regressies sneller zichtbaar.
Wie beslist en wie voert uit?
Menselijke verantwoordelijkheid blijft expliciet waar oordeel, autorisatie of risico speelt.
BEWIJS VOOR CLAIM
Een werkende demo is niet hetzelfde als een productieclaim.
Qavirio maakt onderscheid tussen experiment, candidate, pilot, released software en een specifieke productie-inzet. Dat is geen semantiek: elk niveau vraagt ander bewijs. Een intern geslaagde test is bijvoorbeeld waardevol, maar wordt niet gepresenteerd als externe certificering of klantacceptatie.
Die discipline geldt ook voor AI. Als een component observeert of adviseert, zeggen we niet dat hij zelfstandig uitvoeringsbevoegdheid heeft. Als een functie nog in qualification staat, blijft dat zichtbaar. Zo blijft commerciële communicatie in lijn met de technische werkelijkheid.
Lees over assurance en certificering →Expliciete uitkomst
Tests en gates leveren een benoemde uitkomst in plaats van een vaag “lijkt goed”.
Release-niveau zichtbaar
R&D, pilot en production worden niet door elkaar gebruikt.
Herleidbare wijzigingen
Versies, wijzigingen en relevante acceptatiechecks blijven terug te vinden.
AI MET GRENZEN
Observatie, advies en uitvoering zijn verschillende bevoegdheden.
In intelligente systemen willen we kunnen aanwijzen welke stap informatie verzamelt, welke stap redeneert of adviseert, welke policy van toepassing is en waar een mens beslist. Dat voorkomt dat “AI” één ondoorzichtige laag wordt waar alle bevoegdheden samenkomen.
Autonomie wordt daarom als expliciete capability behandeld. Toolgebruik, writes, externe acties en toegang tot gevoelige bronnen krijgen afzonderlijke grenzen. Een gesprek voeren en informatie ophalen is technisch en bestuurlijk iets anders dan een wijziging uitvoeren in een productieomgeving.
Informatie verzamelen
Read-only waar mogelijk en met duidelijke bron/context.
Redeneren en voorstellen
Output blijft advies totdat bevoegdheid expliciet is toegekend.
Uitvoering onder controle
Writes of acties alleen binnen vooraf gedefinieerde rechten, gates en audit.
DEPLOYMENT IS ENGINEERING
Live zetten is geen eindpunt. Het is een nieuwe bedrijfsfase.
Een systeem dat alleen in een ontwikkelomgeving werkt, is nog geen betrouwbare dienst. Daarom kijken we naar configuratie, omgevingsscheiding, secrets, backups, health checks, logging, updatepad en rollback. Hoe zwaarder de functie, hoe explicieter die operationele randvoorwaarden moeten zijn.
Onderhoudbaarheid telt mee in technische keuzes. Een elegante component die niemand veilig kan updaten of herstellen, is op termijn een slechte component. We kiezen liever een begrijpelijke oplossing met een duidelijk operationeel pad dan complexiteit om de complexiteit.
Weten of het systeem werkelijk leeft
Gerichte checks voor kritieke services en afhankelijkheden.
Backups zijn pas nuttig als herstel mogelijk is
Backup, restore en rollback worden als proces bekeken, niet als vinkje.
Beheersbare releases
Kleine, herleidbare changes beperken regressierisico en versnellen herstel.
TRANSPARANTE VERANTWOORDELIJKHEID
We maken grenzen zichtbaar omdat vertrouwen controleerbaar moet zijn.
Geen enkel softwarebedrijf kan geloofwaardig beloven dat een systeem “nooit fout gaat”. Wat wel professioneel kan, is risico verkleinen, bevoegdheden begrenzen, relevante gebeurtenissen kunnen reconstrueren en vooraf bepalen hoe een veilige toestand wordt hersteld.
Dat is de kern van Engineering & Trust bij Qavirio: niet vertrouwen vragen omdat iets modern oogt, maar genoeg structuur, bewijs en grenzen creëren om vertrouwen rationeel te kunnen onderbouwen.
- Geen security- of AI-claims zonder context.
- Geen certificering suggereren wanneer die niet formeel bestaat.
- Menselijke verantwoordelijkheid expliciet houden waar oordeel of bevoegdheid nodig is.
Engineering is ook weten waar de grens ligt.
Een systeem wordt niet betrouwbaarder door meer functies. Het wordt betrouwbaarder wanneer gedrag, bevoegdheden, bewijs en herstel begrijpelijk blijven.
VOLGENDE STAP
Contact →Wat moet digitaal beter werken?
Beschrijf het probleem. Wij kijken eerst naar doel, gebruiker en proces — daarna pas naar technologie.