Human Structured Intake

decision.type

Una etiqueta de texto libre que describe la categoría de la decisión o intervención humana registrada — por ejemplo, qué tipo de decisión es, no lo que la decisión concluyó.

Sin este campo, un registro ni siquiera indicaría qué tipo de decisión o intervención se registró. Le da a cada otro campo del registro una categoría a la cual vincularse.

Siempre — este campo es obligatorio para cada Human Structured Intake.

Elija una etiqueta lo suficientemente específica para distinguir esta decisión de otras decisiones de un tipo diferente, pero no duplique la narrativa completa que pertenece al campo title (que se convierte en decision.summary). Un buen tipo de decisión nombra la categoría de la acción; el title/summary describe esta instancia específica.

Distinto del campo común title, que se copia directamente en decision.summary — una breve descripción en lenguaje natural de esta decisión específica. decision_type nombra la categoría; decision.summary narra la instancia.

Un Compliance Officer que aprueba una excepción temporal de política podría registrar el tipo de decisión como «Aprobación de excepción de compliance.» Un responsable técnico que autoriza un reinicio de producción podría usar «Autorización de reinicio de línea de producción.»

• Esto no es una enumeración fija — el validador acepta cualquier texto libre no vacío. La coherencia terminológica entre registros es una disciplina organizativa, no una restricción impuesta por el sistema.
• Un tipo de decisión específico no establece por sí mismo que la decisión se tomara correcta o apropiadamente — solo nombra qué tipo de decisión era.

decision.closure_timestamp_utc

El momento declarado en que la decisión humana en sí se cerró — no el momento en que el registro se envió a EVIDE. Vea la sección dedicada Cierre de la Decisión arriba para la distinción completa con el Intake Timestamp.

Una decisión y su preservación probatoria rara vez ocurren exactamente en el mismo instante. Registrar la hora de cierre declarada, por separado de la hora de intake generada por el servidor, es lo que permite una reconstrucción histórica precisa de cuándo ocurrió realmente la decisión.

Siempre — este campo es obligatorio. Introduzca el momento en que la decisión realmente se cerró, en UTC, no el momento en que está completando el formulario.

Use el momento real en que se cerró la decisión, expresado en UTC en lugar de hora local. Si no está seguro de su desfase UTC local, una herramienta como time.is/UTC puede ayudar a evitar un error de varias horas.

Una línea de producción se detiene a las 14:32 hora local. El responsable técnico revisa las condiciones y autoriza un reinicio, cerrando esa decisión a las 16:00 hora local — pero solo registra el intake en EVIDE a las 18:03, tras terminar otras tareas urgentes. La marca de tiempo de cierre preserva las 16:00 (convertidas a UTC); el Intake Timestamp preserva por separado las 18:03.

• Este no es el momento en que el registro fue recibido por EVIDE — ese es el Intake Timestamp separado, generado por el servidor.
• Introducir la hora local sin convertirla a UTC es el error más común con este campo, y produce una hora de cierre desviada por su desfase UTC local.

authority.role

El rol organizativo, en qué calidad, se declara que se tomó la decisión — distinto de la identidad de la persona que la tomó.

Un nombre por sí solo no indica en qué calidad organizativa se tomó una decisión. El rol ayuda a un lector posterior a reconstruir la autoridad organizativa declarada detrás de la decisión, independientemente de quién ocupara específicamente ese rol en ese momento.

Siempre — este campo es obligatorio para cada Human Structured Intake.

Use el título del rol organizativamente relevante para esta decisión — ej. «Compliance Officer,» «SOC Manager,» «HR Director,» «Fraud Analyst,» «Plant Manager.» Texto libre, no una lista fija.

Distinto de authority_id (quién) y de la identidad DAPI de la sesión conectada (vea Identificador de la Autoridad a continuación). El rol responde a «en qué calidad», no «qué persona específica».

La misma persona podría ocupar varios roles en diferentes decisiones; el mismo rol podría ser ocupado por diferentes personas a lo largo del tiempo. Registrar el rol, por separado del individuo, mantiene legible el contexto organizativo incluso cuando cambia el personal.

• Este campo no verifica que la persona declarada realmente ocupara este rol en la organización — es un valor declarado, como los otros campos de texto libre en esta página.

authority.id

Un identificador declarado de quién tomó la decisión. Verificado en el código: si se deja en blanco, este campo toma por defecto el nombre completo del usuario actualmente conectado — pero puede modificarse, para el caso legítimo de registrar una decisión tomada por otra persona.

No todas las decisiones registradas en EVIDE fueron tomadas por la persona que opera el teclado. Permitir que este campo sea editable permite a una persona registrar con precisión una decisión tomada por un colega, manteniendo a la vez preservada por separado la identidad verificada de la sesión subyacente.

Déjelo en blanco cuando usted, el usuario conectado, sea la persona que tomó la decisión — su nombre se usará automáticamente. Complételo explícitamente cuando esté registrando una decisión tomada por una persona diferente.

No trate este campo como un sustituto, o una modificación, de la identidad verificada de su propia cuenta — esa identidad se preserva por separado y automáticamente, independientemente de lo que introduzca aquí.

Verificado en el código: cada registro Human Structured también lleva authority.dapi_number, el identificador DAPI de la sesión realmente conectada y autenticada — establecido automáticamente por el servidor en cada envío y nunca leído del formulario. authority.id y authority.dapi_number son deliberadamente independientes: el primero es una etiqueta declarada, el segundo es la identidad verificada de la sesión.

Un asistente introduce una decisión en EVIDE en nombre de un gerente que realmente tomó la decisión. El asistente deja su propia sesión autenticada (preservada automáticamente como authority.dapi_number), pero establece authority_id con el nombre del gerente, reflejando con precisión quién realmente tomó la decisión.

• authority_id no es lo mismo que una autoridad verificada de forma independiente. Es un valor declarado, de texto libre, que por defecto coincide con el usuario conectado, pero puede ser sobrescrito.
• Sobrescribir este campo no cambia ni reemplaza la identidad DAPI verificada de la sesión — esa identidad se registra de forma independiente, en un campo separado, independientemente de lo que se declare aquí.

authority.verification

Una nota de texto libre, declarada opcionalmente, que la persona que registra la decisión puede usar si pretende vincular la autoridad declarada a una referencia más específica — por ejemplo, una referencia DAPI para la persona o el rol involucrados.

Le da al declarante una forma de agregar una referencia más específica a la autoridad declarada, sin exigirla en cada registro.

Cuando desee declarar una referencia más específica vinculada a la autoridad detrás de esta decisión, y dicha referencia esté genuinamente disponible para usted.

No use este campo como si escribirlo constituyera una verificación. Es una nota declarada, no una comprobación realizada por EVIDE.

Un Compliance Officer hace referencia a una identidad vinculada a un DAPI interno como contexto de apoyo para la autoridad declarada detrás de la aprobación de una excepción, sin que esa referencia sea comprobada de forma independiente por EVIDE.

• Una nota de verificación completada no significa que EVIDE haya realizado una comprobación de identidad. El estado resultante claimed describe lo que se declaró, no lo que se verificó.
• Este campo no está relacionado con la identidad DAPI de la sesión realmente conectada, que se preserva automática y separadamente (vea Identificador de la Autoridad).

intervention.classification_status

Hace observable la calidad operativa de una clasificación en el momento del depósito, en lugar de presentar cada clasificación con la misma confianza no expresada.

Cuando tenga una opinión sobre cuán consolidada, provisional o controvertida es la clasificación asignada a esta decisión.

Si no tiene base para juzgar la estabilidad de la clasificación, es aceptable dejar este campo sin establecer en lugar de adivinar — el campo es opcional, y el sistema no asume ningún estado predeterminado si está ausente.

intervention.classification_context.threshold_status

Un umbral, en este contexto, es un criterio de decisión predefinido — un límite de política, una regla operativa, una condición de aprobación — frente al cual se puede evaluar una decisión. Este campo declara si se alcanzó dicho umbral.

Expone si un umbral de decisión aplicaba a este caso, y si es así, su estado declarado — información que a menudo es implícita y no documentada en las herramientas de flujo de trabajo ordinarias.

Cuando un umbral, regla o condición de política definida es relevante para esta decisión.

Cuando ningún umbral de este tipo aplica realmente a esta decisión — en ese caso, not_defined es el valor preciso, no simplemente dejar el campo vacío si tiene motivos para declarar activamente que no aplica ningún umbral.

• unknown no debe leerse como equivalente a «no existe ningún umbral». Eso es lo que significa not_defined. unknown significa que un umbral aplica, pero su estado no pudo establecerse.

intervention.classification_context.threshold_reference

Una referencia de texto libre al umbral, política o regla específica citada en threshold_status arriba.

Permite rastrear el umbral declarado hasta algo concreto — un documento de política, un procedimiento, un control interno — en lugar de permanecer como una afirmación general sin atribuir.

Cuando threshold_status es met, not_met, o unknown, y tiene disponible una referencia específica — por ejemplo, un nombre de política, un código de procedimiento, o un identificador de documento, dados solo como ejemplos ilustrativos compatibles con este campo de texto libre.

intervention.classification_context.threshold_authority.attribution_status

La atribución del umbral describe cuán claramente la autoridad o propiedad detrás del umbral citado arriba puede rastrearse hasta una persona, rol o comité específico — no si el umbral en sí se alcanzó.

Se vuelve relevante precisamente cuando se declara un estado de umbral de met o not_met, pero la propiedad de ese umbral no es claramente atribuible a una única fuente — haciendo que esa ambigüedad en sí forme parte del registro preservado.

Cuando tenga una opinión sobre cuán claramente atribuible es la propiedad del umbral citado.

intervention.trace.access

Una referencia de texto libre que permite a alguien posteriormente localizar el contexto más amplio de esta decisión dentro del sistema donde realmente ocurrió — un ticket, un ID de caso, una referencia de pista de auditoría, una referencia de registro, o una referencia de flujo de trabajo, dadas como ejemplos ilustrativos de lo que es semánticamente compatible con este campo.

Una decisión rara vez existe aislada del rastro operativo más amplio que la rodeó. Este campo preserva un puntero a ese rastro, sin que EVIDE necesite recibir o almacenar el rastro en sí.

Siempre que exista una referencia específica y localizable en otro sistema — un número de ticket, un expediente de caso, o una entrada de registro de auditoría — que un revisor posterior pudiera usar para encontrar más contexto.

• Una referencia de trazabilidad no significa que EVIDE tenga acceso a, o haya inspeccionado, el sistema al que apunta esa referencia. Es un puntero declarado, nada más.

handoff.boundary_readiness.status

La disponibilidad del boundary declara cuán lista se considera esta decisión, en el momento del cierre, para su preservación probatoria — específicamente, si un gate de disponibilidad independiente la evaluó, y qué pudo y no pudo observar ese gate. Es una declaración sobre el estado de disponibilidad, no una propiedad que EVIDE misma mida o confirme.

Diferentes decisiones conllevan grados muy diferentes de disponibilidad confirmada de forma independiente antes de preservarse. Agruparlas todas en un solo estado indiferenciado ocultaría exactamente la información que un revisor posterior más necesita: ¿fue esta decisión comprobada de forma independiente antes de registrarse, y si es así, con qué grado de completitud?

Siempre — este campo es obligatorio para cada Human Structured Intake.

Pregúntese concretamente: ¿un mecanismo genuinamente separado de quien tomó la decisión evaluó la disponibilidad de este objeto antes de que se registrara? Si no estaba involucrado ningún mecanismo de este tipo, el valor honesto es candidate. Si estaba involucrado uno, elija entre verified, verified_partial, o unverifiable según cuán completa fue realmente la visibilidad de ese mecanismo.

Verificado en el código: visibility_surface (un campo interno en el payload canónico) se deriva mecánicamente de este valor mediante una correspondencia fija — nunca es una elección separada realizada por la persona que completa el formulario. Este valor también rige si readiness_gate_identifier/readiness_gate_scope_reference y unresolved_signals son obligatorios (vea Relaciones Condicionales entre Campos a continuación para las reglas exactas).

Un responsable técnico que autoriza un reinicio de producción después de una anomalía podría declarar verified_partial si un gate diagnóstico automatizado comprobó la mayoría, pero no todos, los sensores relevantes antes del reinicio — registrándose el sensor específico no comprobado como señal no resuelta.

• La palabra verified en este campo es un valor declarado en el modelo de datos, no una evaluación realizada por EVIDE. EVIDE misma no comprueba si el gate declarado realmente operó, o si sus conclusiones fueron precisas.
• No interprete candidate como un envío deficiente o incompleto — es el valor estructuralmente preciso siempre que no estuviera genuinamente involucrado ningún gate de disponibilidad independiente.

handoff.boundary_readiness.readiness_gate.identifier

Un gate, en este contexto, es cualquier mecanismo — humano o automatizado — que realizó la evaluación de disponibilidad declarada en boundary_readiness_status. Este campo nombra o identifica ese mecanismo.

Permite rastrear la evaluación de disponibilidad declarada hasta algo específico, en lugar de permanecer como una afirmación general sin atribuir.

Obligatorio siempre que boundary_readiness_status sea distinto de candidate — es decir, siempre que se declare un gate independiente.

Una comprobación diagnóstica utilizada antes de autorizar un reinicio de producción, o el código de procedimiento interno que rige una revisión de excepción de compliance.

• El nombre «gate» no implica que EVIDE misma haya ejecutado, gestionado o tenga acceso a este mecanismo. Es un identificador declarado para un mecanismo que operó enteramente fuera de EVIDE.

handoff.boundary_readiness.readiness_gate.scope_reference

Mientras readiness_gate_identifier nombra el mecanismo o control declarado que operó, este campo describe el perímetro o alcance que ese mecanismo se declara haber cubierto.

Un gate nombrado es más útil cuando también se especifica su cobertura — la misma comprobación diagnóstica podría cubrir toda una instalación en un caso y una sola máquina en otro.

Obligatorio bajo la misma condición que readiness_gate_identifier arriba: siempre que boundary_readiness_status sea distinto de candidate.

Distinto de readiness_gate_identifier: uno nombra el mecanismo, el otro describe lo que se declara que cubrió.

Para un reinicio de línea de producción, el identificador podría nombrar el control diagnóstico utilizado, mientras que la referencia de alcance nombra la máquina o línea específica que cubrió ese control.

handoff.boundary_readiness.unresolved_signals

Una señal no resuelta es un elemento específico que permaneció sin resolver o sin atribuir en el momento en que se realizó la evaluación de disponibilidad — el «por qué» declarado detrás de un resultado verified_partial o unverifiable, no solo el hecho de que ocurriera.

Sin esta lista, un lector que se encuentre con «Disponibilidad del boundary: verified_partial» sabría que algo estaba incompleto, pero no qué — a menudo la información individual más útil para una reconstrucción posterior de la decisión.

Obligatorio siempre que boundary_readiness_status sea verified_partial o unverifiable — se requiere al menos una entrada en ese caso.

No se usa, y normalmente se deja vacío, cuando el estado es candidate o verified, ya que en esos casos no se declara ninguna brecha sin resolver.

Enumere cada elemento específico que permaneció sin resolver, tan concretamente como sea posible — se admiten varias entradas cuando más de una señal permaneció abierta.

Directamente regido por boundary_readiness_status: obligatorio (mínimo una entrada) cuando ese valor es verified_partial o unverifiable.

Para el escenario de autorización SOC en los Casos de Uso Empresarial anteriores, esto podría decir: «Origen de dos solicitudes API aún no atribuido.»

• EVIDE no determina por sí misma la veracidad, gravedad, materialidad o relevancia de ninguna señal no resuelta enumerada — preserva la lista declarada exactamente como se introdujo, sin evaluar su contenido de forma autónoma.