Har bygget ejerskabskrav og deres afgørelse

Situation. Et katalog, der er seedet fra offentlige kilder, har et strukturelt problem: virksomhederne i det har ikke selv sat sig der. Før eller siden dukker nogen fra en af dem op og vil rette sin egen post — og der er ingen relation mellem den person og den post, kun en påstand om, at der er en. Godkender man kravet for let, redigerer en konkurrent virksomhedens side. Godkender man det for langsomt, bliver kataloget ved med at være forkert.

Opgave. Der skulle være en vej fra “det her er min virksomhed” til reel råderet over posten, med en menneskelig beslutning i midten og et spor bagefter.

Handling. Ejerskabskrav blev bygget fra ende til anden, fordelt på 108 commits og begge applikationer. En bruger indsender et krav med dokumentation; det lander på en arbejdsliste i back‑officen; en administrator gennemgår det og godkender eller afviser det med en begrundelse, der går tilbage til den, der rejste kravet. Det interessante er, hvad en godkendelse gør — det er ikke et flag på en række. Godkendelsen omskriver autorisationsgrafen, så kontoen får en rigtig relation til organisationen, og det er den samme relation, som hvert eneste rettighedstjek i platformen allerede slår op i. Kontrollen ligger i afgørelsen, ikke i kodestien, og ingen funktion har været nødt til at lære om ejerskabskrav for at respektere den.

Resultat. En virksomhed kan overtage og rette sin egen post, uden at nogen redigerer databasen i hånden, og hver tildeling af råderet har en navngiven godkender og en begrundelse knyttet til sig. Den menneskelige gennemgang er bevidst flaskehalsen; et automatisk tjek på et domænenavn ville være hurtigere og ville tage fejl i præcis de tilfælde, der betyder mest.