Anonimnost kot arhitekturna invarianta: zakaj „ne bomo vas kontaktirali” ni dovolj
Obljube tipa „nikoli vas ne bomo kontaktirali brez najave” na B2B platformah niso izvršljive — ponudniki jih zaobidejo offline. Kar deluje, je tehnična invarianta: kontaktni podatki živijo v ločeni sferi, strežnik jih sprosti šele ob obojestranskem ujemanju. Lastnost kode, ne TOS klavzule.
Klasična B2B matching obljuba: „nikoli ne boste kontaktirani brez najave". Lepo formulirano. Ni izvršljivo.
Platforma ne more preprečiti, da ponudnik offline raziskuje, iz poslovnega registra izvleče telefonsko številko podjetja in pokliče. Obljuba je trditev o svetu — in svet je širši od katere koli TOS pogodbe.
Kar resnično drži: arhitekturne invariante
Na PairSonalu smo obljubo preoblikovali. Namesto:
„Vaših kontaktnih podatkov ne bomo posredovali."
zdaj piše:
„Vaši HR kontaktni podatki na platformi so za ponudnike tehnično nevidni — dokler sami ne odklenete ujemanja."
Razlika ni semantična. Strukturna je:
- Kontaktni podatki živijo v ločeni sferi baze.
- Listing endpointi vračajo profile, katerih payload preprosto ne vsebuje
email,telefon,hr_contact. - Match endpoint server-side izvede join na kontaktno sfero šele po obojestranskem odklepu.
- Frontend nima nobene code-path, ki bi rekonstruirala polja, ki v generiranem tipu ne obstajajo.
Obljuba postane lastnost kode. Kdor preizkusi "kaj se zgodi, ko naložim profile?" najde polja odsotna. Ne "filtrirana", ne "null" — ne v shemi.
Zakaj je to močnejše
- Auditirano. Revizor prebere OpenAPI shemo in potrdi: kontaktna polja v anonimni sferi ne obstajajo. To je dejstvo, ne TOS klavzula.
- Skalira s številom zaposlenih. Novi sodelavec ne more po nesreči zgraditi endpointa, ki bi razkril polja — niso v razredu podatkovnega modela, ki ga uvozi.
- Preživi auth-bugove. Bug v privilege sloju ne more razkriti skritih polj, ki v shemi odgovora ne obstajajo.
Kdaj je to pretiravanje
Arhitekturne invariante stanejo. Pravzaprav vzdržuješ dva podatkovna modela, dva repozitorija, dva servisna razreda, eksplicitno premostitev med njima. Za uporabniški profil s tremi atributi je to overkill.
Točka, ko se splača: ko je obljuba sam izdelek. Če stranke pridejo na platformo zato, ker zaupajo anonimnosti, anonimnost ne sme živeti v TOS klavzuli. Mora živeti v arhitekturi plasti — sicer izdelek umre s prvim leakom.
Splošno pravilo
Za vsako obljubo "ne bomo počeli X" se zdaj vprašamo:
Lahko to zgradimo tako, da tehnično ne moremo?
Če da: zgradimo. Če ne: obljuba je trditev, ne funkcija — in jo je treba imenovati kot trditev, ne prodajati kot funkcijo.