Multi-INT-yhtenäisen datamallin suunnittelu sotilastiedusteluympäristöihin

Jokainen vakavasti otettava sotilastiedusteluympäristö kohtaa ennen pitkää saman rakenteellisen ongelman: viisi tai useampi tiedustelusuunta tuottaa dataa omassa muodossaan, omalla nopeudellaan ja omilla semantiikoillaan — ja analyytikot tarvitsevat yhtenäisen kuvan, joka käsittelee kaikkia niitä samanaikaisesti. Puolustuksen datafuusion kattava opas käsittelee käsittelyprosessia laajassa mittakaavassa. Tässä artikkelissa syvennytään skeemakerrokseen — kanoniseen datamalliin, joka sijaitsee fuusiomoottorin alla ja tarjoaa sille johdonmukaisen pohjan.

Datamallin oikea suunnittelu ei ole yksityiskohta. Huonosti suunniteltu skeema pakottaa INT-kohtaisen logiikan sovelluskerrokseen, tekee eri lähteiden välisistä kyselyistä hauraita ja muuttaa skeemamigraatiot viikkojen mittaisiksi ympäristön jäädytyksiksi. Hyvin suunniteltu malli sopeutuu uusiin INT-tyyppeihin, tukee bi-temporaalisia kyselyjä ja säilyttää provenanssin kaikissa fuusion vaiheissa. Tässä artikkelissa käsitellään kaikki päätökset, jotka määrittävät kumpaan kategoriaan ympäristösi kuuluu.

Miksi jokainen INT tarvitsee erilaisen skeemaadaptaation

Viisi pääasiallista tiedustelusuuntaa eroavat toisistaan paitsi siinä, mitä ne keräävät, myös siinä, miten kyseinen data on jäsennetty, millä nopeudella se saapuu ja millainen metatadata on lähtökohtaisesti saatavilla. Nämä erot eivät ole pintapuolisia. Ne määrittävät, millainen adapterlogiikka tarvitaan ennen kuin mikään yhtenäinen malli voi ottaa vastaan tietolähteen, ja ne rajoittavat sitä, millaisia eri INT-lähteiden välisiä kyselyjä on mahdollista tehdä.

HUMINT (human intelligence) on ensisijaisesti tekstimuotoista. HUMINT-raportti on kertomusmuotoinen asiakirja, jossa kuvataan, mitä lähde on havainnut, kuullut tai saanut tietää. Aikaleimat ovat usein epätarkkoja — raportti voi kuvata tapahtuman, joka on saattanut tapahtua päivien kuluessa, sekä ajan että paikan epävarmuus huomioiden. Tärkein metatadata on lähteen arviointi: kuinka luotettava tämä lähde on, ja kuinka uskottava tämä yksittäinen tieto on? HUMINT-datan nopeus on matala — kiireisellä keräyspaikalla kymmeniä tai satoja raportteja päivässä, ei tuhansia sekunnissa.

SIGINT (signals intelligence) — johon kuuluu sekä COMINT (communications) että ELINT (electronic intelligence) — on nopeatempoista, jäsenneltyä ja millisekunnin tarkkuudella aikaleimattua. SIGINT-sieppaus tai lähettimen havainto sisältää taajuusparametrit, suuntakulmat, TDOA-paikanmääritykset ja modulaatioominaisuudet. Semanttinen sisältö (mitä sanottiin) on usein luokiteltu erikseen signaalin parametreistä. SIGINT-datan nopeus voi saavuttaa miljoonia tietueita tunnissa nykyaikaisessa keräysjärjestelmässä, joka kattaa riidanalaisen sähkömagneettisen ympäristön.

IMINT (imagery intelligence) tuottaa jäsenneltyjä havaintotietueita, jotka on johdettu kuvien analyysistä: rajaavia laatikoita entiteettiluokkatunnisteilla ja luottamuspisteillä, geolokointikoordinaatteja, maanäyteetäisyyttä ja keräysaikaleimaa. Yksittäinen satelliittikierros tai droonilento voi tuottaa tuhansia objektintunnistustietueita. Haasteena on, että IMINT-havainnot ovat tilallisia tilannekuvia — ne kertovat missä jokin oli tietyllä hetkellä, eivätkä mihin se on menossa.

OSINT (open-source intelligence) on rakenteellisesti heterogeenisin. Se sisältää sosiaalisen median julkaisuja, uutisartikkeleita, kaupallisten satelliittikuvien analyysejä, lentojen seurantadataa ja merenkulun AIS-syötteitä. Jokaisella lähdetyypillä on oma skeemansa. OSINT on myös vähiten hallittua — lähteiden laatu vaihtelee viranomaisten auktoritatiivisista julkaisuista anonyymeihin vahvistamattomiin some-väitteisiin.

MASINT (measurement and signature intelligence) kattaa fyysisten ilmiöiden mittaukset: seismisiä, akustisia, ydinmateriaali-, kemiallisia/biologisia ja tutkapoikkileikkausprofiileja. MASINT-havainnot ovat usein epäsuoria — ne havaitsevat ilmiön (räjähdyksen, ajoneuvon liikkeen, RF-emission) pikemminkin kuin tunnistavat entiteetin suoraan. Ketju MASINT-havainnosta entiteetin tunnistamiseen edellyttää eksplisiittisiä päättelyaskelia, jotka on mallinnettava skeemaan.

Tämä tarkoittaa yhtenäiselle mallille, että skeeman on kyettävä sopeutumaan tähän monimuotoisuuteen ilman sen hävittämistä. Ratkaisu on tyypitetty ydinkirjekuori (core envelope) ja suuntakohtaiset laajennushyötykuormat — suunnittelumalli, jota käsitellään yksityiskohtaisesti puolustuksen fuusioputken rakentaminen osa 1 -sarjassa.

Kanoniset entiteettityypit yhtenäiselle mallille

Skeemasuunnittelun lähtökohtana on entiteettityyppitaksonomian määrittäminen — tyhjentävä luettelo reaalimaailman asioista, joita ympäristön on seurattava ja käsiteltävä. Useimmissa sotilastiedusteluympäristöissä kuusi entiteettityyppiä kattaa valtaosan tiedustelukohteista:

• Henkilö — yksittäiset ihmiset: taistelijat, komentajat, avustajat, mielenkiintoiset siviilihenkilöt
• Organisaatio — ryhmät, yksiköt, verkostot, komentarakenteet
• Sijainti — kiinteät maantieteelliset kohteet: rakennukset, infrastruktuuri, maamerkit, nimetyt kiinnostusalueet
• Kalusto — ajoneuvot, asejärjestelmät, sensorit, viestintälaitteet
• Tapahtuma — yksittäiset tapahtumat: taistelut, räjähdykset, tapaamiset, lähetykset
• Asiakirja — haltuun otetut materiaalit, julkaisut, tiedustelurapportit analyysikohteina

Jokaisella entiteettityypillä on INT-agnostinen ydinkenttijoukko — kentät, jotka on täytettävä riippumatta siitä, mikä tiedustelusuunta on tiedon toimittanut:

EntityCore {
  entity_id:       UUID           // globally unique, immutable
  entity_type:     Enum           // Person | Organization | Location |
                                  // Equipment | Event | Document
  classification:  ClassMarkings  // see provenance section
  valid_time:      TimeInterval   // [start, end) when fact was true
  transaction_time:TimeInterval   // [start, end) when row was current
  confidence:      Float[0..1]    // fused confidence across sources
  source_obs_ids:  UUID[]         // contributing observation record IDs
  schema_version:  SemVer         // for evolution compatibility
  created_at:      Timestamp
  updated_at:      Timestamp
}

Ydinkenttien lisäksi jokaisella entiteettityypillä on tyypitetyt attribuuttilaajennukset. Henkilöentiteetti sisältää biometriset tunnisteet, aliakset, kansalaisuuden ja linkit liittyneisiin organisaatioihin. Kalustoentiteetti sisältää alustatyypin, sarjanumerot (mikäli tiedossa) ja linkin liittyneeseen yksikköön. Tapahtuma-entiteetti sisältää tapahtumaluokan, osallistuvien entiteettien viitteet ja tilallisen jalanjäljen. Nämä laajennukset tallennetaan tyypitettyinä hyötykuormina ydinkirjekuoreen kiinnitettyinä — ei sarakkeiden muodossa ydintaulussa. Tämä erottelu mahdollistaa sen, että skeema voi ottaa vastaan uusia attribuutteja yhdelle entiteettityypille vaikuttamatta muihin.

Sama erotteluperiaate koskee INT-kontribuutioita. Kun SIGINT-sieppaus linkittyy Henkilö-entiteettiin (koska IMSI on yhdistetty tunnettuun henkilöön), kyseinen linkki tallennetaan havaintotietueena, jossa on SIGINT-tyypitetty hyötykuorma ja viite Henkilö-entiteetin UUID:iin. Henkilöentiteetti itsessään ei kanna SIGINT-kohtaisia sarakkeita — tällainen kytkentä tekisi skeemasta hauraan mille tahansa SIGINT-keräyksen muutokselle.

Provenanssi ja lähteen seuranta

Provenanssi on minkä tahansa tiedustelun datamallin kriittisin ei-toiminnallinen vaatimus. Jokaisen fuusioidun tiedustelukuvan tiedon on oltava jäljitettävissä takaisin alkuperäishavaintoon, sen tuottaneeseen keräysjärjestelmään ja ihmisen tekemiin luotettavuusarvioihin. Ilman tätä ketjua analyytikot eivät voi arvioida työskentelemänsä tiedustelukuvan laatua, eikä ympäristö voi suorittaa palautusta, kun lähde todetaan epäluotettavaksi.

Provenanssilohkon, joka on liitetty jokaiseen havaintotietueeseen, tulee sisältää vähintään:

ProvenanceBlock {
  int_type:            Enum     // HUMINT | SIGINT | IMINT | OSINT | MASINT
  source_id:           UUID     // internal source registry reference
  source_reliability:  Char     // A–F (NATO admiralty scale)
  info_credibility:    Integer  // 1–6 (NATO admiralty scale)
  collection_time:     Timestamp
  report_time:         Timestamp  // when report entered system
  originator:          String     // unit or system that produced report
  classification:      ClassMarkings
  handling_caveats:    String[]   // NOFORN, ORCON, REL TO, etc.
  dissemination_ctrl:  String[]
}

NATO:n amiraalisteikko koodaa kaksi toisistaan riippumatonta ihmisarviointia jokaisesta tiedustelutiedosta. Lähteen luotettavuus (A–F) arvioi lähteen historiallista tarkkuutta ja luotettavuutta — A-luokiteltu lähde on ollut johdonmukaisesti tarkka ja luotettava; F-luokiteltu lähde on tuntematon tai heikosti arvioitu. Tiedon uskottavuus (1–6) arvioi yksittäisen tiedon uskottavuutta riippumatta lähteen historiasta — 1-luokiteltu tieto on vahvistettu muista riippumattomista lähteistä; 6-luokiteltu tieto on epätodennäköinen muun tiedetyn valossa.

Nämä kaksi arviota ovat koulutettujen tiedusteluvirkailijoiden tekemiä ihmisarviointeja. Ne ovat erillisiä eivätkä saa sekoittua koneen laskemaan fuusioluottamuspisteeseen entiteetillä. Fuusioluottamus heijastaa tilastollista yhdenmukaisuutta tukevien lähteiden kesken; amiraaliasteikkoarvosanat heijastavat ihmisen arviota lähteen laadusta. Molemmat on säilytettävä ja esitettävä analyytikoille erikseen.

Luokittelumerkinnät vaativat jäsennellyn esityksen, ei vapaata tekstiä. ClassMarkings-tyypin on koodattava: luokitustaso (UNCLASSIFIED – TOP SECRET), osastot ja koodisanat sekä käsittelyrajoitukset lueteltuna listana. Rakenne mahdollistaa ohjelmallisen pääsynvalvonnan täytäntöönpanon — ympäristö voi kyselyhetkellä arvioida, täyttääkö tietyn käyttäjän turvaselvitys kunkin kentän luokituksen vaatimukset, ja se voi valikoivasti peittää tai pidättää kentät, jotka ylittävät käyttäjän turvaselvitystason, sen sijaan että koko entiteetti evättäisiin.

Eri INT-lähteiden välinen entiteettien yhdistäminen

Entiteettien yhdistäminen — sen määrittäminen, viittaavatko eri lähteistä peräisin olevat tietueet samaan reaalimaailman entiteettiin — on fuusion ydinongelma, ja se on vaikeimmillaan juuri eri INT-lähteiden välisellä rajalla. Saman INT-suunnan sisällä tunnistejärjestelmät ovat yhdenmukaisia: kaksi SIGINT-tietuetta, joissa on sama IMSI, viittaavat samaan laitteeseen. Eri INT-lähteiden välillä ei oletusarvoisesti ole yhteistä tunnistetta. IMINT-havainnolle ajoneuvosta, SIGINT-suuntimalle lähettimelle, joka on sijoitettu kyseiseen ajoneuvoon, ja HUMINT-raportille, joka nimeää ajoneuvossa nähdyn henkilön, täytyy muodostaa linkki todennäköisyyspäättelyn kautta, ei jaetun avaimen avulla.

Yhtenäisen mallin entiteettien yhdistämisputken on käsiteltävä kolmea linkitysskenaariota:

Kovat linkit — jaetut tunnisteet, jotka yhdistävät tietueet ehdottomasti samaan entiteettiin. Tunnettu IMSI, rekisterikilpilukema kahden IMINT-kierroksen tekemänä, biometrinen vastaavuus. Kovat linkit tulee levittää automaattisesti ilman luottamuspisteytyksen heikkenemistä.

Pehmeät linkit — todennäköisyyspohjaiset yhteydet, jotka perustuvat attribuuttien samankaltaisuuteen epävarmuuden rajoissa. Kaksi havaintoa, jotka raportoivat saman luokan ajoneuvon päällekkäisillä sijainneilla aikavalikon sisällä, joka sopii yhteen niiden välisen liikkumisen kanssa. Pehmeät linkit kantavat vastaavuusluottamuspisteitä, jotka ratkaisumoottori laskee.

Johdetut linkit — toimialatietoon perustuvat yhteydet: jos SIGINT-lähettimen suuntima liikkuu johdonmukaisesti yhdessä IMINT-ajoneuvon jäljen kanssa, ne ovat todennäköisesti sama alusta. Nämä linkit vaativat eksplisiittisiä sääntömäärityksiä ja kantavat matalampia luottamuspisteitä kuin suoran attribuuttien päällekkäisyyden perusteella tehdyt pehmeät linkit.

Yhdistämisputki tuottaa vastaavuushypoteeseja. Korkean luottamuskynnyksen ylittävät hypoteesit yhdistetään automaattisesti kultaiseen tietueeseen. Keskivälissä olevat hypoteesit merkitään analyytikon tarkastettaviksi. Matalan kynnyksen alapuolelle jäävät hypoteesit säilytetään erillisinä entiteetteinä. Kynnysarvot ovat konfiguroitavissa ja tulee voida säätää entiteettityypeittäin — Henkilö-entiteettien yhdistäminen edellyttää korkeampaa luottamuskynnystä kuin Kalusto-entiteettien yhdistäminen, koska väärät henkilöiden yhdistämiset tuottavat pahempia analyyttisiä seurauksia kuin väärät kaluston yhdistämiset.

Kultaisen tietueen hallinta edellyttää määriteltyä yhdistämiskäytäntöä attribuuttien ristiriitojen varalle. Kun kaksi lähdettä on eri mieltä attribuutista — yksi HUMINT-raportti sanoo henkilön olleen sijainnissa A, IMINT-havainto sijoittaa hänet sijaintiin B tunnin myöhemmin — yhdistämiskäytännön on määriteltävä, miten attribuutti sovitetaan kultaisessa tietueessa. Yleisiä käytäntöjä ovat: viimeisin valid time voittaa, korkein lähdearvioluokitus voittaa, painotettu yhdistelmä numeerisille attribuuteille. Valittu käytäntö on tallennettava kultaiseen tietueeseen metatietona, jotta analyytikot ymmärtävät, miksi kultainen tietue näyttää tiettyä attribuuttiarvoa.

JDL-datafuusiomalli hahmottaa entiteettien yhdistämisen tason 1 (objektin tarkennus) ja tason 2 (tilanteen tarkennus) ongelmana. Tässä kuvattu skeemasuunnittelu on se, mikä tekee JDL-tasoista käytännössä toteutettavia.

Temporaalinen mallinnus: valid time vs. transaction time

Bi-temporaalinen mallinnus ei ole valinnainen sotilastiedusteluympäristölle. Se on minimaalinen temporaalinen rakenne, joka tarvitaan tukemaan kahta kriittisintä kyselytyyppiä: "mitä maailmassa oli totta hetkellä T?" (valid time -kysely) ja "mitä järjestelmä tiesi kohteesta X hetkellä T?" (transaction time -kysely). Nämä ovat eri kysymyksiä, jotka vaativat eri vastauksia, eikä skeema, joka sekoittaa ne — käyttämällä yhtä aikaleimaa per tietue — voi vastata kumpaankaan oikein.

Valid time edustaa sitä, milloin fakta oli tosi reaalimaailmassa. IMINT-havainnolle ajoneuvosta ruudukkopaikassa valid time on kuvauksen aikaleima. HUMINT-raportille, joka kuvaa kokousta, valid time on analyytikon paras arvio kokouksen ajankohdasta — joka voi olla päivien vaihteluväli, ei tarkka aikaleima. Valid time on maailman ominaisuus, ei tietokanta-ominaisuus.

Transaction time edustaa sitä, milloin tietue oli ajankohtainen tietokannassa. Samalle IMINT-havainnolle transaction time alkaa, kun havaintotietue lisättiin, ja päättyy, jos tietue koskaan korvataan (esim. jos geolokaatio käsitellään uudelleen ja korjataan). Transaction time on tietokannan ominaisuus, jonka järjestelmä hallinnoi automaattisesti.

Yhdistelmä mahdollistaa kaksi kriittistä operaatiota. Ensinnäkin as-of-kyselyt: "rekonstruoi täydellinen tiedustelukuva sellaisena kuin järjestelmä piti sitä päivänä D klo 14:00." Tämä edellyttää kyselyä transaction time:n yli — palautetaan vain tietueet, jotka olivat ajankohtaisia tietokannassa päivänä D klo 14:00, riippumatta siitä, milloin niiden valid time osuu. Tämä on olennaista tapauksen jälkeiselle analyysille ja tiedusteluun perustuvien päätösten auditoimiselle. Toiseksi historialliset faktakyselyt: "mitä tapahtumia esiintyi sijainnissa X päivien D-7 ja D välillä?" Tämä kyselee valid time:n yli — palautetaan tietueet, joiden valid time -väli leikkaa kyselyikkunan, riippumatta siitä, milloin ne lisättiin.

PostgreSQL-toteutuksessa käytetään periodikolumneja. Valid time -dimensio esitetään tstzrange-kolumnina (aikavyöhyketta huomioiva aikaleima-alue). Transaction time -dimensio käyttää joko system-period temporal table -lähestymistapaa (natiivisti tuettu joissain PostgreSQL-laajennuksissa) tai eksplisiittistä transaction_start- ja transaction_end-kolumniparisoa, jossa transaction_end on asetettu äärettömyyteen nykyisille riveille ja leimataan päivityksessä osoittamaan, milloin rivi korvattiin. Kaikki päivitykset on toteutettava lisää-uusi-rivi / leimaa-vanha-rivi -operaatioina, ei koskaan in-place-kirjoituksina.

Versionhallinta ja lineage fuusioiduille objekteille

Tiedusteluentiteetit eivät ole staattisia. Henkilöentiteetti voi alkaa epävarman tunnistuksen muodossa yhdestä HUMINT-raportista, saada tilallisen vahvistuksen IMINT-havainnosta kolme päivää myöhemmin ja saada biometrisen vahvistuksen erillisestä keräystapahtumasta viikkoa sen jälkeen. Jokainen näistä päivityksistä muuttaa kultaista tietuetta — mutta aiemmat tilat on voitava palauttaa, ei kirjoittaa niiden päälle.

Vakiototeutus on append-only-tapahtumaloki per entiteetti. Jokainen tilamuutos kultaisessa tietueessa luo päivitystapahtuman. Jokainen tapahtuma on muuttumaton sen kirjoittamisen jälkeen ja sisältää:

• Entiteetin UUID:n
• Tapahtumatyypin (Created / Updated / Merged / Split / Retracted)
• Edellisen tilavedoksen (täydellinen kopio kultaisesta tietueesta ennen muutosta)
• Uuden tilavedoksen
• Päivityksen laukaisseiden havaintotietueiden tunnisteet
• Käytetyn fuusiokäytännön nimen ja version
• Transaction timestamp -leiman
• Operaattorin tunnisteen (ihmisanalyytikko tai järjestelmäprosessi)

Nykyinen kultainen tietue on tulos kaikkien tapahtumien soveltamisesta järjestyksessä lokia alusta lähtien. Tämä on event-sourcing-malli sovellettuna tiedustelutietoon. Se tarjoaa täydellisen auditointipolun kaikille entiteettien tiloille kaikissa ajankohdissa, mitä vaaditaan tiedustelun vastuullisuuteen useimmissa sotilaskehyksissä.

Palautus on ensimmäisen luokan operaatio: annetulla entiteetin UUID:lla ja kohde-transaction-aikaleimalla ympäristö rekonstruoi kultaisen tietueen sellaisena kuin se oli kyseisellä hetkellä toistamalla tapahtumalokia alusta saakka, mutta ei sisältäen kohdeajan jälkeisiä tapahtumia. Palautus käynnistyy, kun lähde arvioidaan petolliseksi tai virheelliseksi — kaikki kultaiset tietueet, jotka sisälsivät kyseisen lähteen havaintoja, on arvioitava uudelleen saastuneet havainnot poissulkien.

Peruutustapahtuma on mekanismi tämän skenaarion käsittelyyn laajassa mittakaavassa. Kun lähde S mitätöidään, järjestelmä luo peruutustapahtuman jokaiselle S:lle attribuoidulle havainnolle ja suorittaa fuusion uudelleen jokaiselle entiteetille, joka viittasi johonkin näistä havainnoista. Entiteetit, joita tuki yksinomaan peruutettu lähde, palaavat matalampaan luottamustilaan tai merkitään vahvistamattomiksi. Entiteetit, joilla oli tukevat lähteet muista INT-suunnista, absorboivat peruutuksen luottamuspisteenalennuksella mutta pysyvät kuvassa.

Lineage-malli mahdollistaa myös jakaantumistapahtumat — entiteettien yhdistämisen käänteisoperaation. Jos kaksi entiteettiä yhdistettiin virheellisesti (väärä fuusiopositiivi), jakaantumistapahtuma purkaa yhdistämisen: virheellinen kultainen tietue peruutetaan ja kaksi uutta entiteettitietuetta luodaan, joista kumpikin perii sille kuuluvat lähdehavainnot. Jakaantumistapahtuma säilyttää täydellisen historian yhdistetystä tilasta ja jakaantumispäätöksestä, jolloin myöhemmät analyytikot voivat ymmärtää, miksi jakaantuminen tapahtui.

Skeeman kehittäminen tuotantoympäristössä

Sotilastiedusteluympäristö ei ole staattinen tuote. Uusia keräysjärjestelmiä otetaan käyttöön, uusia INT-suuntia lisätään laajuuteen ja olemassa olevia skeemoja tarvitsee attribuuttilisäyksiä uusien analyyttisten vaatimusten myötä. Skeeman kehittäminen tuotantoympäristössä, joka ei siedä käyttökatkoksia, edellyttää harkittuja suunnittelupäätöksiä alusta alkaen.

Periaatteena on taaksepäin yhteensopivuus sopimuksena. Ydinentiteettikuori — EntityCore-kentät — on oltava tarkasti versioitu schema_version-kentän avulla. Mikä tahansa ydinkirjekuoren muutos, joka poistaa kentän tai muuttaa kentän tyyppiä, on rikkova muutos ja vaatii pääversiopäivityksen määritellyllä migraatiopolulla. Valinnaisten kenttien lisääminen ydinkirjekuoreen on pienversiomuutos. Versioida mahdollistaa kuluttajien ilmoittaa, mitä skeemaversioita ne tukevat, ja mahdollistaa ympäristön palvella eri versioita eri kuluttajille migraatiojakson aikana.

Laajennushyötykuormat ovat oikea väline uusien INT-tyyppien tai uusien attribuuttien lisäämiseen. Kun uusi kuvantamisanalyysijärjestelmä otetaan käyttöön ja se tuottaa lisäattribuuttityyppejä (esimerkiksi rakenteellisten vaurioiden arviointipisteitä SAR-kuvista johdettuna), nämä attribuutit menevät uuteen tai päivitettyyn IMINT-laajennushyötykuormaversioon — ei ydinentiteettiskeemaan. Olemassa olevat kuluttajat, joilla ei ole tarvetta SAR-kohtaisille attribuuteille, pysyvät muuttumattomina.

Provenanssin taksonomia on laajennettava, kun uusi INT-tyyppi lisätään. INT-tyypin luettelointi saa uuden arvon, ja lähteen luotettavuus- ja uskottavuusasteikkojen määrittelyt on tarkistettava soveltuvuuden osalta uuteen lähdetyyppiin nähden. Jotkut uudet lähdetyypit saattavat vaatia uusia uskottavuuskriteerejä, jotka eivät kartoitu siististi olemassa olevaan kuusipisteiseen amiraalisteikkoon — siinä tapauksessa provenanssilohkon tulisi kantaa raaka lähdekohtainen luotettavuusmetatiedon lisäksi käännettyä amiraaliasteikkoarvosanaa, jotta tarkkuus säilyy.

Entiteettien yhdistämissäännöt ovat työläin kehityspolku. Kun uusi INT-tyyppi liittyy yhtenäiseen malliin, ratkaisuinsinöörien on määriteltävä, miten uuden lähteen havainnot voidaan linkittää olemassa oleviin entiteettityyppeihin. Tämä edellyttää sekä data-analyysiä (mitä attribuutteja on saatavilla yhdistämistä varten?) että toimialatietoa (mitkä attribuuttien läheisyyskynnykset ovat operatiivisesti merkityksellisiä?). Nämä säännöt on kokeneiden tiedusteluanalyytikkojen vertaisarvioitava, ei pelkästään ohjelmistoinsinöörien — virheelliset yhdistämissäännöt tuottavat vääriä fuusioita, jotka pilaavat tiedustelukuvan hiljaisesti.

Skeemamigraatio bi-temporaalisessa mallissa tuo lisäkonsideraation: historialliset rivit on migroitava muuttamatta niiden transaction time -historiaa. Migraatio, joka kirjoittaa olemassa olevat rivit uudelleen ja päivittää niiden transaction-aikaleimoja, rikkoo historialliset kyselysemantiikan. Migraatioiden on oltava additiivisia: lisää uudet kolumnit oletusarvoilla historiallisille riveille, älä koskaan päivitä olemassa olevia kolumniarvoja historiallisissa tietueissa.

Skeeman kehityksen testaaminen edellyttää monitasoista strategiaa: yksikkötestit kunkin skeemaversion serialisoinnille ja deserialisoinnille; integraatiotestit eri versioiden kuluttajayhteensopivuudelle; ja regressiotestit historiallisilla tiedusteludatanäytteillä vahvistamaan, että olemassa olevat kyselyt palauttavat identtiset tulokset migraation jälkeen. Historialliset datatestit ovat niitä, joita ohitetaan useimmiten, ja ne ovat niitä, jotka havaitsevat eniten tuotantoa hajottavia regressioita.

Tässä artikkelissa kuvattu datamalli edustaa suunnittelutavoitetta, ei yhden sprintin toteutuksen lähtökohtaa. Useimmat ympäristöt rakentuvat kohti tätä arkkitehtuuria vaiheistettuna — aloittaen yksinkertaisemmalla skeemalla kahdelle tai kolmelle INT-tyypille ja lisäten bi-temporaalisen mallin, täydet provenanssilohkot ja event-sourcing-lineagen operatiivisten vaatimusten selkiydyttyä. Tärkeintä on, että ydinsuunnittelupäätökset — tyypitetyt laajennushyötykuormat, INT-agnostiset entiteettikuoret, eroteltu valid time ja transaction time — tehdään varhain, koska niiden jälkikäteen rakentaminen monoliittiseen skeemaan on huomattavasti kalliimpaa kuin niiden sisäänrakentaminen alusta alkaen.