Un touchpoint
si fa crescere.
Il paradigma corrente ti chiede di specificare ogni cosa in anticipo, prima di sapere come la proprietà verrà davvero usata, e di accettare l'entropia — il lento decadimento della coerenza — come prezzo per toccare qualcosa dopo. Ekitai parte dall'ipotesi opposta: un touchpoint continua a cambiare per tutta la sua vita, e l'infrastruttura deve rendere quel cambiamento economico.
Le regole che tengono insieme
un sistema che cambia sempre.
Sono i criteri che sciolgono le decisioni quando restano ambigue — per questo li scriviamo.
Referenzia, non rigenerare
Ogni superficie punta a una sorgente unica. Non si duplica il contenuto per riusarlo: lo si referenzia, così una modifica alla sorgente si propaga ovunque senza divergenze.
Disaccoppia contenuto e presentazione
Il cosa e il come vivono separati. La presentazione cambia senza toccare il contenuto, e lo stesso contenuto si manifesta su contenitori diversi restando sé stesso.
EXTEND > REFACTOR > REWRITE
Prima si estende, poi si rifattorizza, solo in ultima istanza si riscrive. La riscrittura getta via conoscenza accumulata: è l'ultima opzione, non la prima.
Verifica prima di dichiarare
Niente è "fatto" finché non è verificato sul comportamento reale. Si dichiara completo ciò che si è visto funzionare, non ciò che dovrebbe funzionare.
Si migra per gravità,
un livello alla volta.
A ogni livello di integrazione di ekitai.js una superficie esterna guadagna capability: visibilità, identità, controllo, continuità. La piattaforma nativa diventa il passo successivo ovvio. Nessuna organizzazione consolida mai tutto su una piattaforma sola, e una value proposition che richiede la migrazione totale è una value proposition che non si realizza.
Prende la forma di ogni contenitore,
Ekitai è giapponese per liquido. Descrive con precisione una sorgente unica che si manifesta su superfici diverse restando riconoscibile: un touchpoint prende la forma del contenitore che riempie — web, app, e-commerce, DOOH, spaziale — e resta lo stesso brand.