Kwaliteit en lifecycle

Opmerking toevoegen

Je kunt opmerkingen plaatsen via Opmerking toevoegen aan de rechterkant van de pagina.

Doel

Garanderen dat ruwe data uit elke bron in één eenduidig formaat in onze database belandt, dat dezelfde opdracht uit meerdere kanalen niet als twee aparte vacatures verschijnt, en dat een nieuwe bron pas naar productie gaat als hij stabiel en schoon draait.

Drie zorgen, één keten

flowchart LR
  R[Ruwe respons per bron] --> N[Normalisatie naar ABN-datamodel]
  N --> D[Dedup-sleutel platform_id + platform_job_id]
  D --> J[(Vacature opgeslagen)]
  J --> L[Lifecycle gate]
  L --> P[Publicatie en operatie]

Normalisatie in gewone taal

Elk platform gebruikt eigen termen. STRIIVE noemt het "rate", Flextender "tarief per uur", Yacht "salaris". Wij slaan het altijd op één manier op, zodat de frontoffice niet hoeft te vertalen voordat ze beoordelen.

Wat de bron noemt	Wat wij opslaan	Waarom
rate / tarief / salaris	`contract_min_rate_eur`	Één veld waarop frontoffice direct kan beoordelen
uren per week / uren per dag	`contract_hours_per_week`	Filteren en matchen op één eenheid
sluitingsdatum / closing date / deadline	`closes_at` in UTC	Eenduidige sortering en deadline-check
locatie / regio / werkplek	`location` + `location_country`	Geografische filtering los van standplaatstaal

De volledige uitleg per veld staat op ABN Data Model.

Ontdubbeling als basisprincipe

Dezelfde opdracht kan via meerdere kanalen binnenkomen. Bijvoorbeeld een Striive-opdracht die ook bij Flextender staat. Ons mechanisme is simpel maar effectief: we identificeren een vacature aan de combinatie van platform en platform-eigen identifier. Komt er een nieuwe ronde binnen voor één we al kennen, dan updaten we de bestaande rij in plaats van een nieuwe te maken.

Frontoffice ziet altijd één opportunity per opdracht, niet meerdere.
Update-velden zoals sluitingsdatum, eisenwijzigingen of statuswijziging staan altijd op de meest recente bronwaarde.
De bron-URL staat erbij vermeld; bij meerdere bronnen blijven beide zichtbaar via het bron-snapshot-historie.

Lifecycle: van proefdraaien tot productie

Intake

Een nieuw platform start altijd in intake. We hebben een rij in de database, soms al credentials in Infisical, maar nog geen werkende scraper. In dit stadium heeft het nog geen impact op productie.

Staging

Scraper draait, maar resultaten zijn nog niet zichtbaar voor frontoffice. We tunen selectoren, controleren normalisatie en kijken of de cadens klopt. Geen alerts naar de oncall.

Pilot

Voor één team of één kandidaatgroep zichtbaar gemaakt. We meten coverage, foutratio en gebruiker-feedback. Klein opzetje, snel terug te draaien.

Live

Volledig zichtbaar voor frontoffice; alerts staan aan; gebreken leiden tot een incident-melding. Pas hier landt het in dagelijkse routines.

Sunset

De bron of methode wordt uitgefaseerd, bijvoorbeeld omdat het platform stopt of vervangen is. Data blijft bewaard, scrape stopt op een geplande datum.

De lifecycle-gate is geen formaliteit: een platform mag pas door als het twee weken stabiel is gedraaid en de coverage match-baar is met handmatige check. Dit voorkomt dat een halfwerkende bron de operatie vervuilt.