Jeg vil at teknisk arbeid skal kunne kontrolleres uten at mennesker må betale prisen for åpenheten. Derfor bruker jeg en enkel huskeregel: Vis frem kalkulatoren, ikke kundens regnestykke.
Metoden, testene, den offentlige kilden og grensene kan ofte deles. Kundens innlogging, kommentarer, forretningsdata og driftsveier skal fortsatt være beskyttet.
Åpenhet trenger et tydelig formål
Det er lett å gjøre «åpenhet» til en mengde filer, logger og skjermbilder. Men mer materiale er ikke automatisk bedre bevis. Jeg prøver heller å publisere det som gjør en bestemt påstand mulig å undersøke: hvilken versjon som ble vurdert, hva som ble testet, hva testen ikke dekker og hvordan endringen kan tilbakeføres.
En commit kan vise eksakt kilde. En testmatrise kan vise hvilke reiser som ble kontrollert. En offentlig demo kan la andre gjenta en handling. Ingen av delene bør inneholde ekte kundeinnhold bare for å virke troverdige.
Tre statuser rydder opp i språket
- Offentlig kontrollerbart: en utenforstående kan åpne kilden, siden eller demonstrasjonen selv.
- Internt verifisert: jeg har en datert test eller release, men den inneholder detaljer som må beskyttes.
- Ukjent: jeg mangler en navngitt kilde og skal ikke pynte på fraværet med et sikkert klingende tall.
Dette skillet gjør tekstene litt mindre spektakulære. Det gjør dem også mer nyttige. Leseren kan se hvor beviset slutter, og jeg kan oppdatere påstanden når nye data faktisk finnes.
Også åpen kildekode må gjennom en sikkerhetskontroll
Før kodeprosjekter ble publisert fra mine egne miljøer, ble hele den annonserte Git-historikken undersøkt – ikke bare siste mappevisning. Kontrollen så etter hemmeligheter, personopplysninger, kundereferanser, uklare rettigheter og uønskede binærfiler.
Noen prosjekter kunne publiseres med eksakt versjon og lisens. Et prosjekt med reell kunde- og prosjekthistorikk forble privat. Det var ikke et nederlag for åpenheten; det var sikkerhetsregelen som virket.
Metoden kan være åpen selv om driften er lukket
Jeg kan beskrive at en endring hadde en eksakt sikkerhetskopi, en avgrenset rollback og nettlesertester på tre skjermbredder. Jeg trenger ikke publisere serveradresse, nøkkelmateriale eller hele driftskartet. På samme måte kan IntentForce vise en fiktiv App Studio-demo offentlig og gi faktiske kunder en privat visning.
Dette er også tanken bak Evidence Passports: Beviset skal si hva det støtter, hvor det kommer fra og hva det ikke kan brukes til å hevde. Målet er ikke maksimal eksponering. Målet er maksimal etterprøvbarhet innenfor en ansvarlig grense.
I want technical work to be verifiable without making people pay the price for openness. That is why I use a simple rule: show the calculator, not the customer’s calculation.
The method, tests, public source, and boundaries can often be shared. The client’s login, comments, business data, and operational paths should remain protected.
Openness needs a clear purpose
It is easy to turn “openness” into a pile of files, logs, and screenshots. More material is not automatically better evidence. I prefer to publish what makes a specific claim inspectable: which version was assessed, what was tested, what the test did not cover, and how the change can be reversed.
A commit can identify the exact source. A test matrix can name the journeys that were checked. A public demo can allow others to repeat an action. None of these should contain real client content merely to look credible.
Three statuses make the language clearer
- Publicly verifiable: an outsider can open the source, page, or demonstration.
- Internally verified: I have a dated test or release, but it contains details that must remain protected.
- Unknown: I lack a named source and should not disguise that absence with a confident-looking number.
This distinction makes the writing slightly less spectacular. It also makes it more useful. The reader can see where the evidence ends, and I can update the claim when new data actually exists.
Open source also requires a security review
Before projects from my own environments were made public, the complete advertised Git history was inspected—not just the latest folder view. The review looked for secrets, personal data, client references, unclear rights, and unwanted binaries.
Some projects could be published with an exact version and licence. A project containing real client and project history remained private. That was not a failure of openness; it was the safety rule working as intended.
The method can be open while operations stay closed
I can explain that a change had an exact backup, a bounded rollback, and browser tests at three screen widths. I do not need to publish the server address, key material, or the full operational map. In the same way, IntentForce can show a fictional App Studio demo publicly while giving real clients a private view.
This is also the idea behind Evidence Passports: evidence should state what it supports, where it came from, and what it cannot be used to claim. The objective is not maximum exposure. It is maximum verifiability within a responsible boundary.