Kera és a leépítés munkája
The bug report that was not a bug
The story usually starts with a number that is nearly right. Not wildly wrong. Not broken in a way that makes the dashboard red. Nearly right in the expensive way: the sort of wrong that lets one team ship, another team hesitate, and an auditor ask why the answer changed when the same model moved from one machine to another.
One build runs on an x86 server and produces a value. The next build runs on an ARM laptop and produces a value close enough that ademo survives. A GPU path is faster but rounds through the computation differently. An FPGA path is attractive for timing but suddenly the software team is having a hardware conversation. Everyone can explain a small piece of the difference. Nobody owns the whole path from source to result.
That is the space Kera is built for. Not the model idea, not the marketing slide, not a paper about a future compiler, but the compiler work that begins once a team says the same computation must run on different machines andstill mean the same thing. That obligation needs an owner. The compiler promise is not that lowering is elegant. The promise is that lowering is treated as work.
Lowering is the part of a compiler where nice language intent becomes instructions that a target can execute. It is also where vague claims become visible. If the result is supposed to be bit for bit identical across CPU, GPU, FPGA, and WebAssembly, then the compiler cannot shrug at target differences. It has to carry enough structure to decide what maychange and what must not change. It has to know memory spaces, effects, opcodes, data movement, target limits, and the receipts that prove two builds are the same computation.
The tempting version of the story is to call this a portability layer. That is too small. Portability says the program runs elsewhere. Kera is aiming at the harder statement: the program is represented as a content-addressed graph, compiled to a .keg artifact, lowered to multiple backends, and still produces the same answer. The kitchen changes. The recipe does not.
The middle nobody wants to sell
The first conversation with a serious buyer rarely begins with syntax. It begins with a mess. There is a model that matters. There is a simulation that used to be research and has become operational. There is a risk calculation whose result is no longer allowed to vary by machine. There is an edge deployment that cannot carry the full cloud runtime. There is a team that wants an accelerator but cannot afford a rewrite every time the accelerator changes.
Most tooling makes this look like a deployment problem. Choose the target, export the model, patch the runtime, accept some variance, then write a document explaining the exceptions. The document grows. The test matrix grows. The number of specialists grows. Eventually the organisation is paying for heterogeneity twice: once when it buys the hardware, again when it tries to prove the hardware did the same work.
Kera starts from the opposite end. The Kera page calls it a statically typed systems language with a graph-native, content-addressed IR. That phrase matters because the graph is not a decorative compiler diagram. It is the executable object. Source code lowers into directed acyclic graphs of operations, stored as .keg files. Each node carries defined structure. Duplicate work can be eliminated structurally. The same graph can be lowered to CPU, GPU, FPGA, and WASM without treating every target as a separate little universe.
Ezért kell a Kerának komoly fordító infrastruktúraként viselkednie, nem pedig diagramként. A kényelmetlen középút az, ahol az ügyfél él. A tokenizálásnak meg kell őriznie a bájtpozíciókat. Az elemzésnek a fordítás mellett az eszközöket is táplálnia kell. A típusellenőrzésnek el kell utasítania az alak- és él-eltéréseket, mielőtt azok futásidőbeli eseményekké válnának. A kölcsönzés-ellenőrzésnek meg kell értenie a tulajdonlást a hoszt, az eszköz, a rögzített és az egyesített memória között. Az optimalizálásnak megismételhetőnek kell lennie. A szerializációnak olyan artefaktumot kell adnia a szervezetnek, amelyet meg tud őrizni.
Egyik sem hangzik szenzációs címsorként. Sokkal hasznosabb, mint egy címsor. Azt jelenti, hogy amikor egy munkaterhelés a fejlesztésből a termelésbe kerül, vagy egy CPU-alapvonalról GPU-útvonalra vált, a fordítónak van egy stabil összehasonlítási pontja: a gráf-ujjlenyomat. Ha az ujjlenyomat egyezik, a munka ugyanaz a munka. Ez egy közös ellenőrzési pont, amelyet mérnök, vásárló és könyvvizsgáló egyaránt megért.
A gráf nyugta, nem kép
A program magyarázatának régi módja az, hogy megmutatjuk a forrást, és megkérjük az olvasót, hogy bízzon a fordítóban. A Kera oldala folyamatosan egy másik objektumhoz tér vissza: a gráfhoz. Minden művelet egy csomópont. Az élek függőségeket fejeznek ki. A gráfnak van tartalma. A tartalomnak van hash-e. A hash olyan ujjlenyomattá válik, amely végigutazik a builden.
Ez belső gépezetnek hangzik, amíg nem állsz egy megfelelőségi csapat mellett. Egy megfelelőségi csapat nem azt akarja tudni, hogy a szállítónak szép fordítóarchitektúrája van. Azt akarja tudni, hogy a múlt hónapban jóváhagyott számítás az-e, amely ma fut. A gráf-ujjlenyomat a híd a két világ között. Nem képernyőkép a fordítóról. Kompakt módja annak, hogy kijelentsük: ez a műveletkészlet, ezek a típusok, ezek a bemenetek, ezek az attribútumok, ez a függőségi szerkezet.
A csomópontmodell szándékosan szigorú. Egy csomópont sémaverzióból, opkódból, kimeneti leírókból, bemeneti hash-ekből és attribútumtérképekből áll, kanonikus sorrendben elrendezve. A bájtokat SHA3-256-tal hash-elik tartomány-szeparált előtagok alatt, így a csomópont-, régió- és gráf-hash-ek külön névterekben élnek. Ha két csomópontnak ugyanaz az opkódja, bemenete és attribútumai, akkor ugyanaz a hash-ük. A duplikátum beszúrása a meglévő bejegyzést adja vissza. A közös rész-kifejezés elimináció a reprezentáció következményévé válik, nem pedig egy hősies passzus, amelyet később adnak hozzá.
Ez az a fajta részlet, amely egy mérnöki rendszert olyasmivé tesz, amelyre az emberek támaszkodhatnak. A vásárló nem fordítódiagramot vásárol. A vásárló kevesebb vitát vásárol arról, hogy megváltozott-e egy számítás. A fejlesztő nem a determinisztikus MI szlogenjét vásárolja. A fejlesztő olyan gráfformátumot vásárol, ahol az azonosság ellenőrizhető, tárolható és eszközök által használható. A .keg fájl ezért nem utólagos megvalósítási gondolat. A munka hordozható nyilvántartása.
A nyolc kis ajtó, mielőtt egy cél megjelenik
Amikor az emberek fordítóprogramra gondolnak, gyakran egyből a háttérrétegre ugranak. Elképzelik a pillanatot, amikor a kódból AVX, PTX, Verilog vagy WASM lesz. Ez a pillanat számít, de a történetben már későn jön. A fordítóprogram munkájának nagy része addigra már megtörtént, csendes szakaszokban, amelyek eldöntik, hogy a háttérrétegben meg lehet-e bízni.
A Kera egy UTF-8-kompatibilis lexerrel kezdődik, amely a forrást teljes trivia-követéssel és hibajavítással tokenekké alakítja. Ez szerkesztői segédrendszernek hangzik, és az is. De ez egyben az eszközlánc megbízhatósága is. Ha minden bájtpozíció megmarad, a diagnosztika, a formázás, az inkrementális újraelemzés és a nyelvi szerver viselkedése összhangban lehet azzal, amit a felhasználó valójában írt. Az a fordítóprogram, amely korán elveszíti a forrás alakját, mindenhol máshol fizet meg ezért a veszteségért.
Az elemző eseményalapú: a rekurzív leszállás Pratt-kifejezéselemzéssel Start, Token, Finish és Error eseményeket bocsát ki, ahelyett hogy egyetlen AST-t építene, amelyet mindenkinek meg kell osztania. Az eseményfolyam táplálja a faépítőt, a formázót és a nyelvi szervert egymástól függetlenül. A zöld fa veszteségmentes, megőrzi a tokeneket és a triviákat. A gráfépítő ezután bejárja ezt a fát, fenntartja a névfeloldást, és függvényenként egy Region csomópontot hoz létre.
Csak ezután válik a forrásból az a gráf, amelyet a fordítóprogram hordoz. A strukturális típusellenőrzés ellenőrzi a kompatibilitást a műveleti élek mentén és a tenzoralak-korlátok között. A típusok csak akkor egyeznek, ha a kanonikus hash-ük azonos. A kölcsönzésellenőrző értékenként egy tulajdonost kényszerít ki, nem enged meg aliased változtatható referenciákat, és a tulajdonlási szabályokat a memóriaterek között is betartatja. A hatásannotációk konzisztenciáját ellenőrzik. A mellékhatások nincsenek ízlésre vagy konvencióra bízva.
Az optimalizációs folyamatkezelő ezután elvégzi a felismerhető fordítóprogram-munkát: konstansösszevonás, közös részkifejezés-küszöbölés, holtkód-elimináció, beillesztés, vektorizálás és ciklusfúzió egy fixpontos ciklusban. A fontos kifejezés nem a folyamatok listája. Hanem az, ami minden folyamat után történik: egy gráfinvariáns-ellenőrző ellenőrzi a hash-konzisztenciát és a függőségi integritást. Az optimalizálás javíthatja a gráfot, de nem teheti azt átláthatatlanná.
Végül a cél-specifikus kódgenerátorok natív kódot, PTX-et, Verilogot vagy WASM-ot állítanak elő, és az optimalizált gráf egy .keg fájlba szerializálódik szakasztáblával. A fájl a KEG\0 mágikus bájtokkal kezdődik, és szakaszokat hordoz karakterláncokhoz, típusokhoz, attribútumokhoz, csomópontokhoz, régiókhoz és exportokhoz. Ez az az út, amelyet egy csapatnak birtokolnia kell, mielőtt őszintén beszélhet a célokról.
A célok nem matricák egy dián
A célok listáját könnyű megírni, de nehéz kiérdemelni. A CPU, GPU, FPGA és WASM szépen elfér egy termékkártyán. A rájuk való lefordítás az, ahol a számla el van rejtve. Minden célnak megvannak a maga szokásai, erősségei és meghibásodási módjai. Egy fordítóprogram, amely determinisztikus heterogén végrehajtást szeretne, nem kezelheti ezeket a szokásokat valaki más problémájaként.
CPU-kon a Kera natív gépi kódot állít elő x86-64 és ARM64 architektúrára, a RISC-V Vector pedig a műszaki adatlapon szerepel. Az x86-os útvonal SSE2, AVX2 vagy AVX-512 kiválasztását teszi lehetővé; az ARM-os útvonal a NEON-t használja; a regiszterkiosztó és az ütemező közös. A termék állítása nem csupán az, hogy létezik egy bináris. Az állítás az, hogy a cél-specifikus SIMD kernelek kiválasztása úgy történik, hogy a gráf ugyanaz a számítás marad.
GPU-kon a forrásanyag a PTX-generálást említi CUDA és ROCm esetén, tenzormagokkal, amikor a kernel alakja ezt lehetővé teszi. Ez az utolsó kitétel fontos szerepet játszik. A hardveres gyorsítás nem varázspor. Egy kernel alakja vagy illeszkedik a tenzormagos útvonalhoz, vagy nem. A fordítónak ezt őszintén fel kell tárnia, szükség esetén át kell mozgatnia az adatokat a hoszt és az eszköz között, és továbbra is a gráf ujjlenyomatát kell bizonyítékként megőriznie arra vonatkozóan, hogy mi kerül végrehajtásra.
FPGA-n a lowering útvonal hardveres párbeszéddé válik: Verilog-szintézis, erőforrás-becslés, időzítési elemzés és pipeline-ütemezés a kiszámítható, cikluspontos viselkedés érdekében. Ez az a fajta cél, ahol a kézlegyintés különösen drága. Ha a vásárlónak valós idejű követelményei vannak, a fordító felületének ciklusokban, erőforrásokban és pipeline-okban kell beszélnie, nem csupán sebességben. A Kera története az FPGA-t ugyanannak a gráfnak a háttérrendszerévé teszi, nem pedig egy másik csapat által végzett újraírás tárgyává.
WASM esetén az oldal 128 bites SIMD-t említ az edge és a böngészős telepítéshez. Ez azért fontos, mert az edge az a hely, ahol a telepítési valóság gyakran ütközik a tisztasággal. Egy böngésző, egy kis eszköz vagy egy korlátozott futásidejű környezet nem mindig tudja ugyanazt a stacket futtatni, mint egy szerver. A gráf-natív lowering útvonal lehetőséget ad a csapatnak, hogy ugyanazt a számítást vigye át ebbe a környezetbe anélkül, hogy az edge külön termékké válna.
A determinizmusnak túl kell élnie a sikert
A determinizmust könnyű megígérni egy kis szobában. Nehezebbé válik, amikor a termék sikeres lesz. Több felhasználó érkezik. Több hardver jelenik meg. Egy modell átkerül egyik chipről a másikra. Egy teszt-alapvonal, amelyet egyik környezetre írtak, egy másikat is le kell fedjen. Egy ártalmatlannak tűnő optimalizáció megváltoztatja egy redukció sorrendjét. Egy gyors útvonal megjelenik az egyik futásidejű környezetben, de a másikban nem.
A Kera oldal a determinizmust platformok közötti bitenkénti azonosságként keretezi. Ez nem pusztán esztétikai állítás. Megváltoztatja a termékkel kapcsolatos kötelezettségeket. A primitív aritmetikának definiált pontossági szemantikája van minden célplatformon. A redukcióknak definiált döntetlenfeloldásuk van, így az ütemezés és a hardver nem változtatja meg az eredményt. A neurális hálózati primitívek determinisztikus implementációval rendelkeznek CPU-n, GPU-n, FPGA-n és WASM-on. A gráf ugyanazt jelenti, bárhol is fut.
Ezért az undefined behaviour, a szemétgyűjtő szünetei és az implicit mellékhatások nem apró nyelvi preferenciák. Ezek repedések a végrehajtási felületen. A Kera oldala azt mondja: nincs LLVM-függőség, nincs szemétgyűjtő, nincs undefined behaviour. Az explicit típusok, az explicit effektusok és a memóriaterületek közötti tulajdonlás termékvezérlők. Csökkentik azoknak a helyeknek a számát, ahol az eredmény megváltozhat, miközben mindenki másra figyel.
Ennek van emberi oldala is. Amikor egy robotikavezérlő viselkedése eszközönként változik, amikor egy pénzügyi munkafolyamat egy centet másképp kerekít, amikor egy tudományos eredményt egy bíráló nem tud megismételni, vagy amikor egy játékszimuláció eltér a célplatformok között, a vita valójában nem a fordítóelméletről szól. Az intézményi bizalomról szól. A Kera fogyasztói szövege egyszerű történeteket használ, mert a mögöttes problémát egyszerű átérezni: ugyanazok az utasítások, ugyanaz az eredmény, bármelyik számítógépen, amely a tiéd.
Ennek a bizalomnak túl kell élnie a gyorsítást. Ha a teljesítmény megköveteli, hogy a csapatok feladják a determinizmust, a termék csak áthelyezte a kockázatot. A Kera megpróbálja a teljesítményt és a determinizmust ugyanabban a szerződésben tartani azzal, hogy a gráfot teszi a jelentés egységévé, a célútvonalat pedig a végrehajtás egységévé.
A biztonság a lowering része
A fordítókkal kapcsolatos viták gyakran elkülönítik a biztonságot futásidejű feladatként. A Kera forrásanyaga nem teszi ezt. Beszél a képességalapú biztonságról, egy SecurityManagerről, egy alapértelmezésben tiltó kapuról, egy PolicyBuilderről, a seccomp BPF-ről, a Linux névterekről és egy szálbiztos, manipulációt jelző auditnaplóról rögzített kapacitású gyűrűpufferben. Ezek a szavak a mérnöki történethez tartoznak, mert a lowering nem ér véget, amikor az utasítások elkészülnek. Az elkészült munkának még határok között kell futnia.
A képességtokeneket indításkor adják ki. A kiemelt jogosultságú műveletekhez explicit képesség szükséges. A hozzáférési szabályokat előre deklarálják. Egy BPF-szűrő korlátozza a rendszerhívásokat. A névtér-izoláció szétválasztja a folyamat-, a mount- és a hálózati nézeteket. A biztonsági szempontból releváns események az auditnaplóba kerülnek. A rövid mondat ez: alapértelmezésben semmi sem engedélyezett.
Ez a heterogén végrehajtás szempontjából fontos, mert a célplatformok felületeket hoznak létre. Egy CPU-folyamat, egy GPU-átvitel, egy FPGA-út, egy böngészőfuttatókörnyezet és egy elosztott feladat nem azonos módon hibásodik meg. Egy terméknek a munkához kell kötve tartania a szabályzatot, ahogy az mozog. Ha a gráf azt mondja meg, mi a számítás, a futásidejű vezérlők azt mondják meg, mit tehet a számítás.
Van operatív ok is arra, hogy a biztonságot bevigyük a fordítós történetbe. A csapatok nem akarnak egy terméket a fordításra, egy másikat a szabályzatkezelésre, egy harmadikat a naplózásra és egy negyediket a magyarázatra, ha a köztük lévő illesztések válnak azzá a hellyé, ahol az incidensek elrejtőznek. A Kera oldala nem állítja, hogy minden biztonsági problémát megold. Valami szűkebbet és hasznosabbat tesz: explicité és auditálttá teszi az engedélyeket abban a végrehajtási környezetben, amelyet a fordító táplál.
Az elosztott munka is lowering
A műszaki adatlap megnevezi az elosztott végrehajtást, a ring allreduce-öt és az ellenőrzőpont-helyreállítást. Egy másik termékben ezek brosúraelemek lehetnének. A Kerában ugyanahhoz a lowering-beszélgetéshez tartoznak, mert a párhuzamosság megváltoztatja a számítás alakját. Az adat-, a modell- és a csővezeték-párhuzamosság nem csak a gyorsítás módjai. A munka felosztásának módjai anélkül, hogy az eredeti gráf jelentése elveszne.
Ha egy nagy feladat sok gépen fut át, és egy csomópont meghibásodik, a checkpointból való helyreállítás nem kényelmi szolgáltatás. Ez a számítási feladat üzemképessé tételének része. Ha az eredményeket megbízhatóan aggregáljuk, az aggregációs szemantikát definiálni kell. Ha egy gráf tartalom-címzett, az elosztott útnak meg kell őriznie a gráf identitását, nem pedig egy második valóságot kitalálnia, amint a feladat elhagyja az egyik gépet.
Itt válik világossá a termékértelmezés. A Kera nem egy szintaxisréteg elosztott kiegészítővel. Arra törekszik, hogy a számítást alakban és hardverben is hordozhatóvá tegye: egy program, egy gráf, több végrehajtási célpont, és egy ellenőrizhető rekord. Az elosztott végrehajtás csak egy újabb hely, ahol a loweringnek hordoznia kell a végrehajtási szerződést.
Ez a személyzeti történetet is megváltoztatja. Megosztott fordítási út nélkül egy olyan hiba, amely csak egy platformon jelenik meg, olyan embereket igényelhet, akik egyszerre ismerik a chipet, a toolchain-t és a futásidőt. Egy gráffal és egy megosztott úttal élesebb a kérdés: a gráf változott, a lowering út változott, vagy a célpont sértette meg a definiált szemantikát? A jobb kérdések nem szüntetik meg a kemény munkát. Megakadályozzák, hogy a kemény munka véletlenszerűen terjedjen.
Miért kell valakinek birtokolnia az utat
A lowering nem maradhat gazdátlan, ha olyan eredményeket hordoz, amelyekre az emberek támaszkodnak. Egy gráf, amely CPU-n, GPU-n, FPGA-n és WASM-on fut, többet igényel egy okos reprezentációnál. Dokumentációt, diagnosztikát, célpont-állításokat, szerkesztői viselkedést, kódgenerálást, biztonsági vezérlőket, támogatási beszélgetéseket és egy módot arra, hogy a vevőnek pontosan megmondják, mi változott, amikor egy eredmény megváltozik.
Ez nem teszi kevésbé technikainak a munkát. A technikai munkát kötelezőbbé teszi. A Kera jelenleg kereskedelmi Dweve termék, nem nyílt forráskódú kiadás: minden jog fenntartva, kereskedelmi licenc alatt érhető el, Hollandiában készült, és olyan szervezeteknek szánják, amelyeknek a gráfút támogatására van szükségük, nem csupán közzétételére. Ha az oldal Rust 2021-et, gráf IR-t, egyedi JIT-et, LLVM nélkül, CPU/GPU/FPGA/WASM-ot, effektuskövetést, tulajdonlást memóriatereken át, képesség-alapú biztonságot, elosztott végrehajtást, C és Python beágyazást, CLI-munkafolyamatokat, szerkesztői támogatást és LSP-eszközöket említ, ezek nem dekoratív belső részletek. Ezek kötelezettségek, amelyeknek ki kell állniuk a valós munkaterhelések értékelését.
A képességlista óvatos ezzel kapcsolatban. Tervezési célokat ír le, és azt mondja, hogy ellenőrizze a saját munkaterhelése alapján. Ez a visszafogottság fontos. Sokkal egészségesebb, mint azt állítani, hogy minden benchmark-szám átvihető. A rendszernek módot kell adnia a csapatoknak a mérésre, vizsgálatra és összehasonlításra a saját környezetükben, nem pedig egy univerzális sebességtörténet elfogadására kérni őket.
Valakinek birtokolnia kell ezt az utat, mert minden célpont megpróbálja kevésbé univerzálissá tenni a forrást. A Kera az a hely, ahol ezek a célpont-különbségek explicit fordítói munkává válnak, nem pedig a hibajelentés után terjedő folklórrá.
Az a nap, amikor a gráf szerződéssé válik
Képzelje el újra az eredeti hibajelentést, de a Kera már a munkafolyamatban van. Egy pénzügyi csapat jóváhagy egy kockázatszámítást. A gráf ujjlenyomata rögzítésre kerül. Az első telepítés CPU-n fut. Később egy GPU-utat vezetnek be a portfólióelemzéshez. Még később egy FPGA-utat használnak az alacsonyabb késleltetésű árazáshoz. A kérdés minden lépésnél nem az, hogy az új hardver lenyűgözően hangzik-e. A kérdés az, hogy ugyanazt a gráfot lowerelik-e, és hogy a célpont szemantikája azonos eredményt tart-e fenn.
A beszélgetés megváltozik. A platformcsapat beszélhet az ütemezésről és a költségekről. A fordítócsapat beszélhet a backendekről. A megfelelőségi csapat beszélhet az ujjlenyomatról. Az üzleti tulajdonos megkérdezheti, hogy a hardverváltás operatív döntés-e vagy újraírás. A termék egyetlen objektumot ad mindannyiuknak, amelyre mutathatnak.
Ez a tartalom-címzett IR csendes értéke. A platformok közötti végrehajtást meggyőző magyarázatok sorozatából feljegyzéssé alakítja. A gráfot elismervénnyé teszi. Lehetővé teszi, hogy ugyanaz a .keg minden háttérrendszert ellásson. A szervezetnek olyan alapvonalat ad, amely a számításhoz tartozik, nem pedig egyetlen géphez.
Egyetlen fordítóprogram sem mentesítheti a mérnöki ítélőképesség szükségességétől. A csapatoknak továbbra is gondosan kell kiválasztaniuk a célokat, őszintén tesztelniük a munkaterheléseket, megérteniük a célkorlátokat, és el kell dönteniük, mely területek igényelnek bitenkénti azonosságot. De a Kera képes ezeket a döntéseket egyértelművé tenni. Megakadályozhatja, hogy egy teljesítmény-migráció véletlenül szemantikai migrációvá váljon.
A leszállítás tanulsága
A Kera azért fontos, mert a nehéz rész nem az, hogy legyen egy okos leszállítási ötlet. A nehéz rész az, hogy ezt az ötletet végigvigyük mindazokon az unalmas helyeken, ahol a mérnöki munka vagy megbízhatóvá válik, vagy folklórrá: diagnosztika, zöld fák, típushashek, kölcsönzés-ellenőrzés, fixpontos optimalizálás, invariáns-ellenőrzés, .keg szerializáció, háttérrendszer-kibocsátás, biztonsági házirend, naplófájlok, szerkesztőtámogatás és cél-specifikus végrehajtás.
A leszállítás azért munka, mert minden cél megpróbálja kevésbé univerzálissá tenni a forrást. A determinisztikus fordítóprogram-mérnöki munka az a fegyelem, amely megtagadja, hogy ez csendben megtörténjen. A CPU vektorokat akar. A GPU kerneleket akar. Az FPGA ciklusokat akar. A WASM korlátokat akar. A szervezet egyetlen választ akar. A Kera feladata, hogy megőrizze a számítás jelentését, miközben minden cél azt teszi, amihez jól ért.
Ez egy mérnöki forma, nem pedig papír-absztrakció. Van vevője, meghibásodási módja, fájlformátuma, fordítóprogram-útja és működési következményei. Az ígéret nem az, hogy a hardver egyszerűvé válik. Az ígéret az, hogy a komplexitás reprezentálva, leszállítva, ellenőrizve és birtokolva van.
Amikor megérkezik a következő majdnem helyes szám, a csapatnak nem szabad folklórral kezdenie arról, hogy melyik gép mit futtatott. A gráffal kell kezdenie. Egyezett az ujjlenyomat? Melyik háttérrendszer bocsátotta ki a kódot? Mely képességek voltak engedélyezve? Mely cél-szemantika érvényesült? Melyik összeállítás lett tárolva? Ezek termék-kérdések. A Kera azért létezik, mert ezek egyben fordítóprogram-kérdések is.