ReorderOps

Ongelma

Varastosuunnittelijan täytyy ymmärtää, mitkä tuotteet vaativat huomiota, miksi ja minkä toimenpiteen voi turvallisesti ottaa tarkasteluun. Pieni varasto ei yksin ole tilausohje: saapuvat toimitukset, toimitusajat, kysynnän muutokset ja toimittajan ehdot vaikuttavat päätökseen.

Ensimmäinen historiallisten tietojen tarkastelu käytti kiinteitä riittävyysluokkia. Ne tuottivat lähdeaineistossa paljon kohinaa. Tuotekohtaiset prosenttipisteet paransivat vertailua, mutta historiallisesti tavallinen varastotaso ei välttämättä kata toimittajan toimitusaikaa. Hankintasuunnittelusta tehtiin siksi erillinen deterministinen laskenta.

Toistettava suunnittelu

Liiketoimintasäännöt ennustavat varastotilannetta ja laskevat täydennystarpeen toimitusaikojen, varmuusvaraston, vähimmäistilausten ja pakkauskokojen perusteella. Tallennetut ajot säilyttävät syötteet, laskentaversion ja syötteiden sormenjäljen sen sijaan, että vanhoja perusteluja laskettaisiin huomaamatta uudelleen.

• FILTER-420: suositus on 210 yksikköä, ja aiempaan puutteeseen liittyy kiirehtimisen tarkastelu.
• VALVE-88: alkuperäinen 75 yksikön tarve kasvaa 120 yksikköön toimittajan vähimmäistilauksen vuoksi.
• BELT-210: ajoissa saapuva toimitus estää päällekkäisen tilauksen.
• BEARING-51: kysyntäpoikkeama pysäyttää suosituksen tarkasteltavaksi.

Ihmisen päätös, uusi validointi

Hyväksyntä lukee nykyisen varaston, saapuvat toimitukset, kysynnän ja toimittajaehdot uudelleen lyhyen SQLite-kirjoitustransaktion sisällä. Muuttuneet perustelut estävät toiminnon. Täsmälleen saman pyynnön uusiminen palauttaa alkuperäisen tuloksen, ja yksilöllisyysrajoitteet estävät toisen aktiivisen luonnoksen samalle tuotteelle.

Sisäiset ostotilausluonnokset eivät lähetä mitään toimittajalle eivätkä muutu vahvistetuksi saapuvaksi toimitukseksi. Onnistuneet ja estetyt toiminnot tallentuvat vain täydentyvään tapahtumalokiin. Tietokantatiedoston tai skeeman suora muokkausoikeus mahdollistaa silti tietojen muuttamisen; tallennusta ei väitetä peukaloinnin estäväksi.

Rajattu tekoälytulkinta

GPT-6 Luna -integraatio käyttää hallittuja, vain lukuun tarkoitettuja työkaluja erillisen tietopaketin hakemiseen ja varmennettujen tietokorttien yhdistämiseen sovellukseen. Määräävät lukumäärät kuuluvat taustajärjestelmälle. Avustaja ei voi hyväksyä päätöksiä, luoda luonnoksia, muokata varastoa tai lähettää tilauksia.

Arvioinnit sisältävät monikielisiä kysymyksiä, epäsiistejä syötteitä ja kehoteinjektioyrityksiä. Ne paljastivat tärkeän rajoitteen: oikeat lähdeviitteet eivät takaa järkevää selitystä tai pyydettyä kieltä. Deterministinen varatoiminto säilyttää hyödylliset tiedot, kun palveluntarjoaja epäonnistuu tai käyttöraja täyttyy. Tekoälyn selitykset vaativat edelleen tarkastamista.

Julkinen demo, eristetyt toiminnot

Vercelin käyttöliittymä ja Railwayn taustajärjestelmä esittävät generoitua historiaa yksityisen CSV-aineiston sijaan, sillä sen alkuperää ja lisenssiä ei ole vahvistettu. Vierailijat saavat erilliset väliaikaiset tietokantakopiot, jolloin luonnokset ja lokitapahtumat pysyvät erillään.

Pysyvä käytönhallintarekisteri varaa arvioidut tekoälykustannukset ennen palvelukutsua ja soveltaa käyttörajoja. Epävarmassa tilanteessa varaus säilytetään. Kyse on kustannusten hallinnasta, ei väitteestä mitatuista käyttösäästöistä.

Varmennus ja avoimet rajoitteet

Testit kattavat puuttuvat ja virheelliset tiedot, laskennan raja-arvot, tallennettujen ajojen toistamisen, vanhentuneet hyväksynnät, transaktioiden peruutukset, rinnakkaisuuden, vierailijoiden eristämisen ja palautuksen. Dokumentoitu v1.4-vaihe raportoi 303 läpäistyä taustajärjestelmän testiä Pythonin versioilla 3.11 ja 3.12 sekä Ruff- ja käyttöliittymätarkistukset.

Dokumentoidut julkaistun demon tarkistukset kattavat hankintatoiminnot ja rajatun tekoälykäytön. Kielen luotettavuus, palveluntarjoajan käytön täsmäytys, täysi tuotantopalautus ja kylmäkäynnistyksen ajoitus vaativat vielä varmennusta. Projektissa ei ole reaaliaikaista ERP-integraatiota, tilausten lähettämistä toimittajalle, vastaanottotyönkulkua, poikkeaman ohitusta tai varsinaista käyttäjätunnistautumista. Se osoittaa teknisiä ratkaisuja, ei mitattua ennustetarkkuutta tai vähittäiskaupan säästöjä.

Testaus ja varmennus

• Automaattiset tarkistukset kattavat virheelliset syötteet, tulosten toistamisen, rinnakkaisuuden, peruutukset, vanhentuneen tiedon hyväksynnät ja vierailijoiden eristämisen.
• Monikieliset, epäsiistejä syötteitä käsittelevät ja hyökkäävät tekoälyarvioinnit säilyttävät havaitut merkitys- ja kielivirheet.
• Dokumentoitu planning-v1.4-vaihe raportoi 303 läpäistyä taustajärjestelmän testiä Pythonin versioilla 3.11 ja 3.12 sekä Ruff-, TypeScript- ja tuotantokoontitarkistukset. Tämä on projektin lähdeaineistoa, ei tämän portfolion testimäärä.

Dokumentaatio · englanniksi

Teknistä arviointia varten tarjolla ovat kuratoitu arvioijan opas, arkkitehtuuri, suunnittelusäännöt, tekoälyn arviointi ja julkisen demon hallintakeinot. Tekninen dokumentaatio on englanniksi.