Idealuonnos: tässä ehdotetaan avointa kuvausformaattia, ei valmista standardia tai testattua palvelua.
”Sivuilta vähän lyhyemmäksi, päältä jätetään enemmän.” Pyyntö on tuttu, mutta siitä jää paljon tulkittavaa. Kuinka paljon on vähän? Mistä lyhyen ja pitkän alueen raja alkaa? Mitä tehdään pyörteen kohdalla?
Valokuva auttaisi edelleen. Reseptin tehtävä olisi täydentää sitä: kertoa pituudet, alueiden väliset siirtymät, leikkaustavat ja ne kohdat, joissa juuri tämän asiakkaan hiukset vaativat huomiota. Kuva onnistuneesta lopputuloksesta ja ohje sen tekemiseen kuuluisivat samaan pakettiin.
Ajatus ei ole korvata ammattitaitoa millimetriluvuilla. Resepti olisi yhteinen muisti asiakkaalle ja parturille. Siihen voisi kirjata myös epäonnistumiset: tästä ei enää ohenneta, tähän jätetään ensi kerralla enemmän pituutta.
Alkuun riittäisivät pään kuvat edestä, sivuilta, takaa ja ylhäältä sekä muutama selkeä merkintä. Päälaen tavoitepituus voisi olla esimerkiksi 55 millimetriä ja sivujen 6 millimetriä. Pyörteen kohdalle merkittäisiin, että hiusta jätetään pidemmäksi ja kasvusuunta säilytetään.
Nämä olisivat yhden kuvitteellisen leikkauksen ohjeita, eivät yleispätevä suositus. Tarkoitus olisi kuvata tietylle ihmiselle toimiva ratkaisu. Samalla pitäisi sopia, mitä merkinnät tarkoittavat: esimerkiksi tavoitepituus leikkauksen jälkeen ja leikkaamiseen käytetty koneen tallakoko eivät saisi sekoittua toisiinsa.
Käynnin jälkeen parturi ja asiakas voisivat päivittää reseptin. Seuraavan version muutos olisi vaikka: päältä kahdeksan millimetriä pidempi, häivytys hieman alemmas, oikean etusivun ohennus pois. ”Sama kuin viimeksi” saisi tarkistettavan sisällön.
Ratkaisun ydin olisi avoin tiedostomuoto. Asiakas saisi reseptinsä talteen ja voisi viedä sen toiseen palveluun tai näyttää paperilla. Parturin ei tarvitsisi lukea ohjelmakoodia: sovellus esittäisi tiedot ymmärrettävänä karttana ja tekstinä.
Pieni yhteinen perusta kuvaisi alueet, pituudet, siirtymät ja lisäohjeet. Tarkemmat järjestelmät voisivat lisätä pään kolmiulotteisen mallin, kasvusuunnat tai leikkaushistorian. Ohjelman pitäisi myös kertoa, jos se ei osaa näyttää jotakin olennaista lisätietoa, jotta puutteellinen ohje ei näyttäisi täydelliseltä.
Standardi ei siis määrittelisi jokaisen ihmisen päätä samanlaiseksi. Se antaisi yhteiset nimet alueille ja tavan kuvata niiden yksilölliset erot. Ammattilainen voisi edelleen soveltaa ohjetta ja keskustella siitä, mikä on mahdollista.
Ensimmäinen kokeilu voisi olla muutaman parturin ja asiakkaan yhteinen paperi- tai tiedostopohja. Tärkein kysymys olisi, pystyykö toinen parturi hyödyntämään ohjetta ilman pitkää lisäselvitystä. Vasta tämän jälkeen olisi järkevää kasvattaa teknistä tarkkuutta.
Myöhemmin sama formaatti voisi toimia myös robottileikkaamisen lähtötietona. Ihmiselle tarkoitettu resepti ei kuitenkaan sellaisenaan olisi turvallinen koneohjaus: laite tarvitsisi oman tulkintansa, mittauksensa ja turvarajansa. Yhteinen kuvaus voisi yhdistää järjestelmiä, vaikka niiden toteutukset eroaisivat.
Reseptin perusmuodon ja sitä lukevan esimerkkiohjelman voisi julkaista avoimesti. Sen ympärille voisi silti rakentaa maksullisen editorin, parturiliikkeen asiakasjärjestelmän tai palvelun, joka muuntaa eri järjestelmien merkintöjä yhteiseen muotoon. Asiakas ei ostaisi lupaa omaan leikkaukseensa, vaan ammattilainen maksaisi työtä helpottavista välineistä.
Näin kokeilun ei tarvitsisi alkaa koko alan yhteisestä päätöksestä. Yksi liike voisi tehdä reseptejä, joita asiakkaat voivat näyttää muualla. Yhteinen formaatti auttaisi enemmän sitä mukaa, kun muutkin osaavat lukea ja päivittää sitä. Sen hyödyllisyys pitäisi kuitenkin ansaita käytössä: jos reseptin täyttäminen vie enemmän aikaa kuin uuden asiakkaan haastatteleminen, avoimuus ei yksin tee siitä houkuttelevaa.
Henkilökohtainen leikkausresepti ei ole uusi ajatus. Esimerkiksi GRÜM-konsepti kuvaa mukana kulkevaa hiuspassia resepteineen, ja HairCut Historyn tuotesivu kuvaa aluekohtaisia mittoja ja jakamista toiselle parturille. Ensimmäinen on kehitteillä olevan konseptin esittely, jälkimmäinen tuotekuvaus; niiden toimivuutta ei tässä ole testattu.
Tämän tekstin lisä keskusteluun on erottaa resepti yksittäisestä sovelluksesta: voisiko leikkauksen kuvata avoimessa, yhteentoimivassa muodossa, jota eri palvelut ja myöhemmin laitteet voisivat lukea? Tarkistetuista lähteistä ei löytynyt kuvausta juuri tällaisesta yhteisestä standardista.
Myös ilman uutta standardia asiakaskortit, kuvat ja tekoälyllä jäsennetyt muistiinpanot voisivat helpottaa toistamista. Avoimen formaatin lisähyöty olisi tiedon säilyminen käyttökelpoisena palvelua, parturia ja mahdollisesti laitevalmistajaa vaihdettaessa.
Se voisi vähentää selittämistä ja epävarmuutta sekä tehdä uuden parturin kokeilemisesta helpompaa. Samalla koulut ja ohjelmistojen tekijät voisivat rakentaa saman perustan päälle erilaisia työkaluja. Ensimmäinen onnistumisen mittari olisi kuitenkin arkinen: ymmärsikö uusi parturi reseptin ja auttoiko se tekemään sen leikkauksen, jota asiakas tarkoitti?
]]>Idealuonnos: ehdotettu sovittelumenettely ei ole testattu palvelu eikä lupaus riidan ratkeamisesta.
Tekoälytutkija Timo Honkela esitteli vuonna 2017 kirjassaan Rauhankone – tekoälytutkijan testamentti ajatuksen teknologiasta, joka auttaisi ihmisiä ymmärtämään toisiaan, käsittelemään tunteita ja rakentamaan oikeudenmukaisempaa yhteiskuntaa. Taustalla oli myös havainto siitä, että samoilla sanoilla voidaan tarkoittaa eri asioita (Helsingin yliopiston tutkimusportaali).
Tässä tarkasteltava idea rajautuu käytännön keskustelutilanteeseen: voisiko kone auttaa erottamaan tunteen, väitteen ja neuvottelutarpeen sekä tehdä ensimmäisestä myönnytyksestä helpomman? Se on yksi mahdollinen sovellus Honkelan avaaman laajan ajatussuunnan piirissä, ei väite saman vision keksimisestä uudelleen.
Avustaja toimisi kolmessa vaiheessa: tunteen käsittely, asian jäsentäminen ja sovittelu. Aluksi kumpikin saisi kuvata oman kokemuksensa yksityisesti. Kone auttaisi muuttamaan hyökkäävän viestin sellaiseksi, että sen takana oleva huoli tai tarve olisi mahdollista kuulla.
Kuvitteellisessa työtilanteessa ”sinä jätät aina kaiken minun hoidettavakseni” voisi tarkentua muotoon ”haluan sopia etukäteen, kuka vastaa keskeneräisistä tehtävistä”. Käyttäjän pitäisi itse hyväksyä tulkinta. Kone ei saisi vaihtaa hänen asiaansa helpommin sovittavaksi asiaksi vain saadakseen keskustelun näyttämään onnistuneelta.
Tavoite olisi säilyttää kokemus mutta vähentää tarpeetonta loukkaamista. Viesti voisi myös jäädä keskeneräiseksi. Pelkkä se, että toinen ei vielä halua keskustella, ei saisi muuttua koneen silmissä ongelmaksi, joka pitää väkisin ratkaista.
Seuraavaksi eroteltaisiin tapahtumia koskevat väitteet, niiden tulkinnat ja tulevaisuutta koskevat toiveet. Ovatko osapuolet eri mieltä siitä, mitä sovittiin, vai siitä, oliko sopimus reilu? Onko ongelma työn määrä, arvostuksen puute vai epäselvä vastuu?
Avustaja voisi nostaa esiin ristiriitoja ja kaksoisstandardeja kysymyksinä. Jos osapuolet vaativat itselleen vapautta mutta toiselle tarkkoja sääntöjä, tämä olisi hyvä tehdä näkyväksi. Koneen tehtävä olisi auttaa tarkistamaan perusteluja, ei julistaa toista tekopyhäksi tai päätellä hänen motiivejaan varmoiksi.
Myös yhteisymmärrys voisi olla rajallinen. Molemmat saattaisivat hyväksyä uuden työnjaon, vaikka menneisyydestä jäisi kaksi erilaista kokemusta. Palvelun ei tarvitsisi pakottaa niitä yhdeksi kertomukseksi.
Idean erityinen osa olisi myönnytysten yhteinen paljastus. Kumpikin valmistelisi avustajan kanssa viestin, jonka on valmis kertomaan toiselle. Avustaja näyttäisi täsmälleen, mikä teksti jaetaan. Viestejä ei paljastettaisi ennen kuin molemmat olisivat hyväksyneet omansa ja yhteisen paljastamisen.
Myönnytys voisi olla oman toiminnan tunnistaminen: ”Olisi ollut parempi ilmoittaa viivästyksestä aikaisemmin.” Se voisi myös olla tuleva teko: ”Voin ottaa tämän tehtävän, jos sovimme samalla vastuun seuraavasta vaiheesta.” Tarkoitus olisi pienentää ensimmäisen jouston kynnystä.
Samanaikaisuus ei tarkoittaisi yhtä suuria myönnytyksiä tai sitä, että molempien pitäisi tunnustaa sama määrä virheitä. Ihminen voisi myös perääntyä ennen paljastusta. Menettelyltä katoaisi tarkoitus, jos kone alkaisi kiristää molemmilta tasamäärää katumusta.
Avustaja voisi lisäksi etsiä ehdotuksia, joissa toinen joustaa itselleen vähemmän tärkeässä asiassa ja saa vastineeksi jotakin tärkeämpää. Kuvitteellisessa tiimissä yksi voisi arvostaa vapaata aikataulua ja toinen ennakoitavaa tiedonkulkua. Ratkaisu voisi olla joustava työskentely yhdistettynä sovittuun tilannepäivitykseen.
Luottamuksellisuus kuuluisi suunnittelun ytimeen: tavoitteena olisi, ettei yksityisistä keskusteluista muodostu pysyvää arkistoa eikä mitään jaeta ilman hyväksyntää. Tämä vaatisi toteutuksessa erikseen varmistettavan tietojen käsittelyn. Pelkkä käyttöliittymän lupaus ei osoittaisi sitä.
Ihmissovittelija voisi olla mukana. Avustajan pitäisi myös sallia keskeyttäminen ja avun hakeminen muualta. Tavoitteena ei olisi sovinto hinnalla millä hyvänsä, vaan ymmärrettävämpi ja vapaaehtoinen keskustelu. Empaattisen myönnytyksen tarkoitus olisi ilmaista ymmärrystä; palvelu ei voisi luvata käyttäjän sanoille yleistä oikeudellista suojaa.
Tekoälyn käyttö viestien selventämisessä on jo tutkimusaihe, esimerkiksi LLMediatorissa. Ashtin kehittäjäesittely kuvaa myös yksityistä valmistelua ennen yhteistä keskustelua, ja Smartsettle hyödyntää neuvotteluissa luottamuksellisia mieltymyksiä ja sokkotarjouksia. Näitä lähtökohtia ei siis voi pitää tämän tekstin uutuutena.
Tekstin oma lisä on rajattu menettely: kumpikin muotoilee myös tunnepitoisen myönnytyksen yksityisesti, hyväksyy täsmälleen jaettavan viestin ja antaa luvan sen paljastamiseen samanaikaisesti toisen viestin kanssa. Tarkistetuissa kuvauksissa ei tullut vastaan juuri tätä yhdistelmää.
Lähitulevaisuudessa tavallisetkin tekoälyavustajat voisivat auttaa muotoilemaan vaikean viestin. Tämän ehdotuksen lisä olisi osapuolten yhteinen menettely: yksityinen valmistelu, tarkasti hyväksytty jakaminen ja ensimmäisten myönnytysten samanaikaisuus.
Mahdollinen hyöty olisi keskustelu, joka muuten jäisi aloittamatta, tai yhteistyö, joka muuten katkeaisi. Arvoa pitäisi tutkia kysymällä, kokivatko molemmat tulleensa ymmärretyiksi, säilyikö heidän päätösvaltansa ja pitikö mahdollinen sopimus myöhemmin. Pelkkä sovintojen määrä voisi suosia liian helppoja tai painostettuja ratkaisuja. Näille vaikutuksille ei tässä anneta rahallista hintaa.
]]>Idealuonnos: alusta, reittejä ja kustannuksia ei ole suunniteltu tai testattu. Laskelma jäljempänä on kuvitteellinen vertailuesimerkki.
Ajatus lähtee palvelulupauksesta. Pienen vesioikotien ei olisi tarkoitus korvata siltaa, ympärivuotista yhteysalusta tai välttämätöntä kuljetusta, jonka pitää onnistua myös vaikeassa säässä. Rajattu palvelu voisi pysäyttää liikenteen ennakoivasti.
Tämä voisi antaa mahdollisuuden yksinkertaisempaan ja halvempaan toteutukseen. Säästö ei silti syntyisi pelkästään siitä, että alusta kutsutaan robotiksi. Tarvittaisiin myös toimivat laiturit, lataus, lastinkäsittely, kunnossapito ja tapa auttaa alusta häiriötilanteessa.
Ensimmäinen käyttö olisi tavarankuljetus. Ihmisten kuljettamista voisi selvittää erikseen myöhemmin. Tavarareitin onnistuminen ei sellaisenaan osoittaisi, että sama alus tai toimintamalli sopii matkustajille.
Aamulla alus voisi tuoda kauppatavaroita saaren noutolaituriin. Paluumatkalle voisi tulla kalastajan saalista tai pieniä lähetyksiä. Myöhemmin päivällä sama kapasiteetti voisi kuljettaa työvälineitä, varaosia tai viljelyn tarvikkeita.
Yhteinen käyttö olisi tärkeää, koska vain yhtä harvinaista tehtävää odottava alus voisi jäädä liian vähälle käytölle. Tilaukset pitäisi yhdistää niin, että kuljetuksesta tulee hyödyllinen ilman, että jokainen asiakas vaatii oman lähtönsä. Edullinen vesireitti ei auta, jos tavaran saaminen laiturille maksaa enemmän kuin koko maantiekierros.
Reittiverkoston perusta voisi olla yhteinen alusmalli ja samantapaiset laiturit, latauspisteet ja etävalvonta. Jokainen uusi reitti vaatisi silti paikallisen selvityksen. Lyhyt välimatka kartalla ei vielä kerro aallokosta, muusta liikenteestä tai lastaamisen järjestämisestä.
Autonominen tai etävalvottu alus tarvitsisi ennalta sovitun toimintatavan huononevaan säähän, yhteyskatkoon ja tekniseen vikaan. Milloin lähtö jätetään tekemättä, minne keskeytynyt alus siirtyy ja kuka käy tarvittaessa paikalla? Nämä olisivat palvelun perusasioita.
Käyttäjälle pitäisi kertoa selvästi, milloin reitti on käytössä ja mikä on varavaihtoehto. Jos tarkoitus on helpottaa arkea, epävarman kuljetuksen odottaminen ei saisi tuottaa uutta hankaluutta. Rajattu saatavuus voisi olla hyväksyttävä ominaisuus, kun se tunnetaan etukäteen.
Historiallinen edeltäjä löytyy yllättävän kaukaa. Nikola Tesla esitteli radio-ohjattavan veneensä New Yorkissa vuonna 1898 (Nikola Tesla -museo). Kyse oli veneestä, ei nykyisen kaltaisesta autonomisesta robottilossista.
Samansuuntaiset käyttötavat eivät edes jää pelkäksi arvailuksi: Teslan patentti US613809A mainitsee kirjeiden, pakettien, elintarvikkeiden ja muiden tavaroiden kuljettamisen sekä vaikeapääsyisten alueiden tavoittamisen. Hän siis ajatteli etäohjaukselle myös käytännöllisiä kuljetustehtäviä.
Miettikö Tesla samalla jotakin pienten vesioikoteiden verkoston kaltaista? Sitä nämä lähteet eivät kerro, mutta ajatuksella voi leikitellä. Ehkä nykypäivän kiinnostava mahdollisuus onkin tehdä vanhasta kuljetusvisiosta arkinen palvelu nykytekniikan avulla. Tämä rinnastus on spekulaatiota, ei väite Teslan suunnitelmista.
Autonomisia sähköaluksia ja niiden käyttöä tavarakuljetuksiin on jo tutkittu ja kokeiltu. Läheinen vastine on Japanin Smart Island -kokeilu, jossa yhdistettiin kauppatavaroiden ja matkustajien kuljetuksia sekä kokeiltiin etävalvontaa. Myös Roboat II -tutkimus tarkastelee autonomista alusta kaupunkien vesiväylille. Uudesta alusteknologiasta tai kokonaan uudesta kuljetusideasta ei siten ole kyse.
Tämä teksti tuo keskusteluun rajauksen: millaisia pieniä tavarareittejä voisi palvella yhteisellä kalustolla, jos palvelulta ei vaadittaisi ympärivuotisuutta tai toimintaa kaikissa oloissa? Lisä on käyttömallin ja sen kannattavuusehtojen jäsentäminen.
Vertailukohtana ei ole maailma, jossa kaikki kuljetukset tehdään nykyiseen tapaan ikuisesti. Sähköautot, toimitusten yhdistely ja nykyiset vesiliikenteen palvelut voivat jo vähentää kustannuksia. Robottilossin lisähyöty olisi vain se jäljelle jäävä kierto, jonka sen reitti todella poistaisi tämän päälle.
Oletetaan reitti, jolla palvelu toimisi 200 päivänä vuodessa ja korvaisi 20–50 erillistä maantieajoa päivässä. Oletetaan, että jokaisesta jäisi pois 20 kilometriä sen jälkeen, kun laiturille pääsemisen ja tavaran jatkokuljetuksen ajot on huomioitu. Nämä ovat laskelman skenaario-oletuksia, eivät tietoja tunnistetusta reitistä tai kysynnästä.
Tällöin vältetty ajo olisi 200 × 20–50 × 20 = 80 000–200 000 kilometriä vuodessa. Laskelma edellyttää aidosti poistuvia ajoja: jos ostokset olisi jo yhdistetty yhteen jakeluautoon, niitä ei saisi laskea erillisiksi automatkoiksi.
Vältettyjä kilometrejä ei voi muuttaa yleispäteväksi rahasäästöksi yhden maan korvaustasolla. Laskelman rahallinen vastine olisi paikallisesti vältettävä ajokustannus vähennettynä koko vesipalvelun vuosikustannuksella. Mukaan kuuluisivat aluksen ja laiturien pääomakulut, energia, valvonta, huollot, vakuutukset ja lastinkäsittely. Auton kiinteät kulut eivät välttämättä poistu ajokilometrien mukana.
Yksittäisestä reitistä ei tässä ole riittävää kustannusaineistoa, joten nettosäästölle tai takaisinmaksuajalle ei anneta lukua. Laskelmaa heiluttaa eniten se, kuinka monta erillistä kiertomatkaa oikeasti poistuisi. Myös käyttöpäivien määrä ja ihmistyön tarve voisivat muuttaa tuloksen kokonaan. Ensimmäinen selvitys kannattaisi tehdä yhdelle reitille laskemalla todelliset kuljetukset ja pyytämällä toteutuksesta kustannusarviot. Maailmanlaajuinen rahaluku olisi tässä vaiheessa näennäistarkka.
Säästön lisäksi vesioikotie voisi mahdollistaa jotakin, mitä ei nyt tehdä: pienen sadon toimittamisen ostajalle, työvälineen yhteiskäytön vastarannalla tai palvelun ulottamisen saareen. Nämä olisivat uusia mahdollisuuksia, joita ei pidä laskea toistamiseen säästyneinä automatkoina.
Vesi voisi näin muuttua arjessa esteestä yhteydeksi. Ratkaisevaa olisi löytää paikat, joissa lyhyt ylitys, riittävä käyttö ja hallittava palvelulupaus osuvat yhteen. Yhden aluksen ei tarvitsisi muuttaa koko liikennettä, jos se tekisi yhden tarpeellisen oikotien toimivaksi.
]]>Concept draft: the proposed mediation process is not a tested service or a promise that a dispute will be resolved.
In his 2017 book Rauhankone – tekoälytutkijan testamentti (Peace Machine: An AI Researcher’s Testament), AI researcher Timo Honkela outlined technology that would help people understand one another, handle emotions, and build a more just society. One underlying observation was that people can mean different things by the same words (University of Helsinki research portal).
The idea examined here addresses a practical conversation: could a machine help distinguish feelings, claims, and negotiation needs, and make the first concession easier? It is one possible application within the broad direction Honkela explored, not a claim to have reinvented his vision.
The assistant would work in three stages: handling emotions, structuring the issue, and mediation. Initially, each person could describe their experience privately. The machine would help turn an attacking message into something whose underlying concern or need could be heard.
In an imaginary workplace situation, “you always leave everything to me” might become “I want us to agree in advance who is responsible for unfinished tasks.” The user would have to approve the interpretation. The machine must not replace their issue with an easier one merely to make the conversation appear successful.
The aim would be to preserve the experience while reducing unnecessary hurt. A message could also remain unfinished. Someone not yet wanting to talk must not become a problem that the machine insists on solving.
Next, the process would distinguish claims about events, interpretations of them, and wishes for the future. Do the parties disagree about what was agreed, or about whether the agreement was fair? Is the problem workload, lack of appreciation, or unclear responsibility?
The assistant could raise inconsistencies and double standards as questions. If both parties demand freedom for themselves but strict rules for the other, that would be worth making visible. The machine would help examine reasoning, rather than declare someone a hypocrite or treat inferred motives as certain.
Agreement could also be limited. Both might accept a new division of work while retaining different experiences of the past. The service would not need to force those experiences into one narrative.
The distinctive element would be a joint reveal of concessions. Each person would prepare a message with the assistant that they were willing to share. The assistant would show exactly what text would be shared. Neither message would be revealed until both people had approved their own and the joint reveal.
A concession could acknowledge one’s actions: “It would have been better to tell you about the delay earlier.” It could also concern a future action: “I can take this task if we also agree who is responsible for the next stage.” The purpose would be to lower the barrier to making the first concession.
Simultaneity would not mean equal concessions or require both people to admit the same number of mistakes. A person could also withdraw before the reveal. The process would lose its purpose if the machine started extracting equal amounts of remorse from both sides.
The assistant could also seek proposals in which someone concedes on something less important to them in exchange for something more important. In an imaginary team, one person might value a flexible schedule while another wants predictable communication. Flexible working combined with an agreed progress update might provide a solution.
Confidentiality would be central to the design: the aim would be to avoid a permanent archive of private conversations and share nothing without approval. Implementation would require separately verified data handling. A promise in the interface would not establish this by itself.
A human mediator could participate. The assistant should also allow people to stop and seek help elsewhere. The goal would be an understandable, voluntary conversation, rather than agreement at any cost. An empathetic concession would be intended to express understanding; the service could not promise general legal protection for a user’s words.
Using AI to clarify messages is already a research topic, as illustrated by LLMediator. The Ashti developer presentation also describes private preparation before a joint conversation, while Smartsettle uses confidential preferences and blind bidding in negotiations. These starting points therefore cannot be treated as this article’s novelty.
The article adds a specific procedure: each person privately formulates a concession, including an emotional acknowledgment, approves the exact message to be shared, and authorizes its simultaneous reveal with the other person’s message. Precisely this combination did not appear in the descriptions checked.
In the near future, ordinary AI assistants could help formulate difficult messages. This proposal would add a shared process for the parties: private preparation, precisely approved sharing, and simultaneous first concessions.
The potential benefit would be a conversation that otherwise never starts, or cooperation that otherwise breaks down. Its value should be studied by asking whether both people felt understood, retained their decision-making power, and upheld any eventual agreement. Simply counting settlements could favor overly easy or pressured outcomes. These effects are not assigned a monetary price here.
]]>Concept draft: this proposes an open description format, not a completed standard or a tested service.
“A little shorter on the sides, leave more on top.” It is a familiar request, but much remains open to interpretation. How much is a little? Where does the transition from short to long begin? What happens around the cowlick?
A photograph would still help. The prescription would complement it by describing lengths, transitions between areas, cutting techniques, and the spots where this particular customer’s hair needs attention. A photograph of a successful result and instructions for achieving it would belong in the same package.
The idea is not to replace professional skill with millimetre measurements. The prescription would be a shared memory for the customer and barber. It could record failures too: no more thinning here; leave more length there next time.
Initially, front, side, back, and top views of the head and a few clear annotations would suffice. The target length on top might be 55 millimetres, for example, with 6 millimetres on the sides. The cowlick area would carry a note to leave more length and preserve the natural growth direction.
These would be instructions for one imaginary haircut, not a universal recommendation. The purpose would be to describe something that works for a particular person. The meaning of the annotations would also need agreement: for instance, the target length after cutting must not be confused with the clipper guard used to achieve it.
After the appointment, the barber and customer could update the prescription. The next version might specify eight millimetres more on top, a slightly lower fade, and no thinning at the right front. “The same as last time” would become something that could be checked.
The core would be an open file format. Customers could keep their prescriptions and take them to another service or show them on paper. Barbers would not need to read software code: an application would present the information as an understandable map and text.
A small common core would describe areas, lengths, transitions, and additional instructions. More detailed systems could add a three-dimensional head model, growth directions, or haircut history. An application should also say when it cannot display an important extension, so an incomplete instruction does not appear complete.
The standard would therefore not define everyone’s head as identical. It would provide shared names for areas and a way to describe individual differences. Professionals could still adapt the instructions and discuss what is possible.
The first experiment could be a shared paper or file template used by a few barbers and customers. The key question would be whether another barber could use the instructions without a lengthy additional explanation. Only then would it make sense to increase technical precision.
Later, the same format could provide input for robotic haircutting. A prescription intended for humans would not, however, constitute safe machine instructions on its own: a device would need its own interpretation, measurements, and safety limits. A common description could connect systems even when their implementations differed.
The basic prescription format and a reference reader could be published openly. Paid editors, salon customer systems, or services converting different systems’ annotations into the common format could still be built around it. Customers would not be buying permission to use their own haircut; professionals would pay for tools that made their work easier.
An experiment would therefore not need to begin with an agreement across the entire industry. One salon could issue prescriptions that customers could show elsewhere. The common format would become more useful as others learned to read and update it. It would nevertheless have to earn its usefulness in practice: if filling out a prescription takes longer than interviewing a new customer, openness alone will not make it attractive.
A personal haircut prescription is not a new idea. For example, the GRÜM concept describes a portable haircut passport with a recipe, while the HairCut History product page describes measurements by area and sharing with another barber. The former presents a concept under development and the latter describes a product; their effectiveness has not been tested here.
This article adds a distinction between the prescription and an individual application: could a haircut be described in an open, interoperable format that different services and eventually devices could read? The sources checked did not describe precisely such a shared standard.
Even without a new standard, customer records, photographs, and AI-organized notes could make cuts easier to repeat. The additional benefit of an open format would be keeping the information usable when changing services, barbers, and potentially equipment manufacturers.
It could reduce explaining and uncertainty and make trying a new barber easier. Schools and software developers could also build different tools on the same foundation. The first measure of success would nevertheless be ordinary: did the new barber understand the prescription, and did it help produce the haircut the customer meant?
]]>Concept draft: the vessel, routes, and costs have not been designed or tested. The calculation below is an imaginary comparison scenario.
The idea starts with the service commitment. A small water shortcut would not be intended to replace a bridge, a year-round island ferry, or an essential transport service that must work in difficult weather. A limited service could suspend operations proactively.
That could allow a simpler and cheaper implementation. Savings would nevertheless not follow merely from calling the vessel a robot. Working docks, charging, cargo handling, maintenance, and a way to assist a vessel in trouble would also be necessary.
The first application would be goods transport. Passenger transport could be investigated separately later. A successful cargo route would not itself establish that the same vessel or operating model was suitable for passengers.
In the morning, the vessel could deliver groceries to an island collection dock. Its return trip could carry a fisher’s catch or small consignments. Later, the same capacity could carry tools, spare parts, or farming supplies.
Shared use would matter because a vessel waiting for just one infrequent task might see too little activity. Orders would need combining so transport remained useful without every customer requiring an individual departure. An inexpensive water route does not help if getting goods to the dock costs more than the entire road detour.
The network could be based on a common vessel design and similar docks, charging points, and remote supervision. Each additional route would still need a local assessment. A short distance on a map says little about waves, other traffic, or cargo handling arrangements.
An autonomous or remotely supervised vessel would need predefined responses to deteriorating weather, communication loss, and technical failure. When is a departure cancelled, where does an interrupted vessel go, and who attends when needed? These would be basic service questions.
Users should be told clearly when the route is available and what the alternative is. If the purpose is to make daily life easier, waiting for an uncertain delivery must not create another inconvenience. Limited availability could be acceptable if understood in advance.
A historical predecessor reaches surprisingly far back. Nikola Tesla demonstrated his radio-controlled boat in New York in 1898 (Nikola Tesla Museum). It was a boat, rather than an autonomous robot ferry of the kind envisioned here.
Similar applications are not even purely speculative: Tesla’s patent US613809A mentions carrying letters, packages, provisions, and other goods, as well as reaching inaccessible regions. He therefore considered practical transport tasks for remote control too.
Was Tesla also contemplating something like a network of small water shortcuts? These sources do not tell us, but it is an intriguing possibility to consider. Perhaps today’s opportunity is to turn an old transport vision into an everyday service using contemporary technology. This comparison is speculation, not a claim about Tesla’s plans.
Autonomous electric vessels and their use for goods transport have already been researched and trialled. A close counterpart is Japan’s Smart Island trial, which combined grocery and passenger transport and tested remote supervision. The Roboat II study also examines an autonomous vessel for urban waterways. This is therefore neither new vessel technology nor an entirely new transport idea.
This article adds a particular scope: which small cargo routes could use common equipment if the service did not have to operate year-round or in every condition? Its contribution is to clarify an operating model and the conditions for its viability.
The comparison is not a world in which transport continues unchanged forever. Electric cars, combined deliveries, and existing water services can already reduce costs. A robot ferry’s additional benefit would be only the remaining detour its route actually eliminates beyond those improvements.
Suppose a route operates on 200 days a year and replaces 20–50 separate road journeys daily. Assume each replacement removes 20 kilometres after accounting for trips to docks and onward delivery. These are scenario assumptions for the calculation, not observations about an identified route or demand.
Avoided driving would then be 200 × 20–50 × 20 = 80,000–200,000 kilometres annually. The calculation requires journeys genuinely disappearing: if groceries would already travel in one delivery van, they cannot be counted as separate car trips.
Avoided kilometres cannot be converted into universally applicable monetary savings using one country’s reimbursement rate. The monetary counterpart would be locally avoided driving costs minus the full annual cost of the water service. This would include capital costs for the vessel and docks, energy, supervision, maintenance, insurance, and cargo handling. A car’s fixed costs would not necessarily disappear alongside the driving.
Adequate cost data for a specific route are unavailable here, so no figure is assigned to net savings or a payback period. The biggest source of uncertainty is how many separate detours would actually disappear. Operating days and human labor requirements could also change the result completely. The first assessment should examine one route, count actual deliveries, and obtain implementation cost estimates. A global monetary figure would offer false precision at this stage.
Beyond savings, a water shortcut could enable things not currently done: delivering a small harvest to a buyer, sharing a tool across the water, or extending a service to an island. These would be new opportunities and must not be counted again as avoided car journeys.
Water could thereby become a connection rather than a barrier in daily life. The key would be finding locations where a short crossing, sufficient use, and a manageable service commitment coincide. One vessel would not need to transform all transport if it made one useful shortcut work.
]]>Idealuonnos: suoja on toteutusehdotus, jonka toimivuutta ja sopivia raja-arvoja pitäisi vielä kokeilla.
Ajatus on yksinkertainen: painallusta ei pitäisi tulkita varmaksi tahdonilmaukseksi, jos sen kohde vaihtui juuri ennen osumaa. Käyttäjä ehti päättää painavansa yhtä asiaa, mutta sivu vaihtoi tilalle toisen.
Suoja toimisi selaimessa, joten sen käyttäminen ei edellyttäisi jokaisen verkkosivun korjaamista erikseen. Ensimmäisen kokeilun voisi tehdä Androidille tarkoitetussa Chromium-pohjaisessa selaimessa. Chromium on avoimen lähdekoodin selainprojekti, jonka päälle tällaisen muutoksen voisi rakentaa.
Selain pitäisi lyhyttä muistia näkyvän sisällön liikkeistä. Kun sormi koskettaa näyttöä, se tarkistaisi, liikkuiko kosketuskohdan sisältö juuri merkittävästi ja vaihtuiko kohdassa oleva painettava kohde.
Muistiinpanojen alustava tarkasteluikkuna on 50–100 millisekuntia. Jos samassa pisteessä oli esimerkiksi 20 millisekuntia aiemmin linkki A ja nyt painike B, painallus voitaisiin hylätä. Luvut ovat kokeilun lähtökohtia, eivät tutkimuksella vahvistettuja ihmisen havaintokyvyn rajoja.
Pelkkä liike ei riittäisi perusteeksi. Jos sama linkki siirtyy muutaman pikselin mutta sormi osuu edelleen siihen, painalluksen estämisestä olisi vain haittaa. Ratkaisevaa olisi kohteen vaihtuminen yhdessä riittävän tuoreen ja suuren siirtymän kanssa.
Epäilyttävässä tilanteessa selain ei avaisi kumpaakaan kohdetta eikä jonottaisi painallusta myöhemmäksi. Käyttäjä nostaisi sormen ja painaisi uudestaan. Uusi painallus hyväksyttäisiin normaalisti, jos sisältö olisi ehtinyt vakautua.
Selain voisi samalla antaa hillityn palautteen: kosketus rekisteröitiin, mutta kohde liikkui ja toiminto jätettiin siksi tekemättä. Esimerkiksi lyhyt visuaalinen merkki, värähdys tai tarvittaessa selite voisi erottaa tilanteen siitä, ettei laite huomannut kosketusta lainkaan. Sopiva palautetapa pitäisi kokeilla niin, ettei suoja itse ala häiritä käyttöä.
Väärä hälytys pakottaisi silti käyttäjän yrittämään uudelleen. Kokeilussa pitäisi mitata sekä estettyjä vahinkopainalluksia että aiheettomasti estettyjä oikeita painalluksia ja sitä, ymmärtääkö käyttäjä saamansa palautteen. Suoja olisi hyödyllinen vain, jos se poistaisi enemmän vaivaa kuin aiheuttaisi.
Selain olisi ensimmäinen kokeilukohde, mutta lopulta suojaa voisi yrittää toteuttaa myös Androidin käyttöliittymätasolla. Esimerkiksi puhelinvalmistaja voisi kokeilla sitä omassa käyttöliittymäversiossaan, jolloin ajatus voisi ulottua verkkosivuilta myös järjestelmän näkymiin ja mahdollisesti sovelluksiin.
Tämä on jatkokehityksen mahdollisuus, ei väite siitä, että selainratkaisun voisi sellaisenaan siirtää koko puhelimeen. Laajempi toteutus vaatisi oman selvityksensä siitä, miten kohteiden liikkeet tunnistetaan ja painallukset käsitellään eri näkymissä. Periaate ja käyttäjälle annettava palaute voisivat silti olla samat.
Hain vastineita hakusanoilla kuten layout shift accidental clicks, recently moved iframe ja browser click stability. Ongelma ja osa ratkaisusta tunnetaan jo hyvin. Kolme läheistä vastinetta auttavat rajaamaan, mitä tässä oikeastaan ehdotetaan.
Chromiumin kehittäjien vuoden 2023 ilmoitus kuvaa syötetapahtumien hylkäämistä äskettäin liikkuneista, toiselta alkuperältä upotetuista kehyksistä. Ilmoitus laajensi aiempaa, rajatumpaa suojaa. Painalluksen estäminen liikkeen vuoksi ei siis itsessään ole uusi keksintö.
Googlen CLS-ohje käsittelee odottamattomia sisällön siirtymiä ja niiden aiheuttamia virhepainalluksia. Kyse on sivun vakautta kuvaavasta mittarista. Se auttaa tunnistamaan ongelman, mutta mittaaminen ei itsessään määrittele ehdotettua yleistä painallussuojaa.
Layout Instability -määrittely sisältää tietoja liikkuneiden elementtien aiemmista ja uusista suorakulmioista. Se antaa toteutukselle lähtökohdan. Täydellinen historia siitä, mikä painettava kohde oli jokaisessa näyttöpisteessä, vaatisi kuitenkin omaa toteutustyötä. Pelkkä siirtymien loki ei ole valmis ratkaisu.
Selainohjelmien testaamiseen käytetty Playwright tarkistaa ennen tavallista automaattista klikkausta muun muassa kohteen vakauden. Vakaus tarkoittaa siinä samaa rajaavaa suorakulmiota vähintään kahdessa peräkkäisessä animaatiokehyksessä. Testityökalun odotus palvelee kuitenkin automaattista toimintoa; tässä ehdotetaan suojaa ihmisen jo aloittamalle painallukselle.
Uutuusehdotus on siis nykyistä laajempi, kohteen vaihtumisen huomioiva suoja tavallisille linkeille ja painikkeille. Näillä hauilla en löytänyt täsmälleen muistiinpanojen mukaista yleistä toteutusta. Tämä ei osoita, ettei sellaista voisi olla olemassa.
Hyöty syntyisi väärien sivujen avaamisen, paluun ja uuden yrityksen välttämisestä. Maailmanlaajuinen rahaluku vaatisi kuitenkin tietoa vahinkopainallusten yleisyydestä, niiden kustannuksesta ja siitä, kuinka suuren osan suoja todella estäisi. Näille ei tässä ole riittävää pohjaa.
Vertailukohtana on lähitulevaisuus, jossa sivujen tekijät parantavat vakautta ja selaimissa on jo rajattuja suojia. Idean lisäarvo olisi jäljelle jäävien virheiden torjuminen myös sivuilla, joiden toteutukseen käyttäjä ei voi vaikuttaa. Se ei korjaisi itse hypähtävää sivua.
Merkitys ei rajoittuisi säästyneisiin sekunteihin. Jos puhelin tekisi harvemmin jotakin muuta kuin käyttäjä tarkoitti, se voisi vähentää digitaalista turhautumista ja tehdä älypuhelimen käytöstä sujuvampaa ja helpommin lähestyttävää. Selkeä palaute auttaisi samalla ymmärtämään, mitä laite teki ja miksi.
Yksittäinen korjattu painallus on pieni asia. Jos parannus toistuisi suuren käyttäjäjoukon arjessa päivästä toiseen, pienelläkin muutoksella voisi olla suuri kokonaisvaikutus. Kyse olisi sekä nykyisen vaivan vähentämisestä että siitä, että puhelimella hoitaminen voisi tuntua useammasta ihmisestä mielekkäältä. Vaikutuksen suuruus pitäisi selvittää käytössä, ei päätellä pelkästä käyttäjämäärästä.
Lisäksi tällainen suoja voisi tehdä hankalista sivuista käyttökelpoisempia ihmisille, joille toistuva tarkka kohdistaminen on vaikeaa. Tämä on mahdollinen jatkokäyttö, ei osoitettu saavutettavuushyöty. Sen arvioimiseksi pitäisi kokeilla suojaa erilaisten käyttäjien ja sivujen kanssa: milloin uusi yritys on pieni helpotus ja milloin se muodostuu uudeksi esteeksi?
]]>Concept draft: this is an implementation proposal whose effectiveness and thresholds still need testing.
The idea is simple: a tap should not be treated as a definite expression of intent if its target changed just before contact. The user decided to tap one thing, but the page replaced it with another.
The safeguard would operate in the browser, so using it would not require every website to be fixed separately. An initial experiment could use a Chromium-based browser for Android. Chromium is an open-source browser project on which such a change could be built.
The browser would keep a short history of movements in visible content. When a finger touches the screen, it would check whether content at that point had just moved significantly and whether the actionable target there had changed.
The notes suggest an initial window of 50–100 milliseconds. If the same point contained link A 20 milliseconds ago but now contains button B, the tap could be discarded. These numbers are starting points for an experiment, not research-established limits of human perception.
Movement alone would not be sufficient. If the same link moves a few pixels but the finger still hits it, blocking the tap would only be inconvenient. The deciding factor would be a changed target combined with a sufficiently recent and substantial movement.
In a suspicious situation, the browser would neither open either target nor queue the tap for later. The user would lift their finger and tap again. The new tap would be accepted normally if the content had settled.
The browser could also provide subtle feedback: the touch was registered, but the target moved, so the action was not performed. For example, a brief visual cue, vibration, or an explanation when needed could distinguish this from a device failing to notice the touch at all. The appropriate feedback would need testing so that the safeguard did not become a distraction itself.
A false alarm would still force the user to try again. An experiment would need to measure both prevented accidental taps and legitimate taps blocked unnecessarily, as well as whether users understood the feedback. The safeguard would be useful only if it removed more inconvenience than it created.
The browser would be the first experimental setting, but eventually the safeguard could also be explored at the Android interface level. A phone manufacturer, for example, could test it in its own interface version, potentially extending the idea from websites to system screens and possibly applications.
This is a possible development direction, not a claim that the browser solution could be transferred unchanged to the entire phone. A broader implementation would require a separate investigation into detecting target movement and handling taps across different screens. The principle and user feedback could nevertheless remain the same.
I searched for related work using terms including layout shift accidental clicks, recently moved iframe, and browser click stability. The problem and part of the solution are already well known. Three close counterparts help define what this proposal actually adds.
A 2023 announcement from Chromium developers describes discarding input events for recently moved cross-origin iframes. The announcement expanded an earlier, more limited safeguard. Blocking a tap because of movement is therefore not itself a new invention.
Google’s CLS guide discusses unexpected content shifts and the incorrect clicks they cause. CLS measures page stability. It helps identify the problem, but measurement does not itself define the proposed general tap safeguard.
The Layout Instability specification includes previous and current rectangles for shifted elements. This provides an implementation starting point. A complete history of which actionable target occupied each screen point would nevertheless require additional implementation work. A log of shifts alone is not a finished solution.
The browser testing tool Playwright checks target stability, among other conditions, before a normal automated click. It defines stability as an unchanged bounding box for at least two consecutive animation frames. A testing tool waits on behalf of an automated action; this proposal protects a tap that a human has already initiated.
The proposed addition is therefore a broader safeguard for ordinary links and buttons that accounts for target changes. These searches did not uncover a general implementation matching the notes exactly. That does not establish that none exists.
The benefit would come from avoiding wrong pages, navigating back, and trying again. A global monetary figure would nevertheless require evidence about the frequency of accidental taps, their cost, and the share this safeguard could actually prevent. There is insufficient basis for those estimates here.
The comparison is a near future in which website developers improve stability and browsers already have limited safeguards. The idea’s additional value would be preventing remaining errors even on sites whose implementation users cannot influence. It would not fix the jumping page itself.
The significance would extend beyond seconds saved. If a phone less often did something other than what its user intended, it could reduce digital frustration and make smartphone use smoother and more approachable. Clear feedback would also help users understand what the device did and why.
A single corrected tap is a small thing. If the improvement recurred in the daily lives of a large group of users, even a minor change could have a substantial overall effect. It would both reduce existing inconvenience and potentially make handling tasks on a phone feel worthwhile to more people. The scale of that effect would need to be established in use, rather than inferred from user numbers alone.
Such a safeguard could also make difficult sites more usable for people who find repeated precise targeting challenging. This is a possible further application, not a demonstrated accessibility benefit. Evaluating it would require testing with different users and sites: when is trying again a small relief, and when does it become another barrier?
]]>Ajatus on lisätä valituksen tekemiseen pieni henkilökohtainen suoritus, joka on helppo tehdä kerran aidossa asiassa mutta raskas toistaa kymmeniä tai satoja kertoja. Tavoite ei ole estää valittamista. Tavoite on tehdä massavalittamisesta huonosti skaalautuvaa: oikeus valittaa säilyy, mutta valitusten automatisointi ja teollinen monistaminen tehdään työlääksi.
Ytimekkäästi: ei maksua valittamisesta, vaan ihmiseltä vaadittava yksilöllinen suoritus.
Valitus vahvistetaan henkilökohtaisesti virkailijalle joko paikan päällä tai etäyhteydellä. Valittaja kertoo omin sanoin
Jokainen valitus vaatii oman vahvistuksensa. Yhtä yleistä tekstiä ei voi monistaa satoihin asioihin, ja vahva sähköinen tunnistautuminen estää kiertämästä järjestelmää eri tunnuksilla.
Vahvistus aktivoituisi vasta, kun samalta henkilöltä tulee poikkeuksellisen paljon valituksia. Tavallinen valittaja, joka valittaa kerran tai pari omasta asiastaan, ei huomaisi järjestelmää lainkaan.
“Hinta” on ensisijaisesti aikaa ja henkilökohtaista osallistumista. Etu ennakkomaksuun verrattuna on, ettei vähävarainen ole lähtökohtaisesti huonommassa asemassa: kaikilla on vuorokaudessa yhtä monta tuntia, mutta ei yhtä paljon rahaa.
Pelkkä fyysinen asiointi olisi ongelmallinen esimerkiksi liikuntarajoitteisille, syrjäseudulla asuville ja ulkomailla oleville. Siksi mukana pitää olla saavutettava etävaihtoehto.
Hallitus valmistelee parhaillaan keinoja aiheettomia valituksia vastaan. Oikeusministeri Leena Meri kertoi syyskuussa 2026, että valmisteilla on ennakkomaksu rajattuihin hallinto-oikeusasioihin, jotka eivät koske valittajan omaa asiaa, sekä seuraamusmaksu tuomioistuimen väärinkäytöstä (Verkkouutiset). Jo tammikuussa ministerit käynnistivät selvityksen, jossa tarkastellaan muun muassa hallinto-oikeuksien ja korkeimman hallinto-oikeuden maksujen korottamista (Valtioneuvosto). Virasto-CAPTCHA on vaihtoehto juuri näille rahaan perustuville keinoille.
Ongelma ei ole uusi. Jo vuonna 2014 uutisoitiin, kuinka yksi ihminen oli työllistänyt Rovaniemen kaupunkia ja tuomioistuimia yli 50 valituksella, kantelulla ja kanteella (Verkkouutiset).
Hain vastineita hakusanoilla kuten massavalitukset, aiheettomat valitukset, sarjavalittaja, vexatious litigant, proof of work spam, mass comments fake identities ja in-person verification appeal.
Cynthia Dwork ja Moni Naor ehdottivat vuonna 1993, että sähköpostin lähettäjän pitäisi tehdä pieni laskentatehtävä, joka on halpa yhdelle viestille mutta kallis miljoonalle. Adam Backin Hashcash toteutti saman vuonna 1997 (Wikipedia). Virasto-CAPTCHA on sama periaate, mutta konelaskennan tilalla on ihmisen aika, jota ei voi ostaa lisää näytönohjaimella.
Englannissa ja Walesissa tuomioistuin voi julistaa henkilön häiriköiväksi asianosaiseksi (vexatious litigant), jolloin hän tarvitsee tuomarin luvan jokaiseen uuteen oikeudenkäyntiin (GOV.UK). Se on raskas, yksilöön kohdistuva ja julkinen leima, joka annetaan vasta pitkän prosessin jälkeen. Virasto-CAPTCHA taas kytkeytyisi päälle automaattisesti määrän perusteella eikä vaatisi ketään julistamaan valittajaa häiriköksi.
Yhdysvalloissa viestintävirasto FCC sai vuonna 2017 verkkoneutraliteetista yli 22 miljoonaa kommenttia, joista New Yorkin osavaltion oikeusministerin mukaan lähes 18 miljoonaa oli väärennettyjä. Yksi 19-vuotias lähetti ohjelmalla 9,3 miljoonaa kommenttia keksityillä nimillä (New Yorkin oikeusministeri).
En löytänyt mallia, jossa valitus pitäisi vahvistaa virkailijalle omin sanoin vasta, kun saman henkilön valitusmäärä ylittää rajan. Lähimmät vastineet joko maksetaan rahalla (oikeudenkäyntimaksu, suunniteltu ennakkomaksu), konelaskennalla (Hashcash) tai ne kohdistetaan yksilöön raskaalla tuomioistuinpäätöksellä (vexatious litigant). Uutuus on näiden välissä: automaattisesti laukeava, kaikille saman hintainen ja tekoälyllä vaikeasti ohitettava kustannus.
Lähivuosina tekoäly tekee yksilöllisen näköisen valituksen kirjoittamisesta lähes ilmaista. Kirjallinen vaatimus “kerro omin sanoin” ei siksi enää yksinään erota aitoa valittajaa massavalittajasta, mutta virkailijan kanssa käyty keskustelu erottaa paremmin. Samaan aikaan Suomeen ollaan tuomassa ennakkomaksuja ja seuraamusmaksuja. Vertailukohta on siis tilanne, jossa massavalituksia torjutaan rahalla. Idean arvo on se, kuinka paljon enemmän se torjuu ja kuinka paljon vähemmän se haittaa vähävaraisia.
| Tekijä | Arvo | Lähde |
|---|---|---|
| Hallinto-oikeuksiin saapuneet asiat (2024) | 19 215 | STT Info / tuomioistuinlaitos |
| Kustannus ratkaistua asiaa kohden, Helsingin HaO (2025) | 1 395 € | Helsingin hallinto-oikeus |
| Massa- ja sarjavalitusten osuus | 2–5 % | oma oletus |
| Idean lisävaikutus maksujen päälle | 20–50 % | oma oletus |
| Viivästyneiden hankkeiden kustannus Suomessa | 1–10 milj. € / vuosi | oma oletus |
| Kerroin muille vauraille demokratioille | 50–200 | oma oletus |
| Euron ja dollarin suhde | 1 € ≈ 1,15 $ | oma oletus |
Tähän ei sisälly sitä, mitä idea säästää vähävaraisille verrattuna maksuihin, eikä sitä, että se suojaa viranomaisia tekoälyn tuottamilta valitustulvilta, jotka voisivat olla paljon nykyistä suurempia.
Arvio on suuruusluokka, ei ennuste. Suurin epävarmuus on viivästyskustannus ja se, kasvaako massavalittaminen tekoälyn myötä moninkertaiseksi. Jos massavalitukset pysyvät nykyisellä tasolla ja maksut tehoavat hyvin, idean lisäarvo jää haarukan alapäähän. Jos ne kasvavat FCC:n kommenttitulvan tapaan, raha ei enää riitä jarruksi, ja ihmisen aikaan perustuvan vahvistuksen arvo kasvaa haarukan yläpäätä suuremmaksi.
]]>The idea is to add a small personal task to filing an appeal: easy to do once in a genuine matter but heavy to repeat dozens or hundreds of times. The goal is not to prevent appeals. The goal is to make mass appeals scale badly: the right to appeal remains, but automating appeals and copying them on an industrial scale becomes laborious.
In short: no fee for appealing, but an individual effort required from a human.
The appeal is confirmed in person with an official, either on site or remotely. In their own words, the appellant states
Every appeal needs its own confirmation. A single generic text cannot be copied into hundreds of cases, and strong electronic identification prevents anyone from gaming the system with different accounts.
The confirmation would only switch on when an unusually large number of appeals comes from the same person. An ordinary appellant who appeals once or twice in their own matter would never notice the system.
The “price” is primarily time and personal participation. The advantage over an advance fee is that a person with little money is not inherently worse off: everyone has the same number of hours in a day, but not the same amount of money.
In-person visits alone would be a problem for, say, people with mobility impairments, people living in remote areas and people abroad. That is why an accessible remote option must be part of it.
The Finnish government is currently preparing measures against unfounded appeals. In September 2026 Minister of Justice Leena Meri said that an advance fee is being prepared for limited administrative court cases that do not concern the appellant’s own matter, along with a penalty fee for abuse of court proceedings (Verkkouutiset). Back in January, ministers launched a study that looks at, among other things, raising the fees of the administrative courts and the Supreme Administrative Court (Finnish Government). An appeals CAPTCHA is an alternative to precisely these money-based measures.
The problem is not new. As early as 2014, the news reported how one person had kept the city of Rovaniemi and the courts busy with more than 50 appeals, complaints and lawsuits (Verkkouutiset).
I searched with terms such as (in Finnish) mass appeals, unfounded appeals, serial appellant, and vexatious litigant, proof of work spam, mass comments fake identities and in-person verification appeal.
In 1993 Cynthia Dwork and Moni Naor proposed that an email sender should perform a small computational task that is cheap for one message but expensive for a million. Adam Back’s Hashcash implemented the same thing in 1997 (Wikipedia). An appeals CAPTCHA is the same principle, but instead of machine computation the cost is human time, which cannot be bought in bulk with a graphics card.
In England and Wales a court can declare a person a vexatious litigant, after which they need a judge’s permission for every new proceeding (GOV.UK). That is a heavy, individually targeted and public label, given only after a long process. An appeals CAPTCHA would instead switch on automatically based on volume and would not require anyone to declare the appellant a nuisance.
In 2017 the US Federal Communications Commission received more than 22 million comments on net neutrality, of which nearly 18 million were fake according to the New York Attorney General. One 19-year-old used software to submit 9.3 million comments under made-up names (New York Attorney General).
I found no model in which an appeal must be confirmed with an official in one’s own words only once the same person’s number of appeals exceeds a threshold. The closest equivalents are paid for with money (court fees, the planned advance fee), with machine computation (Hashcash), or targeted at an individual through a heavy court decision (vexatious litigant orders). The novelty lies between these: a cost that triggers automatically, is the same for everyone and is hard to bypass with AI.
In the next few years AI will make writing an individual-looking appeal almost free. A written requirement to “explain in your own words” will therefore no longer, on its own, separate a genuine appellant from a mass appellant, but a conversation with an official does so better. At the same time Finland is introducing advance fees and penalty fees. The baseline is thus a situation where mass appeals are fought with money. The idea’s value is how much more it stops and how much less it harms people with little money.
| Factor | Value | Source |
|---|---|---|
| Cases received by Finnish administrative courts (2024) | 19,215 | STT Info / Finnish courts |
| Cost per resolved case, Helsinki Administrative Court (2025) | €1,395 | Helsinki Administrative Court |
| Share of mass and serial appeals | 2–5% | own assumption |
| Idea’s additional effect on top of fees | 20–50% | own assumption |
| Cost of delayed projects in Finland | €1–10 million / year | own assumption |
| Multiplier for other wealthy democracies | 50–200 | own assumption |
| Euro to dollar | €1 ≈ $1.15 | own assumption |
This excludes what the idea saves people with little money compared with fees, and the protection it gives authorities against AI-generated floods of appeals, which could be much larger than today’s.
This is an order-of-magnitude estimate, not a forecast. The biggest uncertainties are the cost of delays and whether mass appeals multiply with AI. If mass appeals stay at today’s level and fees work well, the idea’s added value stays at the low end of the range. If they grow like the FCC comment flood, money is no longer enough of a brake, and the value of a confirmation based on human time rises above the top of the range.
]]>