Põhjused, mida saab lugeda

Mis poodi tegelikult jõuab

Tellimus tuleb sisse. Poe enda server kutsub kontrolli otspunkti, kuni korv on veel ekraanil, ja tagasi tuleb väike objekt: skoor, lühike põhjuste nimekiri, läbipaistmatu käepide vastatud jäljele. Midagi muud ei juhtu. Heatrail ei puutu tellimust ega makset ja tal ei ole selleks võimalust (vt nõuandev konstruktsiooni järgi). Mis järgneb, on poe otsus, tehtud poe enda koodis.

Praktikas maandub vastus järjekorda. Poe reegel saadab selle tellimuse kohta, kus inimene teda vaatab, ja inimene loeb põhjuseid. Sealt tuleb disainisurve: kui inimene hakkab väljundit lugema, on kasulik artefakt lause, mitte number. Skoor 72 ei ütle täitmise töötajale midagi, millega vaielda. Rida, et sama kliendi identifikaator vastas võrgus kinnitatud pettusejäljele, mitu poodi ta puudutas ja kui hiljuti, on midagi, mida inimene saab kaaluda enda ees oleva tellimuse vastu, nõustuda või tagasi lükata.

Seega ei ole põhjused silumisabi, mis skoorimisteenusele külge kinnitati. Number on mugavus suunamiseks. Laused on see, mis otsuse teeb, ja mis teda hiljem kaitseb, kui keegi küsib, kuidas selleni jõuti.

Reeglid lähevad koodina, mitte seadistustena

Skoorimise konfiguratsioon elab versioonituna repositooriumis. Ta muutub, kui keegi kirjutab commit'i ja deploy'ib, ja iga selline muudatus kirjutab sündmuse ainult lisatavasse logiraamatusse, nii et see, millised reeglid ühel päeval olid, on tõend, mitte mälu. Seadistusteekraani tal ei ole, lülitit operaatori konsoolis ei ole, välja, mida administraator enne lõunat nihutada saaks, ei ole.

Reeglite otspunkt järgneb sellest. Ta on olemas selleks, et operaator saaks konfiguratsiooni ja selle muudatuste logi lugeda, ja ta on konstruktsiooni järgi ainult loetav: kirjutamisteed, kuhu jõuda, ei ole. Selliseid väiteid tehakse tavaliselt kavatsuste, mitte kuju kohta, ja see on väide kuju kohta. Operaatori konto täielik ülevõtmine, täielikud volitused, täielik sessioon, iga step-up läbitud, ei saa ikkagi muuta, kuidas kedagi skooritakse. Ründaja selles stsenaariumis otsib kirjutamisteed, mida ei ole kunagi ehitatud. Skoorimise muutmine tähendab commit'i, deploy'd ja logiraamatu kannet, mis hetke nimetab.

Mida põhjusel on lubatud öelda

Põhjus on kategooria selle poe ees oleva tellimuse kohta. Ta ütleb, et midagi vastas, umbes kui laialt ja umbes kui hiljuti. Ta ei kanna kunagi teise poe tõendit, ei nimeta kunagi teist kaupmeest, ei tagasta kunagi identifikaatorit ega räsi, ja ei kanna kunagi piisavalt detaili, et keegi saaks jagatud signaali kaardistada, saates talle kontrolle ja lugedes vastuseid tagasi. See viimane piirang on põhjus, miks vastus on üldse kategooriline, ja ta on korralikult läbi töötatud artiklis miks võrku ei saa loetleda.

Põhjus, mis seletaks rohkem, aitaks inimest järjekorras, ja ta aitaks samavõrra kedagi, kes võrku sondeerib. Vastus lahendab selle ühtpidi: poele öeldakse, mis on tema enda tellimuse jaoks asjakohane, kategooriates, ja mitte kaugemale.

Reeglid, ja kuidas neid ei nimetata

Skoorimine on reeglipõhine. Asi, mis skoori otsustab, on reegel, ja poele saab öelda, milline neist rakendus. See on kogu väide, ja sõnavara vastab talle: fraas masinõpe teeb selles tööstuses palju teenimata tööd, ja reeglimootor, mida selles sõnavaras kirjeldatakse, oleks vale, mis juhtumisi paremini müüb.

Lubadus sõnavara kohta on sama kindel kui lubadus koodi kohta. Kui mudel kunagi skoorimisteele siseneb, ütleb see leht seda samal päeval, koos sellega, mida ta muutis põhjustes, mida pood saab.

Reeglid on loetavad ja teadlikult lihtsad. Lihtsad reeglid töötavad siin, sest signaal tuleb poodidelt, kes sildistavad kahju, mida nad kinnitasid, mitte nutikusest skoorimissammul. Tihedam võrgustik parandab vastust rohkem, kui parem mudel teeks.

• Nõuandev konstruktsiooni järgi, miks skoorist ei järgne midagi, kuni inimene poes paneb ta järgnema.
• Miks võrku ei saa loetleda, miks põhjus on kategooria ja mitte kunagi kirje.
• API viide, vastuse kuju ja avaldatud põhjusekoodide jaoks.