MemPalace nousi 0:sta 23 000 GitHub-tahteen 72 tunnissa argumentoimalla etta tekoalyn muistin ei pitaisi koskaan heittaa mitaan pois. Silti se ei pysty vastaanottamaan yhtakaan kokouslitterointia. Suurin organisatorisen tiedon lahde ei ole edes mukana keskustelussa.

MemPalacen ydinargumentti mahtuu yhteen lauseeseen, ja README ilmaisee sen lahes manifestina: tekoalyn muistijarjestelmien pitaisi tallentaa kaikki sanasanaisesti eika koskaan antaa LLM:n paattaa mika on sailyttamisen arvoista. README:n muotoilu kilpailusta on teravaaa: "Other memory systems try to fix this by letting AI decide what's worth remembering. It extracts 'user prefers Postgres' and throws away the conversation where you explained why." Tuo lause on syy miksi projekti levisi viraalisti 72 tunnissa. Se on myos lause joka tekee kokouslitteroinnin aukosta niin silmiinpistaavan. Jarjestelma jonka koko olemassaolon oikeutus on olla koskaan heittamatta kontekstia pois ei tarjoa mitaan polkua vastaanottaa suurinta organisatorisen kontekstin lahdetta joka useimmilla tiimeilla on.

Tama artikkeli kartoittaa tuon aukon rehellisesti -- mita MemPalace tekee oikein, mita se ei kasittele ja miltaa kokousnatiivi versio samasta ideasta pitaisi nayttaa.

23 000 tahtea 72 tunnissa

Konteksti ensin, lyhyesti, koska nopeus merkitsee. MemPalace julkaistiin 6. huhtikuuta 2026. 24 tunnin sisalla se oli ylittanyt 5 000 GitHub-tahtea. 8. huhtikuuta se oli noin 23 000 tahdessa ja 3 000 forkissa, 159 PR:aa jo jatettyina. Kanssaluojat ovat nayttelija Milla Jovovich (kylla, se sama) ja insinoori Ben Sigman, ja julkaisua kantoi twiitti jolla oli yli 1,5 miljoonaa nayttokertaa.

Julkaisua ajaneet benchmark-vaitteet -- "first perfect score on LongMemEval, beating every product in the space" -- osoittautuivat monimutkaisemmiksi kuin twiitti antoi ymmartaa, ja yhteisooe purki ne reaaliajassa. Katasoimme kiistan yksityiskohdat rehellisesti tekoalyn muistiviikko -lapikayntissa, emmeka aio kayda niita lapi uudelleen taassa. Lyhyt versio: paaluvut vertaavat hakurecallia kilpailijoiden end-to-end QA-tarkkuuteen, mika ei ole vertailukelpoinen, ja "100 % LongMemEvalissa" -ajo sisalsi patcheja jotka kirjoitettiin juuri epaonnistuneita kysymyksia varten. Se on todellista ja tietamisen arvoista.

Mutta markkinoinnin alla olevat arkkitehtuuri-ideat ovat myos todellisia, ja siita tassa artikkelissa on oikeasti kyse. 19 luku-kirjoitus-MCP-tyokalua. Paikallinen SQLite-tietograafi. Siivet-huoneet-kaytavat-laatikot-spatiaalinen metafora. Nelikerroksinen latausjarjestelma joka kaynnistaa agentin noin 170 tokenilla matalimmalla tasolla. Vaatimus sailyttaa alkuperaiset sanasanaiset tiedostot "laatikoissa" joita ei koskaan tiivisteta pois. Nama ovat todellisia insinoorivalintoja joilla on todellisia seurauksia. Riisu julkaisuhype pois ja taalla on kontribuutio joka on ottamisen arvoinen vakavasti.

Otetaan se siis vakavasti, siina ainoassa suunnassa joka merkitsee eniten kokoustyokalujen rakentajille: mita tapahtuu kun MemPalace kohdistetaan kokoukseen?

Mita MemPalace todella hyvaksyy syotteena

Keskustelunlouhija on tiedostossa mempalace/normalize.py. Viisi formaattia on tuettu, ja lista on tarkka:

Claude Code JSONL
Claude.ai JSON
ChatGPT conversations.json
Slack-tyotilan viennit
Yleiset tekstitiedostot

Louhintatilat ovat yhta spesifisia. --mode convos jassentaa chattimuotoisia vaihtoja vuorottelulla. --mode projects kay lapi koodikantoja noin 20 tiedostopaatten yli. --extract general ajaa regex-pohjaisen lapikaynti pelkan tekstin yli etsien pintakuvioita: paatoksia, preferensseja, virstanpylvaita, ongelmia, emotionaalisia hetkia. Se on koko pinta-ala.

Kaikilla viidella syotteella on yhteinen ominaisuus joka on mainitsemisen arvoinen: ne ovat kirjoitettuja keskusteluja yhden ihmiskayttajan ja yhden tekoalyn valilla, tai asynkronisia tekstikanavia joissa on yksi kirjoittaja per viesti. Louhija odottaa tuota muotoa. >-kayttajamerkki, oletus lyhyista vuorottelevista vuoroista, kaiken puhuja-identiteetin seurannan puute -- jokainen suunnitteluvalinta normalisoijassa heijastaa syotemaailmaa joka nayttaa chatilta.

Mita MemPalace ei hyvaksy

Lista asioista joita keskustelunlouhija ei kasittele on kontekstissaan kokousmaailman koko muoto:

Ei VTT-formaattia. WebVTT on vakiotekstitys- ja litterointiformaatti jota Zoom ja pitka lista videotyokaluja kayttaa. Sita ei ole normalisoijassa.
Ei SRT-formaattia. Toinen hallitseva tekstitysformaatti jota litterointipipelinet kayttavat. Myos puuttuu.
Ei nativia Zoom-litteroinnin vientia. Ei rakenteisen kentan kautta eika tiedostontunnistuksella.
Ei Microsoft Teams -litteroinnin vientia. Sama.
Ei Google Meet -litteroinnin vientia. Sama.
Ei tietoisuutta puhujan diarisaatiosta. Chattivientiissa on yksi puhuja per viesti maaritelmallisesti. Kokouslitteroinnissa on useita puhujia per sessio, paallekkaisella kontekstilla, keskeytyksilla ja identiteetilla joka pitaa ratkaista tiedostojen yli.
Ei aikaleiman sailyttamista. Kokouslitteroinnit ovat ankkuroituja sekuntiin. Tuo ankkurointi mahdollistaa paatoksen jaljittamisen takaisin hetkeen jolloin se tehtiin. Mikaan louhijassa ei sailyta sita.
Ei asialisttietoisuutta. Kokoukset on jasrjestetty aiheiden ymparille. Chatit ovat reaktiivisia. Louhijalla ei ole kasitetta aiherajoista session sisalla.
Ei monologitukea. Pitka yhtajaksoinen osuus yhdelta puhujalta -- yleista aanimuistioissa, luennoilla ja monissa todellisissa kokouksissa -- ei nayta chattivaihdolta eika mene puhtaasti louhijan lapi.

Kaksi lisafaktaa tekevat aukosta mahdotonta tulkita tahattomaksi. Sana "meeting" esiintyy nolla kertaa MemPalacen dokumentaatiossa ja koodikannassa. Sana "transcript" esiintyy nolla kertaa. Tama ei ole huolimattomuus paikattavaksi 1.0.1-julkaisussa. Se on suunnittelualue johon projekti ei koskaan astunut.

Se on muuten ihan ok. Projekteilla on lupa rajata itsensa. Pointti ei ole etta MemPalace on vaarassa keskittyessaan chattiartefakteihin. Pointti on etta sanasanainen-ensin-filosofia on tarkalleen se filosofia jota kokoukset tarvitsevat, ja projekti joka artikuloi sen kovimmalla aanella ei ole viela lahellaakaan syotteita joissa silla olisi eniten merkitysta.

Miksi kokoukset ovat rakenteellisesti erilaisia kuin chatit

On tarkkuuden arvoista miksi chattimuotoinen muistijarjestelma ei voi yksinkertaisesti absorboida kokousta kasittelemalla sita yhena teksttiedostona lisaa. Rakenteelliset erot eivat ole kosmeettisia.

Monen puhujan keskustelut yhden session sisalla. Chattivienti on sekvenssi yhden kirjoittajan viesteja. Kokouslitterointi on yksi sessio jossa on useita puhujia joiden vuorot menevat paallekkain, joiden konteksti riippuu toisistaan ja joiden identiteetit pitaa seurata koko tiedoston lapi eika viestikohtaisesti.

Pitkat monologit joita seuraa reaktiivinen keskustelu. Todelliset kokoukset vuorottelevat jonkun puhuessa kymmenen minuuttia ja kaksiriivisten vastausten purskeen valilla. Chattilouhijat olettavat lyhyttya vuorottelua. Molemmat muodot rikkovat oletuksen.

Asialistavetoinen kulku. Kokoukset on rakennettu aiheiden ymparille jotka ulottuvat useiden puhujien yli. Sama aihe voi kestaa viisitoista minuuttia, palata sitten lyhyesti kolmekymmenntaa minuuttia myohemmin. Merkitysyksikko taassa ei ole "vuoro" -- se on "keskustelu X:sta useiden vuorojen yli useiden ihmisten toimesta." Chattilouhijoilla ei ole kasitetta tasta.

Kokousten valinen jatkuvuus. Sarah asiakastiimista taman viikon puhelussa on sama Sarah ensi viikolla, vaikka han ilmestyisi kokoukseen jonka MemPalace arkistoisi eri huoneeseen. Puhujan identiteetti pitaa ratkaista tiedostojen yli, ei niiden sisalla. Chattivientiissa ei ole tata ongelmaa koska kayttaja on aina yksi henkilo.

Paatoshetket ankkuroituna aikaleimoihin. Kun kokous paattaa jotain, paatos on olemassa tiettyssa kohdassa tallennetta. Tuo aikaleima on tapa jolla paatoeksen voi auditoida myohemmin. Muistijarjestelma joka tiputtaa aikaleimat vastaanotossa ei pysty vastaamaan "milloin tarkalleen tama paatettiin," mika on kysymys jolla on eniten merkitysta kun paatokset menevat pieleen.

Toimenpidepisteet jotka ulottuvat kokousten yli. Asia joka annetaan kokouksessa A ja ratkaistaan kokouksessa B ei ole kaksi erillistaa faktaa. Se on saie. Chattimuotoinen poimija naakee ne toisistaan riippumattomina havaintoina. Kokousmuotoisen poimijan pitaa mallintaa itse saie.

Chatille suunniteltu muistijarjestelma kasittelee jokaista vuoroa itsenaisena yksikkona ja antaa korpuksen muotoutua alhaalta ylos. Kokouksille tarkoitetun muistijarjestelman pitaa kasitella koko keskustelua yksikkona, ja silti poimia rakenteisia signaaleja -- paatoksia, sitoumuksia, entiteettimainintoja -- joita seurataan sessioiden yli. Se ei ole sama tyo.

Mita MemPalace tekee oikein

Tama on artikkelin kohta jossa olisi halpaa olla vihaaja. Rehellinen luenta on paastastainen: useimmat MemPalacen kantavista arkkitehtuurivalinnoista ovat tarkalleen mita kokousnatiivi muistijarjestelma myos tarvitsisi. Projekti on lahempana "oikea kaava, vaarat syotteet" kuin "vaara kaava."

Sanasanainen tallennus primitiivina. "Laatikko"-kaava -- alkuperaistiedostot sailytettyina tarkalleen, ei koskaan tiivistettyina yli -- on oikea pohjakerros kokouslitteroinnille. Kokoukset ovat tarkalleen se lahdetyyppi jossa poiminta menettaa kriittista kontekstia. Muotoilu merkitsee. Epavarmuus merkitsee. Jatkokysymys johon kukaan ei vastannut merkitsee. Sanasanaisen litteroinnin tallentaminen ja jokaisen kootun artefaktin kasittely johdettuna nakymana sen paalla on arkkitehtuuri jota kokoustyokalujen pitaisi jo kayttaa ja enimmakseen eivat kayta. (Laajempi versio tasta argumentista, ks. kokouksesta-wikiin-aukko.)

Paikallinen-ensin oletuksena. Kokouslitteroinnit ovat organisaation herkimpien tietojen joukossa. Ne sisaltavat asiakaskeskusteluja, sisaisia erimielisyyksia, nimettyyja henkiloita jotka keskustelevat asioista joita he eivat kirjoittaisi muistiin. Pohjoismaiset datasuvereniteettihhuolet ovat todellisia eivatka ne ole katoamassa. MemPalacen oletus ajaa paikallisella SQLitella ja ChromaDB:lla, ilman mitaan pilvikaannoosta, on oikea lahtoasema. Useimmat kokoustyokalut oletusarvoisesti toimivat toisin pain.

Luku-kirjoitus-MCP-tyokalut. Tama on lapiamurto jota kukaan ei nimeaa tarpeeksi selkeasti. Lahes jokainen tahan mennessa toimitettu kokous-MCP-palvelin on vain-luku-tilassa -- agentit voivat etsia litterointeja ja hakea yhteenvetoja, mutta mikaan ei kirjoita takaisin. MemPalace toimittaa 19 tyokalua ja lista sisaltaa nimenomaisesti add_drawer, kg_add, kg_invalidate ja diary_write. Kirjoitusoperaatiot ovat ensiluokkaisia. Se on arkkitehtuurinen muoto jota kohti kokoustyokalujen pitaa kehittya, ja MemPalace on tallaa hetkella selkein esimerkki siita avoimen lahdekoodin muistialueella.

Nelikerroksinen latausjarjestelma. Jako L0 identiteetti, L1 kriittiset faktat, L2 huoneen palautus, L3 syvaahaku on todellinen insinoorivalinta mitattavalla kustannuksella. Riippumaton reproduktio sijoittaa todellisen L0+L1:n lahemmaksi 600--900 tokenia kuin README:n 170, mutta periaate pitaa: agentti joka tarvitsee kontekstia joka kaynnistyksella hyotyy valtavasti porrastetusta latausmallista jossa suurin osa tiedosta haetaan vasta pyydetayessa. Kokousagentit joiden pitaa briefata itsensa henkilosta tai projektista ennen vastaamista tarvitsevat tarkalleen taman muodon.

Skeema-tiedostona-kaava. MemPalacen rakenne maaritellaan tavallisissa tiedostoissa jotka LLM lukee kaynnistyksessa. Se on sama kaava jonka Karpathy kuvaili LLM:n yllapitamalle wikille -- CLAUDE.md tai AGENTS.md joka kertoo mallille miten sisaltoa pitaa koota tietokantaan. Se on siirrettavissa, versionhallittavissa ja pakottaa ihmisen ajattelemaan selkeasti mita tietopohja todella on. Kokoustyokalut eivat ole adoptoineet tata kaavaa lainkaan. Niiden pitaisi.

Mita MemPalace tekee varin (tai ei lainkaan) kokouksille

Nyt toinen puoli. Ota yllapolevat ideat annettuina, ja aukot kokouskaseen teroistyavat nopeasti.

Siivet-huoneet-kaytavat-metafora ei kartoitu luonnollisesti kokouksiin. Kokoukset ovat episodisia, eivat temaattisia. Yksi tunnin kokous koskettaa viiden "huoneen" verran aiheita. Sen pakottaminen yhteen huoneeseen menettaa aiheiden valisen kontekstin. Sen jakaminen huoneiden yli menettaa session yhtenaisyyden. Kumpikaan ei ole oikein. Chattimuisti on luonnostaan huonemuotoista koska jokainen keskustelu kasittelee enimmakseen yhtaa asiaa. Kokoukset eivat ole.

Keskustelunlouhija odottaa chattikuvioita, ei kokousrakennetta. Dokumentoitu edella. >-kayttajamerkki, oletettu vuorotteluvauhti, kaiken puhujan jatkuvuusseurannan puute -- mikaan siita ei selvia kohtaamisesta todellisen litterointitiedoston kanssa.

Tietograafi on todellinen mutta rajallinen, eika ristiriitojen havaitsemista todellisuudessa ole. Tama on tarkea ja yllattava. README esittelee toistuvasti ristiriitojen havaitsemista ("AUTH-MIGRATION: attribution conflict -- Maya was assigned, not Soren"). Leonard Linin riippumaton koodikatselmus loysi nolla esiintymaa sanasta "contradict" tiedostossa knowledge_graph.py. Erillinen fact_checker.py on olemassa mutta ei ole kytkettyna KG-operaatioihin. Projekti on myontanyt taman. Kokouksille ristiriitojen havaitseminen on yksi arvokkaimmista mahdollisista ominaisuuksista -- oliko taman viikon paatos ristiriidassa viime kuukauden kanssa? -- ja juuri nyt MemPalace ei toteuta sita edes tukemilleen syotteille.

Ei puhujan identiteetin ratkaisua kokousten yli. "Sarah" kokouksessa yksi ja "Sarah Chen" kokouksessa viisi ovat eri entiteetteja MemPalacelle. Ei aanisormenjalkeaa, ei nimen yhdistamislaapikayntia, ei entiteetin ratkaisukerrosta joka on suunniteltu keskusteluaanelle. Jotta kokoustieto keraantyisi -- koko syy miksi taman rakentaisi ylipaaataan -- puhujan identiteetti pitaa ratkaista lahteessa, ei jalkeen paain kyselyhetkella.

Ei paatoksen poimintaa. --extract general -tila ajaa regexa tekstia vasten etsien paatoksia ja preferensseja. Se nappaa pintakuvioita. Se ei ymmaarraa kokousrakennetta, jossa useimmat paatokset todella asuvat ("ok, eli mennaan silla toisella vaihtoehdolla" on rakenteellisesti paatos juuri sitaa edeltaneen keskustelun takia). Kokouslitteroinnit tarvitsevat poimintaa joka on tietoinen keskustelukontekstista, ei kuvionvastaavuutta avainsanoihin.

Sanasanainen-vastaan-poiminta-keskustelu sovellettuna kokouksiin

Astu askel taaksepain. MemPalacen "tallenna kaikki sanasanaisesti" -kanta on yksi napa vanhassa keskustelussa. Toinen napa on kokoustyokalut kuten Granola, jotka tallentavat parannettuja muistiinpanoja loistavasti ja suurelta osin heittavat raaan litteroinnin pois. Molemmilla navoilla on todellinen argumentti takanaan. Sanasanaiset puolustajat ovat oikeassa etta poiminta menettaa kontekstia. Poimintapuolustajat ovat oikeassa etta kukaan ei lue uudelleen neljan tunnin litterointia.

Rehellinen vastaus on etta tama on valebinaari. Oikea arkkitehtuuri tallentaa molemmat:

Sanasanaisen litteroinnin, muuttumattomana, jotta mika tahansa hetki voidaan toistaa ja mika tahansa poiminta voidaan johtaa uudelleen.
Rakenteisia signaaleja -- paatoksia, entiteetteja, toimenpidepisteitaa, puhujaidentiteetteja -- poimittuna vastaanotossa ja seurattuna sessioiden yli ensiluokkaisina objekteina.
Yhden kyselyrajapinnan joka antaa ulottua kumpaan tahansa kerrokseen riippuen siita mita tarvitsee.

Tama on myos arkkitehtuuri jonka Karpathy kuvaili LLM:n yllapitamalle wikille, raakadata yhdessa kansiossa ja koottu, uudelleengeneroitava wiki sen paalla. Jos et ole lukenut tyonkulkuopasta tai kokoustietomuotoilua, ne tekevat saman pointin taydessa pituudessaan. Skeptinen versio samasta keskustelusta, mukaan lukien tokenkustannus- ja kontaminaatiohuolet, on LLM-wiki-skeptikon oppaassa.

MemPalace on ottanut sanasanaisen puoliskon vakavasti ja poimintapuoliskon kevyesti. Useimmat kokoustyokalut ovat tehneet paasnvastoin. Kumpikaan ei ole valmis.

Miltaa kokousnatiivi MemPalace nayttaisi

Jos ottaisi MemPalacen arkkitehtuurisen filosofian ja rakentaisi sen uudelleen kokouksille alusta alkaen, komponentit eivat ole mysteereita. Lista lukeutuu kuin tuotespesifikaatio.

Natiivi kokousformaattien vastaanotto. VTT, SRT, Zoom, Teams, Google Meet, Otter-viennit, raaka audio transkription kautta. Mika tahansa joka tuottaa ihmisten huoneessa sanomia sanoja.
Puhujan ratkaisu ensiluokkaisena operaationa. Aanisormenjaljet, nimen poiminta kontekstista, kokousten valinen identiteetin yhdistaminen. "Sarah Chen" viikolla viisi yhdistyy "Sarahn" kanssa viikolla yksi ilman etta kayttajan tarvitsee pyytaa.
Paatos- ja toimenpidepoiminta vastaanottopipelinessa. Ei alavirtaan chattiominaisuutena. Osana sita miten kokouksesta tulee muisti. Poimitut kohteet elaavat ensiluokkaisina entiteetteina graafissa, merkittyina lahdekokouksella ja aikaleimalla sen sisalla.
Kokousten valinen synteesi pysyvana artefaktina. "Kaikki mihin Sarah sitoutui viimeisen kuuden kokouksen aikana" ei pitaisi olla chattvastaus joka katoaa kun valilehden sulkee. Sen pitaisi olla markdown-tiedosto joka on olemassa huomenna ja paivittaa itsensa inkrementaalisesti seitsemmannen kokouksen jalkeen.
MCP-tyokalupinta seka lukemiselle etta kirjoittamiselle. Lukutyokalut litterointien etsimiseen ja entiteettien hakemiseen. Kirjoitustyokalut uusien kokousten vastaanottamiseen, paatoslokien paivittamiseen, puhujaidentiteettien yhdistamiseen, ristiriitojen liputukseen. Kirjoituspuoli on se osa joka useimmilta kokoustyokaluilta puuttuu tanaan.
Paikallinen-ensin-arkkitehtuuri EU-dataresidensilla oletuksena. Ei yritylisinaaa. Lahtopositiona. Tama on perusvaatimus eurooppalaisille asiakkaille ja yha enemman kaikille muille.

Tama ei ole hypoteettinen tuote. Olemme rakentaneet sita Proudfrogilla kuukausien ajan -- Proudfrogin MCP-palvelin, talla hetkella betassa viidella vain-luku-tyokalulla ja kirjoitustyokalut tulossa, on silta jonka rakennamme kokouslitteroinnin ja Karpathy/MemPalace-muistikaavan valille. Se on ainoa lause tassa artikkelissa omasta tuotteestamme, ja se on taalla koska aukko jota tama artikkeli kuvaa on aukko jota kohti olemme rakentaneet.

Avoin kysymys

Kokousten sanasanaisen tallentamisen ongelma on nyt nakyvissa tavalla jolla se ei ollut kaksi viikkoa sitten. MemPalace laittoi toisen puolen vastauksesta poydalle, hyvin aanekkaaasti. Kokoustyokaluilla on suurin osa toisesta puoliskosta mutta ne eivat viela tajua tarvitsevansa MemPalacen puoliskoa. Kysymys seuraaville kahdelletoista kuukaudelle on kuka kuroo eron umpeen. Lisaaako MemPalace kokoustuen? Adoptoiko kokoustyokalu MemPalacen sanasanainen-ensin, kirjoita-takaisin, paikallinen-ensin-arkkitehtuurin? Saapuuko uusi tulija ja tekee molemmat kerralla?

Vastuksesta riippumatta aukko on nyt luettavissa, ja tuo nakyvyys on se osa joka puuttui. Voidaan vaidella siita kuka on parhaiten asemoitunut sulkemaan sen. Ei voida enaa vaittaa ettei sita ole.

Usein kysytyt kysymykset

Miksi MemPalace ei tue kokouslitterointeja?

Sita ei rakennettu niita varten. MemPalacen keskustelunlouhija on suunniteltu chattimuotoisille artefakteille -- Claude Code -lokeille, ChatGPT-viennille, Slackille -- joissa jokaisella viestilla on yksi kirjoittaja ja vuorotteluvauhti on nopea. Kokouslitteroinnit ovat rakenteeltaan fundamentaalisesti erilaisia: useita puhujia per sessio, pitkia monologeja, asialistaavetoista aihekulkua ja aikaleimoja jotka ankkuroivat paatoksia. Niiden tukeminen vaatisi natiivien jaasenninten lisaaamiseen VTT:lle, SRT:lle ja suurten kokousplatformien vientiformaateille, seka puhujan ratkaisukerroksen jota ei tallaa hetkella ole missaan koodikannassa. Se on eri suunnittelualue, ja sanat "meeting" ja "transcript" esiintyvat molemmat nolla kertaa projektin dokumentaatiossa. Se on selkein signaali etta tama oli tietoinen rajausvalinta eika huolimattomuus.

Voinko vain tallentaa kokouslitterointini tekstitiedostona ja syottaa sen MemPalacelle?

Voit, eika se kaadu. Yleinen tekstitila hyvaksyy sen, regex-pohjainen poimija vetaa pintakuvioita siita ja tulos laskeutuu laatikkoon. Mita menetat on kaikki mika tekee kokouslitteroinnista hyoodyllisen: puhujaidentiteetti, aikaleimat, asiallistarajat, erottelu monologin ja keskustelun valilla, ja kaikki kokousten valinen jatkuvuus mukana oleville henkiloille. Paaadyt sanasanaiseen blobiin joka on etsittavissa mutta ei rakenteinen. Se on parempi kuin ei mitaan, ja paljon huonompi kuin mita kokousmuotoinen pipeline antaisi.

Mika on ero MemPalacen sanasanaisen tallennuksen ja Otterin taydellisen litteroinnin valilla?

Otter tallentaa litteroinnin ja tarjoaa sen haun ja chatbotin kautta. MemPalace tallentaa raakadatan "laatikoissa" ja kasittelee niita muuttumattomana lahdemateriaalina josta kaikki muu johdetaan, eksplisiittisilla kirjoitustyokaluilla tietograafin paivittamiseen paalle. Filosofinen ero on mita kukin jarjestelma ajattelee tallennuksen olevan tarkoitettu. Otter kasittelee litterointia tuotteena. MemPalace kasittelee sanasanaista tiedostoa luotettavana lahdekerroksena koottun, kyselttavan graafin alla. Otter-lahestymistapa on yksinkertaisempi kayttaa tanaan; MemPalace-lahestymistapa on lahempana arkkitehtuuria jonka haluaa jos valittaa tiedosta joka keraantyy sessioiden yli.

Onko MemPalacen tietograafi tarpeeksi hyva kokouspaatoksille?

Nykyisessa muodossaan, ei. Graafi on todellinen -- SQLite-tuettu, subjekti-predikaatti-objekti-kolmikot temporaalisilla voimassaoloikkunoilla -- ja temporaalinen malli on aidosti hyoodyllinen. Mutta ristiriitojen havaitseminen, joka on yksi arvokkaimmista mahdollisista ominaisuuksista kokouspaatoslokille, ei ole toteutettu koodissa vaikka README antaa ymmartaa toisin. Leonard Linin riippumaton koodikatselmus vahvisti taman ja projekti myonsi sen. Paatoksten seuraamiseen kokousten yli -- "oliko taman viikon puhelu ristiriidassa viime kuukauden kanssa?" -- graafi on lahtopiste, ei valmis tyokalu.

Miten Proudfrog eroaa kokousnatiivista MemPalace-versiosta?

Lyhyin tapa sanoa se: Proudfrog alkaa siita mihin MemPalace loppuu. Proudfrog kasittelee osat joita MemPalace ei kasittele -- tallennus, litterointi, puhujan diarisaatio, identiteetin ratkaisu kokousten yli, paatos- ja toimenpidepoiminta, ja tietokerros joka paivittaa itsensa uusien kokousten saapuessa -- ja on rakennettu paikallinen-ensin EU-dataresidensilla alusta alkaen. Proudfrogin MCP-palvelin (lukutyokalut tanaan, kirjoitustyokalut seuraavaksi) on tarkoitettu samaan rooliin kokouksille kuin MemPalacen MCP chateille. Emme ole ainoita jotka voisivat sulkea taman aukon, mutta olemme rakentaneet tarkalleen tata muotoa kohti kuukausien ajan, ja monet MemPalacen suunnitteluvalinnoista nayttavat tutuilta meille juuri siita syysta.

Pitaisiko minun odottaa etta MemPalace lisaa kokoustuen?

Jos tarvitset sita tanaan, ei. Projekti on kolme paivaa vanha kirjoitushetkella, kontribuoijat ovat responsiivisia mutta tiekartta on kiireinen paljon valittomammilla asioilla (benchmark-metodologia, AAAK-kompressiovaitteet, ristiriitojen havaitsemisaukko), ja kokousten vastaanotto vaatisi merkittavan uuden osajarjestelman pienen paikkauksen sijaan. Jos olet kehittaja joka haluaa kokeilla ideoita, forkkaa se ja yrita kirjoittaa VTT-normalisoija -- se on tarkalleen sellainen kontribuutio jonka projekti todennakoisesti toivottaisi tervetulleeksi. Jos tarvitset toimivan pipelinen tiimisi kokouksille nyt, katso tyokaluja jotka rakennettiin kokouksia varten alusta alkaen ja jotka ottavat sanasanaisen ja kootun arkkitehtuurin vakavasti. Tietotyolaaisten kayttotapaus ja ominaisuussivu ovat lahimmat kuvaukset siita miten ajattelemme asiasta.

MemPalace tallentaa kaiken. Kokouksesi eivat tallenna mitaan. Tassa on aukko.