Cómo funciona
Una capa de metodología alrededor del modelo, con un ciclo de aprendizaje detrás.
AuditFellow no reemplaza el chat que usa tu equipo. Adjunta una metodología estructurada a cada pedido en el momento en que el chat lo envía, hace que el modelo razone en un orden fijo, verifica el resultado contra un contrato de salida y convierte las correcciones de tus revisores en reglas versionadas. El modelo escribe; el harness decide cómo es una respuesta correcta.
1 · Inyección a nivel del pedido
El harness viaja con el mensaje, no con la persona
La extensión del navegador intercepta el pedido que el chat envía a su propio servidor y le agrega el harness: el núcleo de razonamiento, el catálogo de skills con sus contratos de salida, las reglas globales y del equipo, y los archivos de conocimiento. El modelo que tu empresa ya paga hace la escritura. Nada se envía a AuditFellow: el único tráfico hacia nosotros es la verificación diaria de la key y la descarga del pack. El harness completo viaja una vez por conversación; los mensajes siguientes llevan un recordatorio corto, y una variante compacta entra en chats con ventanas de contexto chicas.
2 · El ciclo de razonamiento
Ocho fases antes de escribir una palabra del entregable
Entender el pedido; inventariar las herramientas que la sesión realmente tiene; recordar lo que la conversación ya resolvió; asignar el pedido a exactamente una skill, con aislamiento estricto para que ninguna otra metodología se filtre en la forma; elegir la ruta más segura; preguntar como máximo dos cosas, solo por insumos sin los cuales el entregable no puede existir; ejecutar bajo el contrato; entregar en el canal y el idioma de la persona. Cualquier valor que la organización no haya dado, una escala de calificación, un responsable, una fecha objetivo, se escribe como N/A. Nunca se inventa.
3 · Skills con contratos de salida
Una skill es una especificación, no un prompt
Cada skill contiene la metodología de un entregable (un hallazgo, una declaración de riesgo, un control, un papel de trabajo, una estrategia de datos, un documento de uso de IA), una especificación de salida con los campos, su orden y sus etiquetas, y una lista de autorrevisión generada desde esa especificación. La lista corre antes de entregar y nombra explícitamente los modos de falla conocidos, por ejemplo una sección "Riesgo" donde corresponden Impacto en el negocio y Nivel de riesgo. Cada respuesta abre con la línea "AuditFellow · tarea", así cualquiera ve qué metodología se aplicó.
4 · El ciclo de aprendizaje
Las correcciones se vuelven reglas solo después de demostrar que sirven
Un revisor corrige una respuesta con sus palabras. Un destilador convierte la corrección en una regla candidata, conceptual y no una coincidencia de texto. Después una compuerta vuelve a correr un conjunto de pedidos con y sin la regla y puntúa ambos contra las especificaciones de salida; solo se aplica una regla que sube el puntaje. Las reglas se versionan con reversión, viven en la capa del equipo (almacenamiento cifrado que no podemos leer, o tu propio endpoint, solo con reglas destiladas) y llegan a cada key de la organización con el próximo pack, dentro del día. Administradores y coordinadores alimentan la capa del equipo; los auditores conservan sus correcciones en su dispositivo.
Cada noche corremos nuestros propios pedidos con el harness publicado contra un modelo y puntuamos la forma de las respuestas, así una regresión en una plataforma de chat o una actualización del modelo aparece de nuestro lado antes de llegar a tu equipo. Los cambios se listan en la página Updates dentro de la app.