Vaikeat kysymykset

Miksi ette käytä SQLiteä?

Todennäköinen kysymys

Miksi ette tee tätä SQLite:lla?

Lyhyt vastaus

Koska tutkimuskysymys ei ole voiko SQLite tehdä tämän, vaan voiko object storage itse toimia kyseltävänä lukukerroksena ilman tietokantapalvelinta.

Pidempi vastaus

SQLite olisi vahva oletus, jos tavoite olisi yleinen embedded SQL-ratkaisu. Mutta silloin tutkimusasetelma olisi eri. Tässä kiinnostava kohta on nimenomaan se, voidaanko immutable object storagea käyttää tehokkaasti kyseltävänä artifactina.

Miksi ette käytä D1:tä?

Todennäköinen kysymys

Miksi ette käytä Cloudflare D1:tä?

Lyhyt vastaus

D1 ratkaisee eri ongelman.

Pidempi vastaus

Tässä tutkimuksessa kiinnostava yhdistelmä on immutable object + Worker + byte-range-read + kyselysuunnittelija ilman tietokantapalvelinta ja ilman perinteistä relaatiokerrosta.

Turvallinen muoto

D1 on oikea vastaus silloin, kun halutaan tietokanta. Tämän tutkimuksen pointti on selvittää, milloin object storage itse voi riittää lukukerrokseksi.

Miksi tämä ei ole SQL?

Todennäköinen kysymys

Miksi ette vain kutsu tätä tietokannaksi?

Lyhyt vastaus

Koska tämä ei ole yleinen SQL-moottori.

Pidempi vastaus

Kyselyt tunnetaan etukäteen, suunnittelija on deterministinen, eikä mallissa ole vapaata SQL:ää, join-operaatioita tai OLTP-tyyppistä mutaatiokuormaa. Oikea kuvaus on lukupolulle optimoitu julkaisu- ja briefing-arkkitehtuuri.

Mikä ongelma tällä ratkaistaan?

Todennäköinen kysymys

Mitä ongelmaa tässä oikeastaan ratkaistaan?

Lyhyt vastaus

Tässä ratkaistaan kahta eri ongelmaa: toimituksellista ongelmaa ja datan jakelun ongelmaa.

Pidempi vastaus

Toimituksellinen ongelma: uutisvirtaa on liikaa. Tarvitaan putki, joka hakee useita lähteitä, poistaa duplikaatit, kokoaa samaa tarinaa yhteen, erottaa lähdefaktan toimituksellisesta kopiosta ja näyttää varmuustason.

Datan jakelun ongelma: kun sisältö on jo rakennettu etukäteen, sitä ei välttämättä kannata palvella täydellä tietokantapalvelimella. Silloin kysymys on voidaanko enimmäkseen luettava briefing-data toimittaa suoraan object storagesta ilman tietokantapalvelinta.

Miten AI liittyy tähän?

Todennäköinen kysymys

Onko tämä vain AI-uutissivusto?

Lyhyt vastaus

Ei. AI on yksi osa putkea, mutta ei julkista pyyntöpolkua.

Pidempi vastaus

Nykyisessä jaossa Claude valitsee shortlistin ja lopullisen valinnan, OpenAI tuottaa julkaistavat toimitukselliset kentät ja grounding + publish-gate yrittävät estää heikot signaalit. Julkinen /api/data tai /api/news/history ei kutsu AI-malleja jokaisessa pyynnössä.

Mistä AI tietää mitä tapahtui?

Todennäköinen kysymys

Käykö AI vapaasti verkossa?

Lyhyt vastaus

Ei. AI toimii rajatun tutkimuskorpuksen päällä.

Pidempi vastaus

Ensin rakennetaan korpus:

• raw articles RSS-lähteistä
• story clusters
• source metadata
• audit snapshotit

Sen jälkeen toimituksellinen vaihe toimii tämän aineiston päällä. AI ei arvaa maailmaa tyhjästä, vaan käyttää kerättyä ja audit-kelpoista korpusaineistoa.

Miksi AI ei ole request pathissa?

Todennäköinen kysymys

Miksi ette vain generoi vastausta livenä?

Lyhyt vastaus

Koska julkinen käyttöliittymä tarvitsee vakaan vasteajan, toistettavan sisällön ja audit-polun.

Pidempi vastaus

Jos AI olisi pyyntöpolussa, vasteaika, toistettavuus, versionointi ja audit-kelpoisuus heikkenisivät. Tässä mallissa AI tekee korpustulkintaa, shortlistin, toimituksellisia kenttiä ja groundingin apua ennen julkaisua.

Mikä publish-gate on?

Todennäköinen kysymys

Julkaiseeko AI kaiken automaattisesti?

Lyhyt vastaus

Ei. Publish-gate erottaa AI-outputin julkaistavasta signaalista.

Pidempi vastaus

Publish-gaten tarkoitus on estää heikot tai puutteelliset signaalit, laskea convictionia matalan varmuuden tapauksissa ja pitää julkinen publish-polku hallittuna.

Turvallinen muoto

Publish-gate ei tee järjestelmästä totuuskonetta, mutta tekee siitä läpinäkyvämmän ja hallitumman kuin pelkkä AI-yhteenvetoputki.

Mikä consensus tässä on juuri nyt?

Todennäköinen kysymys

Onko teillä jo valmis consensus-malli tai claim-level fact-checking?

Lyhyt vastaus

Ei vielä. Nykyinen consensus v1.1 on heuristinen tuotekerros, ei formalisoitu tutkimusmalli eikä väitetason faktantarkistusmoottori.

Pidempi vastaus

Lähdedokumenttien nykytila on tämä:

• julkisessa /api/data-vastauksessa on kevyt consensus-kerros jokaiselle signaalille
• se lasketaan Workerissa, ei erillisenä LLM-vaiheena
• syötteinä käytetään evidenceSources-listaa, sourceHealth-snapshotia ja ingest-vaiheessa talteen otettua sourceSnapshots-metadataa
• nykyinen objekti sisältää ainakin kentät level, confidenceScore, independentSourceCount, sourceWeightSum, avgSourceWeight, avgSuccessRate, degradedSourceCount, contradictionFlag, contradictionReasons, singleSource, crossSource ja sources[]
• tasot ovat low, medium, high ja contested

Docsien mukaan tämän tarkoitus ei ole vielä "todistaa totuutta", vaan erottaa:

• yhden lähteen signaalit
• usean riippumattoman lähteen tukemat signaalit
• tapaukset, joissa lähteiden välillä näkyy eksplisiittinen ristiriita

Mitä on oikeasti varmennettu

implementation-status.md ja live-smoke-testaus.md osoittavat, että 28.6.2026 live-puolella oli varmennettu ainakin:

• /api/data palauttaa consensus-kentät tuotannossa
• consensus.level voi olla low|medium|high|contested
• contradiction-haara toimii julkaistussa datassa asti
• kontrollitapauksessa inflow vs outflow palautui muodossa consensus.level = contested ja contradictionFlag = true
• samalla korjattiin oikea delta-persistenssibugi, jossa sourceSnapshots saattoi aiemmin kadota publish-vaiheessa

Mitä tämä ei vielä tee

Sama dokumentaatio rajaa nykyisen toteutuksen ulkopuolelle:

• stance- tai claim-extractionin
• pidemmän aikavälin story-chain-consensuksen
• täyden väitetason faktasovituksen
• hienovaraisen numeeristen ristiriitojen päättelyn
• formalisoidun cross-source consensus -moottorin

Turvallinen muoto

Nykyinen consensus on Workerissa laskettu heuristinen confidence- ja contradiction-kerros. Se auttaa näyttämään monilähteistä tukea ja ristiriitatilanteita, mutta se ei vielä ole formalisoitu consensus-malli eikä claim-level fact-checking -engine.

Miksi immutable?

Todennäköinen kysymys

Miksi teitte tästä immutable-mallin?

Lyhyt vastaus

Koska se sopii object storageen ja helpottaa julkaisu- ja audit-polkuja.

Pidempi vastaus

Immutable-mallissa voidaan versionoida, rollbackata, julkaista ja auditoida ilman inplace-kirjoituksia aktiiviseen base-objektiin. Tämä tekee object storagesta luonnollisen julkaisupinnan.

Mikä pointer on?

Todennäköinen kysymys

Miksi tarvitsette pointerin?

Lyhyt vastaus

Pointer ratkaisee sen, mikä manifest on aktiivinen juuri nyt.

Pidempi vastaus

Uusi base ja manifest rakennetaan ensin, ja pointer vaihdetaan vasta lopuksi. Näin publish voidaan tehdä atomisesti ja vanha ketju säilyttää rollbackia varten.

Mikä delta engine on?

Todennäköinen kysymys

Miten muutokset tehdään, jos base on immutable?

Lyhyt vastaus

Muutos ei kirjoita basea yli, vaan syntyy append-only deltaobjektina.

Pidempi vastaus

Tyypillinen lifecycle on:

1. ingest
2. write delta
3. update manifest
4. julkaise pointer
5. kysy live-tila
6. compaction
7. rollback / retention tarvittaessa

Miten julkaisun turvallisuus on ratkaistu?

Todennäköinen kysymys

Entä jos kaksi publisheria kirjoittaa samaan aikaan?

Lyhyt vastaus

Publish suojataan CAS / ETag -mallilla.

Pidempi vastaus

Pointer-publish ei perustu siihen, että viimeinen kirjoitus vain voittaa. Käytetyt kontrollit ovat:

• pointerKey
• expectedGeneration
• ETag guard
• conditional write
• health check

Miksi snapshotit, jos JDBIN kerran toimii?

Todennäköinen kysymys

Jos JDBIN toimii, miksi käyttöliittymä käyttää snapshotteja?

Lyhyt vastaus

Koska snapshotit ja live JDBIN -polku ratkaisevat eri ongelmia.

Pidempi vastaus

JDBIN on kanoninen tallennus- ja lukukerros. Snapshot on julkinen jakeluartifact. Snapshot-polku tekee julkisesta käyttöliittymästä nopean ja vakaan. Live-JDBIN-polku tekee kanonisesta tallennuskerroksesta auditoitavan, versionoidun ja mitattavan.

Turvallinen muoto

Käyttöliittymän oletuspyyntöpolku ei ole live-JDBIN-kysely, vaan snapshot-ensin JSON-jakelu. JDBIN/JDBON toimii kanonisena tallennuskerroksena ja julkaisumoottorina.

Onko tämä ajettu oikeasti tuotannossa?

Todennäköinen kysymys

Onko tämä vain local demo?

Lyhyt vastaus

Ei. Toteutus on ajettu oikeasti Cloudflareen.

Pidempi vastaus

Nykytilasta on varmennettu ainakin:

• Worker + R2 + pointer + manifest + base/delta -ketju toimii
• aktiivinen live chain on julkaistu compacted baseen
• benchmark-endpoint toimii oikeaa R2-objektia vasten
• snapshot-pathit ovat käytössä julkisessa UI:ssa

Mitä on realistisesti valmista nyt?

Todennäköinen kysymys

Mikä tästä on oikeasti valmis?

Lyhyt vastaus

Useat ydinosat ovat jo toimivia, vaikka ne eivät ole lopullisia.

Pidempi vastaus

Valmiita nyt:

• Worker + R2 live
• tutkimuskorpusputki
• AI-avusteinen toimitusputki
• JDBIN/JDBON-kirjoituspolku
• julkinen snapshot-polku
• arkiston snapshot-polku
• consensus v1.1 tuotekerros

Mitä benchmarkit oikeasti todistavat?

Todennäköinen kysymys

Mitä nämä benchmarkit todistavat?

Lyhyt vastaus

Ne todistavat, että suuri immutable object voidaan pitää R2:ssa ja sitä voidaan kysellä ilman koko objektin lataamista.

Pidempi vastaus

Benchmarkit näyttävät, että Worker pystyy ratkaisemaan tunnettuja kyselymuotoja niin, että kyselyn kustannus voi pysyä sidottuna kyselymuotoon eikä koko objektin kokoon.

Mitä ei pidä väittää

• yleinen SQL-korvike
• valmis kyselymoottori kaikkiin ongelmiin
• todistettu 100M / 5GB tuotantovalmius

Miksi rangeReads on niin tärkeä mittari?

Todennäköinen kysymys

Eikö bytesRead riitä?

Lyhyt vastaus

Ei yksin riitä.

Pidempi vastaus

R2-latenssi kertyy paitsi luettujen tavujen määrästä, myös pyyntöjen määrästä. Siksi rangeReads on usein aivan yhtä tärkeä tai jopa tärkeämpi mittari kuin bytesRead.

Mikä ei ole vielä valmis?

Todennäköinen kysymys

Mitkä ovat suurimmat puutteet?

Lyhyt vastaus

Rajaukset on syytä myöntää suoraan.

Pidempi vastaus

Keskeiset keskeneräisyydet ovat:

• ei yleinen SQL-moottori
• ei laaja query-VM
• ei laajaa compression benchmarkointia
• ei formalisoitua consensus-mallia
• ei vielä riittävän kevyt liven käyttöliittymän kuuma polku
• ei vielä Kaupr-tasoista toimituksellista laatua
• ei vielä 100M / 5GB tuotantopolun näyttöä
• ei yhtenäistä viikon p50/p95 telemetriaa

Mitä projektista ei pidä väittää?

• ei pidä väittää, että ratkaisu korvaa yleiskäyttöisen SQL-ekosysteemin
• ei pidä väittää, että kaikki query-tyypit toimivat samalla tehokkuudella
• ei pidä väittää, että arkkitehtuuri poistaa datamallinnuksen kompromissit
• ei pidä väittää, että kyse on uudesta SQLite:sta tai yleisestä tietokannasta
• ei pidä väittää, että toimituksellinen tuote on jo valmis lopputuote
• ei pidä väittää, että consensus on jo formalisoitu tutkimusmalli