Human Structured Intake

decision.type

Eine Freitext-Bezeichnung, die die Kategorie der erfassten menschlichen Entscheidung oder Maßnahme beschreibt — zum Beispiel, um welche Art von Entscheidung es sich handelt, nicht was die Entscheidung ergeben hat.

Ohne dieses Feld würde ein Datensatz überhaupt nicht angeben, welche Art von Entscheidung oder Maßnahme erfasst wurde. Es gibt jedem anderen Feld des Datensatzes eine Kategorie, an die es sich anknüpfen kann.

Immer — dieses Feld ist für jeden Human Structured Intake erforderlich.

Wählen Sie eine Bezeichnung, die spezifisch genug ist, um diese Entscheidung von anderen Entscheidungen einer anderen Art zu unterscheiden, aber duplizieren Sie nicht die vollständige Erzählung, die in das Feld title gehört (das zu decision.summary wird). Ein guter Entscheidungstyp benennt die Handlungskategorie; der title/summary beschreibt diese spezifische Instanz.

Zu unterscheiden vom gemeinsamen Feld title, das direkt in decision.summary kopiert wird — eine kurze Beschreibung dieser spezifischen Entscheidung in natürlicher Sprache. decision_type benennt die Kategorie; decision.summary erzählt die Instanz.

Ein Compliance Officer, der eine vorübergehende Richtlinienausnahme genehmigt, könnte den Entscheidungstyp als «Genehmigung einer Compliance-Ausnahme» erfassen. Ein technischer Leiter, der einen Produktionsneustart autorisiert, könnte «Autorisierung zum Neustart der Produktionslinie» verwenden.

• Dies ist keine feste Aufzählung — der Validator akzeptiert jeden nicht leeren Freitext. Terminologische Konsistenz zwischen Datensätzen ist eine organisatorische Disziplin, keine vom System erzwungene Beschränkung.
• Ein spezifischer Entscheidungstyp stellt an sich nicht fest, dass die Entscheidung korrekt oder angemessen getroffen wurde — er benennt nur, um welche Art von Entscheidung es sich handelte.

decision.closure_timestamp_utc

Der erklärte Zeitpunkt, zu dem die menschliche Entscheidung selbst abgeschlossen wurde — nicht der Zeitpunkt, zu dem der Datensatz an EVIDE übermittelt wurde. Siehe den dedizierten Abschnitt Abschluss der Entscheidung oben für die vollständige Unterscheidung vom Intake Timestamp.

Eine Entscheidung und ihre Beweisbewahrung erfolgen selten im exakt selben Moment. Die Erfassung der erklärten Abschlusszeit, getrennt von der server-generierten Intake-Zeit, ermöglicht eine genaue historische Rekonstruktion, wann die Entscheidung tatsächlich erfolgte.

Immer — dieses Feld ist erforderlich. Geben Sie den Moment ein, zu dem die Entscheidung tatsächlich abgeschlossen wurde, in UTC, nicht den Moment, in dem Sie gerade das Formular ausfüllen.

Verwenden Sie den tatsächlichen Moment des Abschlusses der Entscheidung, ausgedrückt in UTC statt in Ortszeit. Wenn Sie sich Ihres lokalen UTC-Versatzes nicht sicher sind, kann ein Tool wie time.is/UTC helfen, einen Fehler von mehreren Stunden zu vermeiden.

Eine Produktionslinie stoppt um 14:32 Uhr Ortszeit. Der technische Leiter überprüft die Bedingungen und autorisiert einen Neustart, wodurch diese Entscheidung um 16:00 Uhr Ortszeit abgeschlossen wird — erfasst den Intake in EVIDE jedoch erst um 18:03 Uhr, nachdem er andere dringende Aufgaben erledigt hat. Der Abschlusszeitstempel bewahrt 16:00 Uhr (in UTC umgerechnet); der Intake Timestamp bewahrt separat 18:03 Uhr.

• Dies ist nicht der Zeitpunkt, zu dem der Datensatz von EVIDE empfangen wurde — das ist der separate, server-generierte Intake Timestamp.
• Die Eingabe der Ortszeit ohne Umrechnung in UTC ist der häufigste Fehler bei diesem Feld und führt zu einer um den lokalen UTC-Versatz verschobenen Abschlusszeit.

authority.role

Die organisatorische Rolle, in welcher Eigenschaft die Entscheidung erklärtermaßen getroffen wurde — zu unterscheiden von der Identität der Person, die sie getroffen hat.

Ein Name allein gibt nicht an, in welcher organisatorischen Eigenschaft eine Entscheidung getroffen wurde. Die Rolle hilft einem späteren Leser, die erklärte organisatorische Autorität hinter der Entscheidung zu rekonstruieren, unabhängig davon, wer diese Rolle zu diesem Zeitpunkt spezifisch innehatte.

Immer — dieses Feld ist für jeden Human Structured Intake erforderlich.

Verwenden Sie den für diese Entscheidung organisatorisch relevanten Rollentitel — z. B. «Compliance Officer,» «SOC Manager,» «HR Director,» «Fraud Analyst,» «Plant Manager.» Freitext, keine feste Liste.

Zu unterscheiden von authority_id (wer) und von der DAPI-Identität der angemeldeten Sitzung (siehe Kennung der Autorität unten). Die Rolle beantwortet «in welcher Eigenschaft», nicht «welche spezifische Person».

Dieselbe Person könnte je nach Entscheidung mehrere Rollen innehaben; dieselbe Rolle könnte im Laufe der Zeit von verschiedenen Personen besetzt sein. Die Erfassung der Rolle, getrennt von der Einzelperson, hält den organisatorischen Kontext auch bei Personalwechsel lesbar.

• Dieses Feld überprüft nicht, ob die erklärte Person diese Rolle in der Organisation tatsächlich innehatte — es ist ein erklärter Wert, wie die anderen Freitextfelder auf dieser Seite.

authority.id

Eine erklärte Kennung dessen, wer die Entscheidung getroffen hat. Im Code verifiziert: wenn leer gelassen, wird dieses Feld standardmäßig auf den vollständigen Namen des aktuell angemeldeten Benutzers gesetzt — kann aber geändert werden, für den legitimen Fall, eine von jemand anderem getroffene Entscheidung zu erfassen.

Nicht jede in EVIDE erfasste Entscheidung wurde von der Person getroffen, die die Tastatur bedient. Die Bearbeitbarkeit dieses Feldes ermöglicht es einer Person, eine von einem Kollegen getroffene Entscheidung genau zu erfassen, während die zugrunde liegende verifizierte Sitzungsidentität separat bewahrt bleibt.

Lassen Sie es leer, wenn Sie, der angemeldete Benutzer, die Person sind, die die Entscheidung getroffen hat — Ihr Name wird automatisch verwendet. Füllen Sie es explizit aus, wenn Sie eine von einer anderen Person getroffene Entscheidung erfassen.

Behandeln Sie dieses Feld nicht als Ersatz für oder Änderung Ihrer verifizierten Kontoidentität — diese Identität wird unabhängig davon, was Sie hier eingeben, separat und automatisch bewahrt.

Im Code verifiziert: jeder Human Structured-Datensatz führt auch authority.dapi_number, die DAPI-Kennung der tatsächlich angemeldeten, authentifizierten Sitzung — diese wird bei jeder Übermittlung automatisch vom Server gesetzt und nie aus dem Formular gelesen. authority.id und authority.dapi_number sind bewusst unabhängig: das erste ist eine erklärte Bezeichnung, das zweite ist die verifizierte Identität der Sitzung.

Ein Assistent erfasst eine Entscheidung in EVIDE im Namen eines Vorgesetzten, der die tatsächliche Entscheidung getroffen hat. Der Assistent lässt seine eigene Sitzung authentifiziert (automatisch bewahrt als authority.dapi_number), setzt aber authority_id auf den Namen des Vorgesetzten und spiegelt genau wider, wer die Entscheidung tatsächlich getroffen hat.

• authority_id ist nicht dasselbe wie eine unabhängig verifizierte Autorität. Es ist ein erklärter Freitextwert, der standardmäßig dem angemeldeten Benutzer entspricht, aber überschrieben werden kann.
• Das Überschreiben dieses Feldes ändert oder ersetzt nicht die verifizierte DAPI-Identität der Sitzung — diese Identität wird unabhängig, in einem separaten Feld, erfasst, unabhängig davon, was hier erklärt wird.

authority.verification

Ein optional erklärter Freitexthinweis, den die erfassende Person verwenden kann, wenn sie beabsichtigt, die erklärte Autorität mit einer spezifischeren Referenz zu verknüpfen — zum Beispiel einer DAPI-Referenz für die beteiligte Person oder Rolle.

Es gibt dem Erklärenden eine Möglichkeit, eine spezifischere Referenz zur erklärten Autorität hinzuzufügen, ohne diese für jeden Datensatz zu verlangen.

Wenn Sie eine spezifischere Referenz zur Autorität hinter dieser Entscheidung erklären möchten und eine solche Referenz Ihnen tatsächlich zur Verfügung steht.

Verwenden Sie dieses Feld nicht so, als würde das Schreiben eine Verifizierung darstellen. Es ist ein erklärter Hinweis, keine von EVIDE durchgeführte Prüfung.

Ein Compliance Officer referenziert eine mit einer internen DAPI verknüpfte Identität als unterstützenden Kontext für die erklärte Autorität hinter einer Ausnahmegenehmigung, ohne dass diese Referenz von EVIDE unabhängig geprüft wird.

• Ein ausgefüllter Verifizierungshinweis bedeutet nicht, dass EVIDE eine Identitätsprüfung durchgeführt hat. Der resultierende Status claimed beschreibt, was erklärt wurde, nicht was verifiziert wurde.
• Dieses Feld steht in keinem Zusammenhang mit der DAPI-Identität der tatsächlich angemeldeten Sitzung, die automatisch und separat bewahrt wird (siehe Kennung der Autorität).

intervention.classification_status

Es macht die operative Qualität einer Klassifizierung zum Zeitpunkt der Hinterlegung beobachtbar, anstatt jede Klassifizierung mit gleicher, unausgesprochener Sicherheit darzustellen.

Wenn Sie eine Einschätzung haben, wie gefestigt, vorläufig oder umstritten die dieser Entscheidung zugewiesene Klassifizierung ist.

Wenn Sie keine Grundlage haben, um die Stabilität der Klassifizierung zu beurteilen, ist es akzeptabel, dieses Feld nicht zu setzen, anstatt zu raten — das Feld ist optional, und das System nimmt bei Fehlen keinen Standardzustand an.

intervention.classification_context.threshold_status

Ein Schwellenwert ist in diesem Kontext ein vordefiniertes Entscheidungskriterium — eine Richtliniengrenze, eine Betriebsregel, eine Genehmigungsbedingung — anhand derer eine Entscheidung bewertet werden kann. Dieses Feld erklärt, ob ein solcher Schwellenwert erreicht wurde.

Es zeigt auf, ob ein Entscheidungsschwellenwert für diesen Fall galt und, falls ja, dessen erklärten Status — eine Information, die in gewöhnlichen Workflow-Tools oft implizit und undokumentiert bleibt.

Wenn ein definierter Schwellenwert, eine Regel oder eine Richtlinienbedingung für diese Entscheidung relevant ist.

Wenn kein solcher Schwellenwert tatsächlich für diese Entscheidung gilt — in diesem Fall ist not_defined der korrekte Wert, nicht einfach das Feld leer zu lassen, wenn Sie Grund haben, aktiv zu erklären, dass kein Schwellenwert gilt.

• unknown darf nicht als gleichbedeutend mit «es existiert kein Schwellenwert» gelesen werden. Das bedeutet not_defined. unknown bedeutet, dass ein Schwellenwert gilt, sein Status jedoch nicht festgestellt werden konnte.

intervention.classification_context.threshold_reference

Eine Freitextreferenz auf den spezifischen Schwellenwert, die Richtlinie oder die Regel, die in threshold_status oben genannt wird.

Es ermöglicht, den erklärten Schwellenwert auf etwas Konkretes zurückzuführen — ein Richtliniendokument, ein Verfahren, eine interne Kontrolle — anstatt eine unzugeordnete allgemeine Aussage zu bleiben.

Wenn threshold_status gleich met, not_met oder unknown ist und Ihnen eine spezifische Referenz zur Verfügung steht — zum Beispiel ein Richtlinienname, ein Verfahrenscode oder eine Dokumentkennung, nur als illustrative Beispiele für dieses Freitextfeld angegeben.

intervention.classification_context.threshold_authority.attribution_status

Die Zuordnung des Schwellenwerts beschreibt, wie eindeutig die Autorität oder Eigentümerschaft hinter dem oben genannten Schwellenwert auf eine bestimmte Person, Rolle oder ein Gremium zurückgeführt werden kann — nicht, ob der Schwellenwert selbst erreicht wurde.

Es wird genau dann relevant, wenn ein Schwellenwertstatus von met oder not_met erklärt wird, die Eigentümerschaft dieses Schwellenwerts jedoch nicht eindeutig einer einzelnen Quelle zuordenbar ist — wodurch diese Unklarheit selbst Teil des bewahrten Datensatzes wird.

Wenn Sie eine Einschätzung haben, wie eindeutig zuordenbar die Eigentümerschaft des genannten Schwellenwerts ist.

intervention.trace.access

Eine Freitextreferenz, die es jemandem später ermöglicht, den breiteren Kontext dieser Entscheidung innerhalb des Systems zu finden, in dem sie tatsächlich stattfand — ein Ticket, eine Fall-ID, eine Audit-Trail-Referenz, eine Protokollreferenz oder eine Workflow-Referenz, angegeben als illustrative Beispiele für das, was mit diesem Feld semantisch kompatibel ist.

Eine Entscheidung existiert selten isoliert vom breiteren operativen Verlauf, der sie umgab. Dieses Feld bewahrt einen Zeiger auf diesen Verlauf, ohne dass EVIDE den Verlauf selbst empfangen oder speichern muss.

Immer wenn eine spezifische, auffindbare Referenz in einem anderen System existiert — eine Ticketnummer, ein Fallordner oder ein Audit-Protokolleintrag — die ein späterer Prüfer nutzen könnte, um mehr Kontext zu finden.

• Eine Nachverfolgungsreferenz bedeutet nicht, dass EVIDE Zugriff auf das System hat, auf das diese Referenz verweist, oder es untersucht hat. Es ist lediglich ein erklärter Zeiger, nichts weiter.

handoff.boundary_readiness.status

Die Boundary-Bereitschaft erklärt, wie bereit diese Entscheidung zum Zeitpunkt des Abschlusses für ihre Beweisbewahrung angesehen wird — insbesondere, ob ein unabhängiges Bereitschafts-Gate sie bewertet hat und was dieses Gate beobachten konnte und nicht konnte. Es ist eine Erklärung über den Bereitschaftszustand, keine Eigenschaft, die EVIDE selbst misst oder bestätigt.

Unterschiedliche Entscheidungen tragen sehr unterschiedliche Grade unabhängig bestätigter Bereitschaft, bevor sie bewahrt werden. Alle in einen einzigen undifferenzierten Zustand zusammenzufassen, würde genau die Information verbergen, die ein späterer Prüfer am dringendsten benötigt: wurde diese Entscheidung unabhängig geprüft, bevor sie erfasst wurde, und wenn ja, wie vollständig?

Immer — dieses Feld ist für jeden Human Structured Intake erforderlich.

Fragen Sie sich konkret: hat ein tatsächlich vom Entscheidungsträger getrennter Mechanismus die Bereitschaft dieses Objekts bewertet, bevor es erfasst wurde? Wenn kein solcher Mechanismus beteiligt war, ist der ehrliche Wert candidate. Wenn einer beteiligt war, wählen Sie zwischen verified, verified_partial oder unverifiable, je nachdem, wie vollständig die Sichtbarkeit dieses Mechanismus tatsächlich war.

Im Code verifiziert: visibility_surface (ein internes Feld im kanonischen Payload) wird mechanisch aus diesem Wert über eine feste Zuordnung abgeleitet — es ist niemals eine separate Wahl der Person, die das Formular ausfüllt. Dieser Wert regelt auch, ob readiness_gate_identifier/readiness_gate_scope_reference und unresolved_signals erforderlich sind (siehe Bedingte Beziehungen zwischen Feldern unten für die genauen Regeln).

Ein technischer Leiter, der einen Produktionsneustart nach einer Anomalie autorisiert, könnte verified_partial erklären, wenn ein automatisiertes Diagnose-Gate die meisten, aber nicht alle relevanten Sensoren vor dem Neustart überprüft hat — wobei der spezifische nicht überprüfte Sensor als ungelöstes Signal erfasst wird.

• Das Wort verified in diesem Feld ist ein erklärter Wert im Datenmodell, keine von EVIDE durchgeführte Bewertung. EVIDE selbst prüft nicht, ob das erklärte Gate tatsächlich funktioniert hat oder ob seine Schlussfolgerungen korrekt waren.
• Lesen Sie candidate nicht als mangelhafte oder unvollständige Einreichung — es ist der strukturell korrekte Wert, wenn kein unabhängiges Bereitschafts-Gate tatsächlich beteiligt war.

handoff.boundary_readiness.readiness_gate.identifier

Ein Gate ist in diesem Kontext jeder Mechanismus — menschlich oder automatisiert — der die in boundary_readiness_status erklärte Bereitschaftsbewertung durchgeführt hat. Dieses Feld benennt oder identifiziert diesen Mechanismus.

Es ermöglicht, die erklärte Bereitschaftsbewertung auf etwas Spezifisches zurückzuführen, anstatt eine unzugeordnete allgemeine Aussage zu bleiben.

Erforderlich, wann immer boundary_readiness_status etwas anderes als candidate ist — also immer, wenn ein unabhängiges Gate erklärt wird.

Eine vor Autorisierung eines Produktionsneustarts verwendete Diagnoseprüfung oder der interne Verfahrenscode, der eine Compliance-Ausnahme-Überprüfung regelt.

• Der Name «Gate» impliziert nicht, dass EVIDE selbst diesen Mechanismus ausgeführt hat, verwaltet hat oder Zugriff darauf hat. Es ist eine erklärte Kennung für einen Mechanismus, der vollständig außerhalb von EVIDE operiert hat.

handoff.boundary_readiness.readiness_gate.scope_reference

Während readiness_gate_identifier den Mechanismus oder die Kontrolle benennt, die erklärtermaßen funktioniert hat, beschreibt dieses Feld den Umfang oder Geltungsbereich, den dieser Mechanismus erklärtermaßen abgedeckt hat.

Ein benanntes Gate ist nützlicher, wenn auch seine Abdeckung angegeben wird — dieselbe Diagnoseprüfung könnte in einem Fall eine ganze Anlage und in einem anderen nur eine einzelne Maschine abdecken.

Erforderlich unter derselben Bedingung wie readiness_gate_identifier oben: wann immer boundary_readiness_status etwas anderes als candidate ist.

Zu unterscheiden von readiness_gate_identifier: das eine benennt den Mechanismus, das andere beschreibt, was er erklärtermaßen abgedeckt hat.

Für einen Neustart einer Produktionslinie könnte die Kennung die verwendete Diagnoseprüfung benennen, während die Bereichsreferenz die spezifische Maschine oder Linie benennt, die diese Prüfung abgedeckt hat.

handoff.boundary_readiness.unresolved_signals

Ein ungelöstes Signal ist ein spezifisches Element, das zum Zeitpunkt der Bereitschaftsbewertung ungelöst oder nicht zugeordnet blieb — das erklärte «Warum» hinter einem Ergebnis von verified_partial oder unverifiable, nicht nur die Tatsache, dass ein solches auftrat.

Ohne diese Liste wüsste ein Leser, der auf «Boundary-Bereitschaft: verified_partial» stößt, dass etwas unvollständig war, aber nicht was — oft die nützlichste einzelne Information für eine spätere Rekonstruktion der Entscheidung.

Erforderlich, wann immer boundary_readiness_status gleich verified_partial oder unverifiable ist — in diesem Fall ist mindestens ein Eintrag erforderlich.

Nicht verwendet und normalerweise leer gelassen, wenn der Status candidate oder verified ist, da in diesen Fällen keine ungelöste Lücke erklärt wird.

Listen Sie jedes spezifische Element auf, das ungelöst blieb, so konkret wie möglich — mehrere Einträge werden unterstützt, wenn mehr als ein Signal offen blieb.

Direkt geregelt durch boundary_readiness_status: erforderlich (mindestens ein Eintrag), wenn dieser Wert verified_partial oder unverifiable ist.

Für das SOC-Autorisierungsszenario in den Anwendungsfällen im Unternehmen oben könnte dies lauten: «Herkunft von zwei API-Anfragen noch nicht zugeordnet.»

• EVIDE bestimmt nicht selbst die Wahrheit, Schwere, Wesentlichkeit oder Relevanz eines aufgelisteten ungelösten Signals — es bewahrt die erklärte Liste genau wie eingegeben, ohne deren Inhalt eigenständig zu bewerten.