Aparência
Integrações
A Alethoryn foi desenhada para trabalhar sobre sistemas empresariais existentes. A integração não começa por copiar todo o banco de dados nem por criar um segundo ERP; começa por declarar quais Eventos, leituras e efeitos fazem parte de uma jornada operacional concreta.
A arquitetura em três blocos
Sistema de origem
O ERP, CRM, documento, API ou aplicação interna que possui o registro do negócio. Ele continua responsável pelos dados e pelo estado que somente ele pode confirmar.
Adapter
A fronteira que normaliza as diferenças técnicas do sistema e expõe somente capacidades declaradas. Um adapter pode receber Eventos, ler contexto, preparar um efeito, escrevê-lo na origem e observar o resultado — desde que cada operação exista no contrato daquela integração.
Camada Alethoryn
Onde o Caso reúne contexto, política, autoridade, coordenação e evidência. A camada decide qual capacidade pode ser usada; ela não transforma uma capacidade técnica em permissão automática.
Capacidade antes de automação
Cada capacidade precisa declarar, quando aplicável:
- qual domínio e alvo pode acessar;
- quais campos pode ler ou escrever;
- quais unidades, moedas e limites aceita;
- qual autoridade é necessária;
- se o efeito é reversível, compensável ou irreversível;
- como duplicatas são evitadas;
- qual observação pode confirmar o resultado.
O que não foi declarado fica fora da superfície operacional autorizada. Dados ausentes, indisponíveis, não suportados ou redigidos permanecem distintos; nenhum deles é convertido em zero ou “tudo certo”.
Do primeiro Caso ao adapter reutilizável
Uma avaliação de integração segue uma sequência simples:
- escolher um Caso operacional estreito e observável;
- identificar o sistema que possui cada fato e efeito;
- mapear Eventos e capacidades mínimas;
- validar políticas, autoridade e reconciliação em ambiente controlado;
- provar a jornada com dados sintéticos antes de usar um limite real;
- somente então avaliar reaproveitamento na base compatível do parceiro.
Reutilização é uma possibilidade de arquitetura, não uma promessa universal. Diferenças de versão, configuração, dados e módulos podem exigir adaptação adicional.
Modos de entrega e profundidade
Standalone, Hosted/Co-branded e Embedded descrevem onde a experiência aparece. Profundidade de integração descreve quanto a implementação se adapta ao frontend, identidade, navegação e contexto do parceiro.
Os dois eixos são independentes. Um modo Embedded pode exigir uma integração padrão ou uma adaptação mais profunda; isso não altera os invariantes de Caso, Política, Decisão, Evidência e autoridade.
Ecossistemas empresariais
SAP S/4HANA, Microsoft Dynamics 365, Salesforce, Oracle, ERPs regionais e sistemas próprios são exemplos de ambientes sobre os quais essa arquitetura pode ser avaliada.
Esses nomes não indicam parceria, certificação, disponibilidade imediata ou conector oficial.
Disponibilidade atual
Esta documentação descreve a arquitetura e os limites públicos. Não há, neste momento, catálogo público de conectores, runtime endpoint público da Public API V1, SDK oficialmente distribuído ou promessa de prazo de implantação. O Public MCP somente leitura é um subject externo distinto: ele possui endpoint HTTPS em estágio DEMONSTRATION e foi submetido à revisão da OpenAI, sem aprovação ou publicação no diretório observadas. Materiais adicionais só podem ser apresentados junto de uma superfície correspondente, testável e versionada.