Anonimnost kao arhitektonska invarijanta: zašto „nećemo vas kontaktirati” nije dovoljno
Obećanja poput „nikada vas nećemo kontaktirati nezatraženo” na B2B platformama nisu provediva — pružatelji ih zaobilaze offline. Ono što djeluje je tehnička invarijanta: kontaktni podaci žive u odvojenoj sferi, server ih otključava tek na obostrani match. Svojstvo koda, ne TOS klauzula.
Klasično B2B matching obećanje: „nikada nećete biti kontaktirani nezatraženo". Lijepo formulirano. Neprovedivo.
Platforma ne može spriječiti da pružatelj offline istraži, izvuče broj tvrtke iz sudskog registra i nazove. Obećanje je tvrdnja o svijetu — a svijet je širi od bilo kojeg TOS ugovora.
Što stvarno drži: arhitektonske invarijante
Na PairSonalu preformulirali smo obećanje. Umjesto:
„Nećemo proslijediti vaše kontaktne podatke."
sada stoji:
„Vaši HR kontaktni podaci na platformi tehnički su nevidljivi pružateljima — sve dok sami ne otključate match."
Razlika nije semantička. Strukturalna je:
- Kontaktni podaci žive u odvojenoj sferi baze.
- Listing endpointi vraćaju profile čiji payload jednostavno ne sadrži
email,telefon,hr_contact. - Match endpoint server-side radi join na kontakt-sferu tek nakon obostranog otključavanja.
- Frontend nema code path koji bi rekonstruirao polja koja u generiranom tipu ne postoje.
Obećanje postaje svojstvo koda. Tko provede "što se dogodi kad učitam profile?" pronalazi polja odsutna. Ne "filtrirana", ne "null" — ne postoje u shemi.
Zašto je to jače
- Provjerljivo. Revizor pročita OpenAPI shemu i potvrđuje: kontaktna polja u anonimnoj sferi ne postoje. To je činjenica, ne TOS klauzula.
- Skalira s timom. Novi kolega ne može nehotice izgraditi endpoint koji curi polja — ona nisu u klasi modela koju on importa.
- Otporno na auth-bugove. Bug u privilege sloju ne može iznijeti skrivena polja koja u response shemi ne postoje.
Kad je to pretjerano
Arhitektonske invarijante imaju cijenu. Praktički održavaš dva modela podataka, dva repozitorija, dvije service klase, eksplicitan most između njih. Za korisnički profil s tri atributa to je overkill.
Točka u kojoj se isplati: kad je obećanje sam proizvod. Ako klijenti dolaze na platformu jer vjeruju anonimnosti, anonimnost ne smije živjeti u TOS klauzuli. Mora živjeti u layer-arhitekturi — inače proizvod umire s prvim leakom.
Opće pravilo
Za svako obećanje "nećemo raditi X" sada se pitamo:
Možemo li to izgraditi tako da tehnički ne možemo?
Ako da: gradimo. Ako ne: obećanje je tvrdnja, ne značajka — i treba ga imenovati kao tvrdnju, ne prodavati kao značajku.