Esta página profundiza el concepto de la landing con vocabulario técnico, ciclo de trabajo, CLI, memoria externa y fronteras de autoridad. Está escrita para poder leerse sin conocer la historia interna del proyecto.
Alcance: AK sigue siendo experimental. Esta documentación explica la arquitectura observable y sus límites; no presenta como terminadas capacidades que todavía están en construcción.
Los nombres concretos de artifacts pueden evolucionar. La separación de responsabilidades es la parte importante.
La intención humana ya puede estructurarse, revisarse y evaluarse para determinar si contiene suficiente significado relevante y un objetivo anclado para solicitar la siguiente proyección. Lo que todavía falta es derivar requirements sin inventarlos y materializar una Mission gobernada desde esa base.
El límite es deliberado: “suficiente para avanzar” no significa que existan requirements, que una Mission esté autorizada ni que el Kernel pueda seleccionar trabajo o conceder autoridad por inferencia.
AK evita usar una sola palabra —“aprobado”— para estados que significan cosas distintas.
Existe como propuesta. Puede ser verificable sin tener autoridad para producir efecto.
El cambio fue efectivamente aplicado y observado. No implica que todo su contenido sea una verdad estable.
Una promoción más fuerte que debe ocurrir mediante reglas específicas; tests o merge no la conceden por sí solos.
Una persona declara haber revisado un sujeto exacto. No es lo mismo que autorizar una acción.
Permite una acción concreta bajo un scope y sujeto determinados.
Retira una autoridad previa sin reescribir la historia de que esa autoridad existió.
Fail-closed: ante sujetos ambiguos, autoridad incompatible, cambios no reconciliados o ubicaciones no resolubles, el runtime se detiene en vez de seleccionar silenciosamente “el más nuevo” o “el primero”.
Una lectura útil es “runtime experimental / pre-alpha”: ya existen operaciones reales y verificables, pero todavía falta cerrar la experiencia guiada de extremo a extremo.
ak.Objeto durable y versionable que el Kernel puede identificar, verificar y relacionar: por ejemplo una misión, un estado de revisión, una propuesta de cambio o evidencia.
Unidad de trabajo delimitada con objetivo, inputs, outputs, contexto, restricciones y validators.
Artifact propuesto que todavía no debe confundirse con verdad estable ni con autoridad para actuar.
Incertidumbre registrada: algo que el sistema todavía no sabe o no debe completar por inferencia.
Capacidad declarada. Puede estar implementada por una tool, un modelo, código local o una composición de componentes.
Regla que comprueba una propiedad del artifact, contexto, ejecución o transición sin depender del juicio del modelo que produjo la propuesta.
Rastro durable de inputs, resultados, verificaciones, receipts y observaciones.
Representación de un cambio material propuesto. En el flujo gobernado se propone, verifica, autoriza y aplica como etapas distintas.
Conjunto durable de proyectos, conocimiento, identidades, relaciones y capacidades que puede sostener continuidad más allá de una conversación.
Mientras el runtime siga siendo experimental, la documentación pública puede avanzar más rápido que la distribución del core. Una futura release debería poder demostrar qué se entrega, de dónde proviene y cómo verificarlo.
Mantiene fuera de una release prematura código experimental, RAW, evidencia sensible y decisiones internas todavía no preparadas para soporte público.
Explican concepto, método, estado, límites, CLI relevante, glosario, FAQ y ejemplos sanitizados sin exigir acceso al repositorio.
Cuando corresponda: versión, changelog, checksums, firmas, SBOM/notices y una política explícita de compatibilidad y soporte.