Service codes & ITAD matching: quand "certified erasure" veut dire une seule chose

"Effacement certifié des données" signifie une chose sur le devis d'un ITAD et autre chose sur celui du suivant, et c'est ainsi que les clients trade-in finissent par comparer des pommes et des poires. La plateforme corrige cela avec un catalogue partagé de service codes — chaque ITAD parle le même vocabulaire, donc le client compare like with like.

Le catalogue

La plateforme seed un set canonique de service codes couvrant le cycle opérationnel : variantes de data-erasure (NIST 800-88 Clear, Purge, Destroy), shredding (drives, full devices), refurbishment, recycling par material stream, transportation classes, secure pickup, et les catégories compliance + security utilisées par le trade-in intake. Chaque code a un human-readable name, un short identifier et une category. Les tenants ne modifient pas le platform catalog — ils activent les codes qu'ils offrent et ajoutent des overrides de pricing par tenant.

Tenant Coverage

Chaque tenant configure Coverage dans /settings/coverage : les regions où il collecte, les certifications qu'il détient, les service codes qu'il propose et à quel price level. Lorsqu'un trade-in customer publie une pickup request — avec location, device catégories et les service codes requis (par exemple NIST 800-88 Purge + R2v3 transport) — le matching engine trouve les tenants dont la Coverage intersecte la request. Les ITADs qui ne couvrent pas la request ne la voient jamais ; ceux qui la couvrent enchérissent les uns contre les autres.

Pourquoi default-on pour compliance + security

Les service codes compliance et security (NIST 800-88, secure-chain-of-custody, regulated-waste-handling, ADISA-conformant) sont seedés default-on pour chaque ITAD qui détient les certifications correspondantes. Sinon les tenants doivent penser à les activer — et le trade-in customer qui fixe une exigence compliance reçoit moins de bids qu'il ne devrait. Default-on signifie qu'un tenant certifié apparaît par défaut dans le bid pool, avec la possibilité d'opt out par code.

Versioning

Les service codes sont versionnés au niveau du catalogue. Quand la plateforme introduit un nouveau code (un nouveau compliance regime, une nouvelle disposal class), les tenants existants voient le nouveau code dans leur Coverage UI pour l'activer. Les anciens codes ne changent pas silencieusement de sens — si un code est remplacé, la plateforme déprécie l'ancien code et migre les active bids, avec review possible par l'opérateur.

Où le code apparaît

Sur le trade-in intake form (le client choisit les codes dont il a besoin), sur le bid de l'ITAD (les codes qu'il fournira), sur l'awarded contract (les codes devenus l'accord), et sur le settlement (les codes facturés). Un seul vocabulaire, tout au long du flow.