O Kairos é a IA. O LifeOS é a arquitetura de dados em que ela opera.
São duas peças de trabalho diferentes, e essa é a que costuma ficar invisível.
Quinze módulos de domínio mais uma camada de identidade modelam a realidade operacional de uma pessoa como dado consultável: o que ela tem, o que ela deve, como ela dorme, o que ela decidiu e o que prometeu.
Pra quem compra, é a resposta concreta do que a coisa faz pela semana dela.
Pra quem contrata, é a engenharia embaixo da IA.
Cada bloco abaixo é um módulo real, com schema declarado. O que aparece aqui é a área que ele governa, o que ele captura e o que ele devolve na prática.
Quem você é: identidade, valores, como você opera, o que te trava.
O agente não te conhece em geral, ele te conhece. Você não explica do zero toda vez.
Sono noite a noite mais cochilos, resumo diário do corpo, ingestão, episódios de saúde, treinos e o catálogo de exercícios e máquinas.
Quando o corpo não está em condição de decidir, o sistema segura a decisão em vez de te empurrar.
O desenho do seu dia, versionado, e a execução real de cada hábito, dia após dia.
A diferença entre o dia que você desenhou e o dia que você viveu, medida em vez de sentida.
Contas, transações, recorrentes e dívidas, com a fase financeira detectada antes de qualquer conselho.
Saldo é derivado do extrato e nunca de memória, e o sistema sabe o que vence antes de você prometer esse dinheiro pra outra coisa.
Cada sessão de trabalho, com entrada, saída e os intervalos descontados um por um.
Quanto a sua hora vale de verdade depois do intervalo, e não quanto você acha que ela vale.
Cada objetivo e sub-objetivo, ligado à área da vida que ele serve.
Um portão de foco pelo método 5/25 do Buffett: poucos ativos por vez, o resto dorme e para de cobrar atenção.
As tarefas, as simples direto no índice e as complexas com nota própria, priorizadas por peso.
O que fazer agora, ordenado, em vez de uma lista que só cresce.
Uma entrada por decisão, imutável, com a data, o porquê, o que era esperado e o que foi trocado.
Quando o resultado chega, ele volta pra linha original. É assim que dá pra saber se você decide bem, em vez de lembrar que decide.
O registro de cada pessoa e entidade da sua órbita, e o que está aberto de cada lado.
Reciprocidade vira dado: quem apareceu, o que ficou pendente e em qual direção.
O que você tem agora e o histórico do que já acabou, separados de propósito.
Responde o que tem em casa e o que dá pra cozinhar com isso, sem você abrir o armário.
A frota, cada abastecimento, cada rodagem e cada item de manutenção, pendente ou feito.
Quanto custa o seu quilômetro de verdade, e o que a manutenção vai cobrar antes de quebrar.
Cada item que você quer, em sequência de execução, com tier, portão e auditoria depois da compra.
O desejo entra numa fila com regra. Você compra na ordem, não no impulso.
Uma linha por dia operado com o estado do operador, o livro de trades, as execuções e o diário.
Cruza como você estava com o que a operação rendeu, que é a correlação que quase ninguém mede.
As empresas, os braços de cada uma e qual deles é a lança do momento.
Uma lança por vez. Os outros braços ficam em conceito até essa aterrissar.
O catálogo do que foi publicado e as medições por peça e por conta, em arquivos separados.
A medição sobrevive à peça: você apaga o post e a série histórica continua verdadeira.
A sua vida em eras, cada uma um nó fechado com começo, virada e fim.
O sistema sabe de onde você veio e não te trata como quem começou ontem.
Cada módulo tem quatro peças com funções estritamente separadas.
O driver é o SSOT de máquina e é portátil: schema, ENUMs, formatos, procedimentos, portões, o mapa de chaves entre módulos, a lista do que nunca fazer e o contrato de falha, com zero dado de usuário dentro.
O state é a realidade operacional daquela pessoa, os dados são as linhas dela, e o cold start é o onboarding que roda uma vez por usuário por módulo.
Um driver nunca escreve o caminho de um usuário dentro dele, e o loader monta driver mais state mais dado em tempo de execução.
É isso que faz disso um produto em vez do caderno de uma pessoa: constrói uma vez, instancia infinitas, em dois eixos, qualquer usuário e qualquer agente.
E a mesma separação decide ONDE cada camada mora.
O framework fica em texto permanentemente, porque driver e cold start são colados dentro de um system prompt e system prompt é texto.
Todo o resto é Postgres com pgvector: as linhas, o state de cada módulo, os boards, o registro de decisões, as eras e a identidade.
O harness consulta o banco e injeta o resultado embaixo do framework.
Não é markdown esperando virar SQL, são duas camadas com formatos escolhidos separadamente.
Cada item aqui existe porque uma falha real produziu ele.
Toda coluna é obrigatória, opcional ou CONDICIONAL, e é no condicional que a migração ingênua quebra.
Quatro colunas do livro de transações são legitimamente vazias por desenho, então um DDL gerado só pelos obrigatórios rejeita 33 linhas válidas na importação.
A exceção está documentada antes da migração em vez de descoberta durante ela.
Cada arquivo declara a própria chave de ordenação, porque uma linha na posição errada faz parse limpo e lê perfeitamente.
Um dos arquivos ordena por uma chave que não é a coluna de data dele, e nada além da declaração contaria isso pra quem lê.
Arquivo onde linha só chega recebe id sequencial.
Arquivo de onde linha sai recebe slug estável, porque um id sequencial é liberado quando a linha vai embora e reaponta silenciosamente toda referência histórica pra outra coisa.
A regra saiu de um bug real onde seis chaves estrangeiras resolviam todas pro item errado.
Contagem de campos por linha contra o cabeçalho, unicidade de chave primária, ordem, resolução de chave estrangeira e conformidade de ENUM.
Roda sempre e não na suspeita, porque uma vírgula sem aspas dentro de um campo de texto desloca todas as colunas seguintes e produz uma linha que ainda faz parse, com valores plausíveis no lugar errado.
Saldos, taxas, totais e proporções são calculados do livro na hora da leitura.
Um texto que guarda um desses já nasce vencido.
Ligadas por uma chave que aponta pra própria tabela, porque o valor muda ao atravessar a moeda e uma linha só não carrega os dois números honestamente.
Um defrag recorrente audita o sistema contra os próprios contratos, módulo por módulo, caçando quatro classes de bug nomeadas: um valor derivado copiado pra dentro de texto e deixado apodrecer, uma mudança que chegou na definição e nunca chegou nas consultas que leem ela, um fato morando no módulo errado, e uma afirmação duplicada dentro da mesma estrutura.
É prática de QA de integridade de dado aplicada a um sistema vivo, e ela já achou defeito que nenhum portão mecânico alcança.
O maior deles: uma métrica de manchete devolvendo 2,86 por hora contra um valor real de 14,11, porque trabalho por hora tinha sido tipado com o formato de pagamento do trabalho por sessão e 392 horas entraram no denominador sem nada no numerador.
Medido em 25 de agosto de 2026, contando os arquivos em disco. O sistema é vivo e a contagem cresce, então a data está aqui pra que o número seja conferível em vez de eterno.
O schema está desenhado e o banco ainda não foi construído.
Hoje as linhas vivem em CSV, e é exatamente por isso que o contrato foi escrito primeiro: quando o banco nascer, a migração executa um plano documentado em vez de descobrir as exceções durante ela.
É dogfood em um usuário só e não é multi-tenant em produção.
O que está em oferta é a arquitetura, a disciplina de contrato e a prática de integridade, e essas três transferem inteiras.
Isso está escrito aqui em cima e não escondido porque uma página cortada de uma fonte inflada cai na primeira pergunta, e é justamente o escopo declarado que torna o resto crível.