Human Structured Intake - Complete Guide

Documentation › Human Structured Intake

Explore the documentation — select a guide below:

Overview

Why Would an Organization Use Human Structured Intake?

Most organizational decisions leave a trace somewhere — an email, a ticket, a comment in a workflow tool, a line in a spreadsheet. That trace is rarely structured, rarely time-anchored in a tamper-evident way, and rarely designed to survive outside the system that created it. When a decision is later questioned — in an audit, a dispute, a regulatory inquiry, or an internal investigation — reconstructing exactly what was decided, by whom, in what declared role, and under what conditions can be slow, incomplete, or impossible.

Human Structured Intake gives a person a structured way to declare a decision at the moment it closes: the type of decision, who declared it and in what role, when it was closed, the classification and threshold context that applied, whether a readiness gate was involved, and any signals that remained unresolved. EVIDE then canonicalizes that declaration, computes a deterministic hash over it, and preserves it as an independently retrievable record.

Human Structured Intake preserves that a decision was declared — not that the decision was correct.

Preservation of a declaration is not independent validation of the truth of that declaration.

This distinction runs through every field documented on this page. Where a value uses a word like “verified,” that word describes what a person or an upstream mechanism declared — not an assessment EVIDE itself performed, unless stated otherwise for that specific field.

Before the Field Reference

Enterprise Use Cases

The seven scenarios below are illustrative examples of how different functions might use Human Structured Intake. Each shows the kind of decision involved, information that could reasonably be declared, and, just as importantly, the boundary of what EVIDE’s preservation of that record does and does not establish.

Compliance

Compliance exception approval

Event / ContextA Compliance Officer is asked to temporarily authorize an exception to a procedure that would normally be blocked, under time pressure and a documented business justification.

Human DecisionThe officer approves a temporary, scoped exception, subject to specific conditions and a defined review point.

Information That Could Be Declared

Decision type — e.g. “Compliance exception approval”
Authority role — e.g. “Compliance Officer”
Classification status of how settled the categorization is
Threshold status and reference — whether an internal policy threshold was met
Threshold attribution — how clearly the threshold ownership is attributable
Boundary readiness — whether a readiness gate confirmed the conditions, or the officer is only declaring readiness
Trace access — a reference to the internal ticket or case file

Reconstructive ValueA later reviewer, auditor, or regulator can reconstruct that the exception was declared, by whom, in what role, under what declared threshold and readiness conditions, without relying on the officer’s memory or a system log that may since have rotated out.

Boundary of the EVIDE claim: EVIDE preserves that this decision, with this declared context, was recorded at this time. It does not determine whether the exception was substantively or legally justified.

Cybersecurity / SOC

Authorization after a security alert

Event / ContextA Security Operations Center detects anomalous behavior. A human responder reviews the available telemetry and must decide whether to allow continued operation, block, isolate, or escalate.

Human DecisionThe responder authorizes continued operation while an investigation proceeds, rather than an immediate isolation.

Information That Could Be Declared

Decision type — e.g. “Authorization to continue operation pending investigation”
Classification status — often provisional, since the investigation is not yet closed
Boundary readiness — often verified_partial, if some but not all relevant signals were reviewed
Unresolved signals — e.g. “Origin of two API requests not yet attributed”
Trace access — reference to the SOC case or alert ID

Reconstructive ValueIf the incident later escalates, the record preserves exactly what was known, and what was explicitly flagged as unknown, at the moment the decision was made, distinguishing genuine hindsight from information that was actually available at decision time.

This is a case where verified_partial together with a populated unresolved_signals array is often more honest than a premature verified, using only values and relationships actually supported by the validator.

Boundary of the EVIDE claim: EVIDE preserves that the responder declared continued operation under these stated conditions. It does not determine whether the system was actually secure, or whether the decision was the correct security judgment.

Human Resources

Human review of an automated recommendation

Event / ContextAn AI-assisted screening system produces a recommendation about a candidate or employee. A human reviewer examines that recommendation and makes the final call.

Human DecisionThe reviewer accepts, modifies, or overrides the automated recommendation.

Information That Could Be Declared

Who decided, and in what role — e.g. “HR Director”
Exact moment the decision was closed
Any threshold used in the review process
Reference to the internal HR procedure that governed the review
Any elements that remained contested or unresolved at closure

Reconstructive ValueThe record helps preserve a structural separation between what the automated system recommended and what the human being actually decided, a distinction that is often difficult to reconstruct after the fact from system logs alone.

Boundary of the EVIDE claim: EVIDE preserves that a human decision was declared as distinct from a machine recommendation. It does not certify that the human review was substantively adequate, unbiased, or legally compliant.

Fraud Prevention

Manual release of a blocked transaction

Event / ContextAn automated fraud system blocks a transaction as high risk. A fraud analyst reviews the case and must decide whether to release, keep blocked, or escalate.

Human DecisionThe analyst releases the transaction after review, judging the risk signal to be a false positive.

Information That Could Be Declared

Decision type — e.g. “Manual transaction release”
Authority role — e.g. “Fraud Analyst”
Threshold status — whether the fraud-risk threshold that triggered the block is declared as met, not met, or unclear on review
Trace access — reference to the case file or transaction ID

Reconstructive ValueThe record preserves the declared context of the human override, who authorized the release, when, and on what declared basis, independent of whether the transaction later turns out to have been legitimate or not.

Boundary of the EVIDE claim: EVIDE preserves that the override was declared under this stated context. It does not determine whether the transaction was, in fact, fraudulent.

Industrial / Manufacturing

Authorization to restart a production line

Event / ContextA production line stops automatically after an anomaly is detected. A technical manager reviews the relevant conditions and must decide whether to authorize a restart.

Human DecisionThe manager authorizes the restart, having reviewed the available diagnostic information.

Information That Could Be Declared

Threshold reference — e.g. the technical procedure or operational limit that governs restart conditions
Readiness gate identifier — e.g. the diagnostic check performed before authorizing restart
Readiness gate scope reference — e.g. which machine or line the check covered
Unresolved signals, if any condition remains uncertain — e.g. “Sensor 4 reading not yet cross-validated”

Reconstructive ValueIf a related failure recurs later, the record preserves exactly what diagnostic gate was declared to have been checked, and by what scope, before the restart was authorized.

If any condition remains uncertain at the moment of restart, this is exactly the case for verified_partial plus a populated unresolved-signals list, rather than a full verified.

Boundary of the EVIDE claim: EVIDE preserves that a restart authorization was declared under this stated diagnostic context. It does not verify the diagnostic result itself, or guarantee the line was, in fact, safe to restart.

AI Governance

Human authorization of an AI agent action

Event / ContextAn AI agent requests to perform a sensitive action. Before execution, a human authority must approve, reject, condition, or escalate the request.

Human DecisionThe human authority approves the requested action, subject to declared conditions.

Information That Could Be Declared

Decision type — e.g. “Authorization of agent-requested action”
Authority role of the person authorizing
Boundary readiness of the authorization itself
Trace access — reference to the agent request log or governance ticket

Reconstructive ValueHuman Structured Intake records the human decision to authorize. It is deliberately not the same function as declaring the operational perimeter the agent was authorized within (that is the separate declarations extension documented in the JSON Schema Reference), and it is not an automatic execution-authorization mechanism.

Boundary of the EVIDE claim: EVIDE preserves that a human declared this authorization decision, under these declared conditions. It does not verify that the agent subsequently acted within the authorized scope, and does not itself authorize or execute anything.

Incident Response

Decision during an active incident

Event / ContextDuring a cybersecurity incident, a responder must choose between competing courses of action under time pressure, for example isolating a server versus keeping a service operational despite an indicator of compromise.

Human DecisionThe responder declares a chosen course of action, along with the information available at that moment.

Information That Could Be Declared

Decision type — e.g. “Incident containment decision”
Classification status, often provisional during an active incident
Boundary readiness and any unresolved signals at the moment of decision
Trace access — reference to the incident ticket

Reconstructive ValueIncident timelines are frequently reconstructed after the fact under scrutiny. A structured, time-anchored declaration reduces reliance on reconstructing intent from memory or from logs that were not designed for evidentiary use.

Boundary of the EVIDE claim: EVIDE preserves the declared state of information available at the moment of decision. It does not determine, after the fact, whether the decision taken was the objectively best course of action.

Core Concept

Decision Closure

Two different timestamps appear in every Human Structured Intake record, and they answer two different questions:

Timestamp	What it answers
`decision.closure_timestamp_utc`	When was the decision itself closed? This is the moment the person declares the decision was actually made — entered by the person, in UTC.
Intake Timestamp	When did EVIDE receive and preserve this record? This is generated by the server at the moment the intake is processed, not entered by the person.

These two moments are frequently different, and that difference is expected, not an error. A decision might be closed at 16:00 and only recorded in EVIDE at 18:03 — because of a delayed workflow step, a batch submission process, or simply because the person recording it did so later in the day.

Why this distinction matters for historical reconstructability: if the two timestamps were treated as interchangeable, a later reviewer could wrongly conclude that a decision was made at the moment it was administratively recorded, rather than at the moment it was actually closed. Keeping them visually and textually distinct preserves the ability to reconstruct the true sequence of events.

What this does not establish: decision_closure_timestamp_utc is a value declared by the person completing the intake. It is not a cryptographic or trusted timestamp of when the decision was actually made in the outside world — EVIDE has no independent way to confirm that the declared closure time is accurate. What EVIDE does preserve, independently, is the Intake Timestamp: the moment the record itself was received and canonicalized.

Before the Evidentiary Fields

Common / Operational Intake Fields

The seven fields below provide operational and organizational context. They are shared with EVIDE’s other intake types and are not specific to the Human Structured evidentiary model — they are documented here briefly, for completeness, rather than in the same depth as the fields in the next section.

Field	Type	Requirement	What it is
`title`	string	Required	Short label for the record. Verified in the code: this value is copied directly into `decision.summary` in the canonical payload — it is not a separate, unrelated field.
`business_area_id`	integer	Required	The business area the intake belongs to. Verified in the code: must reference an existing, active business area, or the request is rejected.
`description`	string	Optional	Free-text description stored alongside the record. Not included in the canonical evidentiary payload itself.
`context_reference`	string	Optional	Free-text operational reference for internal use.
`notes`	string	Optional	Free-text internal notes.
`topic`	string	Optional	Free-text topic label for organizing intakes.
`case_reference`	string	Optional	Free-text case or matter reference. This is the same field used by the “Evidence from the same case” search available elsewhere in EVIDE.
`evidence_reference`	string	Optional	Free-text evidentiary reference for internal cross-linking.

These fields provide operational and organizational context for locating and managing the intake within the platform. They are not part of the Human Structured evidentiary model documented in the rest of this page, and their presence or absence does not affect the evidentiary fields below.

The Core of This Guide

Human Structured Evidentiary Fields

The fourteen fields below are the fields specific to the Human Structured evidentiary model — verified individually against HumanStructuredIntakeService.php. The table gives a quick summary; a full explanatory card follows for every field.

Field	Type	Requirement
`decision_type`	string	Required
`decision_closure_timestamp_utc`	datetime	Required
`authority_role`	string	Required
`authority_id`	string	Optional
`authority_verification_note`	string	Optional
`classification_status`	enum	Optional
`threshold_status`	enum	Optional
`threshold_reference`	string	Conditional
`threshold_attribution_status`	enum	Optional
`trace_access`	string	Optional
`boundary_readiness_status`	enum	Required
`readiness_gate_identifier`	string	Conditional
`readiness_gate_scope_reference`	string	Conditional
`unresolved_signals[]`	array of strings	Conditional

Decision Type decision_type #decision-type

Required string

Canonical Path

decision.type

What It Means

A free-text label describing the category of the human decision or intervention being recorded — for example, what kind of decision this is, not what the decision concluded.

Why It Exists

Without this field, a record would not indicate what kind of decision or intervention was registered at all. It gives every other field in the record a category to attach to.

When To Use It

Always — this field is required for every Human Structured Intake.

How To Choose The Value

Choose a label specific enough to distinguish this decision from other decisions of a different kind, but do not duplicate the full narrative that belongs in the title field (which becomes decision.summary). A good decision type names the category of action; the title/summary describes this specific instance of it.

Relationships

Distinct from the common field title, which is copied directly into decision.summary — a short natural-language description of this specific decision. decision_type names the category; decision.summary narrates the instance.

Business Example

A Compliance Officer approving a temporary policy exception might record the decision type as “Compliance exception approval.” A technical manager authorizing a production restart might use “Production line restart authorization.”

Example Value

decision_type"Human review of automated recommendation"

Common Misinterpretations

This is not a fixed enumeration — the validator accepts any non-empty free text. Consistency of terminology across records is an organizational discipline, not a system-enforced constraint.
A specific decision type does not by itself establish that the decision was made correctly or appropriately — it only names what kind of decision it was.

What EVIDE Preserves

That a decision of this declared type was recorded, at this declared closure time, by this declared authority.

What EVIDE Does Not Claim

That the declared type is drawn from a controlled or standardized vocabulary comparable across organizations.

Decision Closure Timestamp (UTC) decision_closure_timestamp_utc #decision-closure-timestamp

Required datetime

Canonical Path

decision.closure_timestamp_utc

What It Means

The declared moment at which the human decision itself was closed — not the moment the record was submitted to EVIDE. See the dedicated Decision Closure section above for the full distinction from the Intake Timestamp.

Why It Exists

A decision and its evidentiary preservation rarely happen at the exact same instant. Recording the declared closure time, separately from the server-generated intake time, is what allows an accurate historical reconstruction of when the decision actually happened.

When To Use It

Always — this field is required. Enter the moment the decision was actually closed, in UTC, not the moment you happen to be filling in the form.

How To Choose The Value

Use the actual moment the decision was closed, expressed in UTC rather than local time. If you are unsure of your local UTC offset, a tool such as time.is/UTC can help avoid an off-by-several-hours error.

Conditional Behavior

The value must be a datetime the server can parse; an invalid or empty value is rejected outright with an explicit error, rather than silently defaulting to the current time.

Business Example

A production line stops at 14:32 local time. The technical manager reviews conditions and authorizes a restart, closing that decision at 16:00 local time — but only records the intake in EVIDE at 18:03, after finishing other urgent tasks. The closure timestamp preserves 16:00 (converted to UTC); the Intake Timestamp separately preserves 18:03.

Example Value

decision_closure_timestamp_utc"2026-04-07T16:00:00Z"

Common Misinterpretations

This is not when the record was received by EVIDE — that is the separate, server-generated Intake Timestamp.
Entering local time without converting to UTC is the most common error with this field, and produces a closure time that is off by your local UTC offset.

What EVIDE Preserves

The declared moment the decision was closed, as stated by the person recording it.

What EVIDE Does Not Claim

That this timestamp is a cryptographically trusted or independently verified record of when the real-world decision occurred. It is a declared value.

Authority Role authority_role #authority-role

Required string

Canonical Path

authority.role

What It Means

The organizational role, in what capacity, the decision was declared to have been made — distinct from the identity of the person making it.

Why It Exists

A name alone does not indicate in what organizational capacity a decision was taken. The role helps a later reader reconstruct the declared organizational authority behind the decision, independent of who specifically held that role at the time.

When To Use It

Always — this field is required for every Human Structured Intake.

How To Choose The Value

Use the role title that is organizationally meaningful for this decision — e.g. “Compliance Officer,” “SOC Manager,” “HR Director,” “Fraud Analyst,” “Plant Manager.” Free text, not a fixed list.

Relationships

Distinct from authority_id (who) and from the DAPI identity of the logged-in session (see Authority ID below). Role answers “in what capacity,” not “which specific person.”

Business Example

The same person might hold multiple roles across different decisions; the same role might be held by different people over time. Recording the role, separately from the individual, keeps the organizational context legible even as personnel change.

Example Value

authority_role"Compliance Officer"

Common Misinterpretations

This field does not verify that the declared person actually held this role at the organization — it is a declared value, like the other free-text fields on this page.

What EVIDE Preserves

The declared organizational role or capacity under which the decision was made.

What EVIDE Does Not Claim

That EVIDE independently confirmed the person held this role within the organization.

Authority ID authority_id #authority-id

Optional string

Canonical Path

authority.id

What It Means

A declared identifier for who made the decision. Verified in the code: if left blank, this field defaults to the full name of the currently logged-in user — but it can be changed, for the legitimate case of recording a decision made by someone else.

Why It Exists

Not every decision being recorded in EVIDE was made by the person operating the keyboard. Allowing this field to be edited lets one person accurately record a decision made by a colleague, while still keeping the underlying verified session identity separately preserved.

When To Use It

Leave it blank when you, the logged-in user, are the person who made the decision — your name will be used automatically. Fill it in explicitly when you are recording a decision made by a different person.

When Not To Use It

Do not treat this field as a substitute for, or a modification of, your own verified account identity — that identity is preserved separately and automatically, regardless of what you enter here.

Relationships

Verified in the code: every Human Structured record also carries authority.dapi_number, the DAPI identifier of the actually logged-in, authenticated session — this is set automatically by the server on every submission and is never read from the form. authority.id and authority.dapi_number are deliberately independent: the first is a declared label, the second is the session’s verified identity.

Business Example

An assistant enters a decision into EVIDE on behalf of a manager who made the actual call. The assistant leaves their own session authenticated (preserved automatically as authority.dapi_number), but sets authority_id to the manager’s name, accurately reflecting who actually made the decision.

Example Value

authority_id"Jane Whitfield"

Common Misinterpretations

authority_id is not the same thing as an independently verified authority. It is a declared, free-text value that, by default, matches the logged-in user, but can be overridden.
Overriding this field does not change or replace the verified DAPI identity of the session — that identity is recorded independently, in a separate field, regardless of what is declared here.

What EVIDE Preserves

The declared identifier of who made the decision (defaulting to the logged-in user’s name if left unchanged).
Separately and always: the DAPI identity of the actual authenticated session, in authority.dapi_number.

What EVIDE Does Not Claim

That the declared authority.id value has itself been independently verified against any external identity system.

Authority Verification Note authority_verification_note #authority-verification-note

Optional string

Canonical Path

authority.verification

What It Means

A free-text note, optionally declared, that the person recording the decision can use if they intend to link the declared authority to a more specific reference — for example, a DAPI reference for the person or role involved.

Why It Exists

It gives the declarant a way to add a more specific reference to the declared authority, without requiring one on every record.

When To Use It

When you want to declare a more specific reference tied to the authority behind this decision, and such a reference is genuinely available to you.

When Not To Use It

Do not use this field as if writing it constitutes a verification. It is a declared note, not a check performed by EVIDE.

Conditional Behavior

Verified in the code: if this field is present and non-empty, the server-computed authority_verification_status value in the API response becomes claimed instead of declared — documented in full on the JSON Schema Reference. This reflects that a reference was declared, not that it was verified.

Business Example

A Compliance Officer references an internal DAPI-linked identity as supporting context for the declared authority behind an exception approval, without that reference being independently checked by EVIDE.

Common Misinterpretations

A populated verification note does not mean EVIDE performed an identity check. The resulting claimed status describes what was declared, not what was verified.
This field is unrelated to the DAPI identity of the actual logged-in session, which is preserved automatically and separately (see Authority ID).

What EVIDE Preserves

That a verification-related note was declared, exactly as entered.

What EVIDE Does Not Claim

That the declared note constitutes, or resulted from, an independent identity verification performed by EVIDE.

Classification Status classification_status #classification-status

Optional enum

Canonical Path

intervention.classification_status

Allowed Values

stable

The classification assigned to this decision is considered settled, with no known ambiguity under the active categorization at the time of closure.
Example: a fraud case reviewed and closed with a clear, uncontested categorization.
Does not mean: that the classification is permanently fixed or immune to future revision — only that no ambiguity was known at closure.

provisional

The classification is still tentative or pending refinement — it may change as more information becomes available.
Example: an active security investigation where the incident category may be revised as the investigation continues.
Does not mean: that the decision itself is incomplete — the decision can still be finalized while its classification remains provisional.

contested

The classification is assigned despite a known interpretive disagreement, or overlap with another category.
Example: a decision where two reasonable people could categorize the same case differently, and that disagreement is known at closure.
Does not mean: that the underlying decision is invalid — only that its categorization carries acknowledged interpretive tension.

Why It Exists

It makes the operational quality of a classification observable at the time of deposit, rather than presenting every classification with equal, unstated confidence.

When To Use It

When you have a view on how settled, tentative, or contested the classification assigned to this decision is.

When Not To Use It

If you have no basis for judging the stability of the classification, it is acceptable to leave this field unset rather than guess — the field is optional, and the system assumes no default state if it is absent.

Example Value

classification_status"provisional"

What EVIDE Preserves

The declared stability state of the classification assigned to this decision.

What EVIDE Does Not Claim

That the classification itself is correct — only how settled or contested its assignment was declared to be.

Threshold Status threshold_status #threshold-status

Optional enum

Canonical Path

intervention.classification_context.threshold_status

Allowed Values

met

A relevant decisional threshold is declared to have been met.
Example: an internal policy required a documented justification above a certain risk level, and one was provided.

not_met

A relevant decisional threshold is declared not to have been met.
Example: the review found that the required conditions for automatic approval were not satisfied, prompting manual intervention.

unknown

A threshold exists in this context, but whether it was met is not known at the time of closure. This is different from not_defined — here, a threshold genuinely applies, but its status could not be established.

not_defined

No threshold was defined for this case at all. This is different from unknown — here, there is no applicable threshold to evaluate, rather than an unresolved one.

What It Means

A threshold, in this context, is a predefined decision criterion — a policy limit, an operational rule, an approval condition — that a decision may be evaluated against. This field declares whether such a threshold was met.

Why It Exists

It exposes whether a decisional threshold applied to this case, and if so, its declared status — information that is often implicit and undocumented in ordinary workflow tools.

When To Use It

When a defined threshold, rule, or policy condition is relevant to this decision.

When Not To Use It

When no such threshold genuinely applies to this decision — in that case, not_defined is the accurate value, not simply leaving the field blank if you have reason to actively state that no threshold applies.

Conditional Behavior

Verified in the code: this field governs the visibility of threshold_reference below — if threshold_status is not_defined, any value entered in threshold_reference is silently discarded by the server, even if submitted.

Example Value

threshold_status"met"

Common Misinterpretations

unknown must not be read as equivalent to “no threshold exists.” That is what not_defined means. unknown means a threshold applies, but its status could not be established.

What EVIDE Preserves

The declared status of a decisional threshold relevant to this case.

What EVIDE Does Not Claim

That EVIDE independently evaluated whether the threshold was actually met — this is a declared status.

Threshold Reference threshold_reference #threshold-reference

Conditional string

Canonical Path

intervention.classification_context.threshold_reference

What It Means

A free-text reference to the specific threshold, policy, or rule cited in threshold_status above.

Why It Exists

It lets the declared threshold be traced back to something concrete — a policy document, a procedure, an internal control — rather than remaining an unattributed general statement.

When To Use It

When threshold_status is met, not_met, or unknown, and you have a specific reference available — for example, a policy name, a procedure code, or a document identifier, given only as illustrative examples compatible with this free-text field.

Conditional Behavior

Verified in the code: if threshold_status is not_defined, this field is discarded by the server even if a value is submitted. There is no need to leave it blank defensively — the server enforces this, but it is good practice to leave it empty when no threshold is defined.

Example Value

threshold_reference"Internal policy COM-EXC-04, section 3.2"

What EVIDE Preserves

The declared reference to the specific threshold cited, when a threshold status other than not_defined applies.

What EVIDE Does Not Claim

That the referenced document, policy, or procedure was independently retrieved, read, or validated by EVIDE.

Threshold Attribution Status threshold_attribution_status #threshold-attribution

Optional enum

Canonical Path

intervention.classification_context.threshold_authority.attribution_status

Allowed Values

attributed

A single, identifiable, attributable authority for the threshold was defined at closure.
Example: a policy explicitly owned by a named committee.
When to use: when you can point to one clear owner of the threshold.

fragmented

The threshold is defined across multiple sources, with no single attributable authority.
Example: a rule assembled from several overlapping internal guidance documents with no single owner.
Common misinterpretation: fragmented does not mean the threshold is invalid — only that its ownership is distributed.

implicit

The threshold is present in practice but was not formally defined or attributable at closure.
Example: an unwritten but consistently applied internal norm.
Common misinterpretation: implicit does not mean informal thresholds are illegitimate — only that they lack formal attribution.

unknown

The authority behind the threshold could not be verified at the moment of closure.
Example: the declarant is aware a threshold exists but cannot identify who owns it.

What It Means

Threshold attribution describes how clearly the authority or ownership behind the threshold cited above can be traced to a specific person, role, or committee — not whether the threshold itself was met.

Why It Exists

It becomes relevant precisely when a threshold status of met or not_met is declared, but the ownership of that threshold is not clearly attributable to a single source — making that ambiguity itself part of the preserved record.

When To Use It

When you have a view on how clearly attributable the ownership of the cited threshold is.

Example Value

threshold_attribution_status"attributed"

What EVIDE Preserves

The declared attributability state of the authority behind the cited threshold.

What EVIDE Does Not Claim

Who should own the threshold, or that the threshold’s substance was independently reviewed — only whether an attributable source of authority for it was declared to exist.

Trace Access trace_access #trace-access

Optional string

Canonical Path

intervention.trace.access

What It Means

A free-text reference that lets someone later locate the broader context of this decision within the system where it actually happened — a ticket, a case ID, an audit trail reference, a log reference, or a workflow reference, given as illustrative examples of what is semantically compatible with this field.

Why It Exists

A decision rarely exists in isolation from the broader operational trail that surrounded it. This field preserves a pointer to that trail, without EVIDE needing to receive or store the trail itself.

When To Use It

Whenever a specific, locatable reference exists in another system — a ticket number, case file, or audit log entry — that a later reviewer could use to find more context.

Example Value

trace_access"SOC-CASE-4471"

Common Misinterpretations

A trace reference does not mean EVIDE has access to, or has inspected, the system that reference points to. It is a declared pointer, nothing more.

What EVIDE Preserves

The declared reference for locating further context about this decision.

What EVIDE Does Not Claim

That EVIDE has access to, has retrieved, or has verified the contents of the referenced system.

Boundary Readiness boundary_readiness_status #boundary-readiness

Required enum

Canonical Path

handoff.boundary_readiness.status

Allowed Values

candidate

No independent gate has assessed this object. The declaring party states only that they consider it ready, without an independent check having been performed.
When to choose it: this is the honest default when no separate readiness mechanism was involved — it is not a weaker or lesser value, it is the accurate one for that situation.

verified

An independent readiness gate confirmed stability across what it declares to be complete visibility, with no unresolved signals.
When to choose it: only when a genuinely separate mechanism — distinct from the person or system that made the decision — performed this assessment.
Common misinterpretation: this value cannot be self-declared by simply feeling confident about a decision; it specifically means an independent gate was involved.

verified_partial

An independent gate confirmed what it was able to observe, but explicitly declares that some relevant signals remain unresolved.
When to choose it: when a readiness gate was involved but its visibility was genuinely incomplete — requires at least one entry in unresolved_signals.

unverifiable

A readiness gate attempted an assessment, but the visibility available to it was insufficient to reach any stability conclusion. This demonstrates that diligence was attempted, not that the process failed.
When to choose it: when a genuine attempt at readiness assessment could not reach a conclusion due to insufficient visibility — also requires at least one entry in unresolved_signals.

What It Means

Boundary readiness declares how ready this decision is considered to be, at the moment of closure, for its evidentiary preservation — specifically, whether an independent readiness gate assessed it, and what that gate could and could not observe. It is a declaration about the state of readiness, not a property EVIDE itself measures or confirms.

Why It Exists

Different decisions carry very different degrees of independently confirmed readiness before they are preserved. Collapsing all of them into a single undifferentiated state would hide exactly the information a later reviewer most needs: was this decision independently checked before being recorded, and if so, how completely?

When To Use It

Always — this field is required for every Human Structured Intake.

How To Choose The Value

Ask concretely: did a mechanism genuinely separate from the decision-maker assess this object’s readiness before it was recorded? If no such mechanism was involved, the honest value is candidate. If one was involved, choose among verified, verified_partial, or unverifiable based on how complete that mechanism’s visibility genuinely was.

Relationships

Verified in the code: visibility_surface (an internal field in the canonical payload) is derived mechanically from this value through a fixed mapping — it is never a separate choice made by the person filling in the form. This value also governs whether readiness_gate_identifier/readiness_gate_scope_reference and unresolved_signals are required (see Conditional Field Relationships below for the exact rules).

Conditional Behavior

If this value is anything other than candidate, both readiness_gate_identifier and readiness_gate_scope_reference become required together. If this value is verified_partial or unverifiable, at least one entry in unresolved_signals becomes required.

Business Example

A technical manager authorizing a production restart after an anomaly might declare verified_partial if an automated diagnostic gate checked most, but not all, relevant sensors before the restart — with the specific unchecked sensor recorded as an unresolved signal.

Example Value

boundary_readiness_status"verified_partial"

Common Misinterpretations

The word verified in this field is a declared value in the data model, not an assessment performed by EVIDE. EVIDE does not itself check whether the declared gate actually operated, or whether its conclusions were accurate.
Do not read candidate as a deficient or incomplete submission — it is the structurally accurate value whenever no independent readiness gate was genuinely involved.

What EVIDE Preserves

The declared readiness state at the boundary, and, when applicable, a reference to the declared mechanism that performed the assessment.

What EVIDE Does Not Claim

That EVIDE itself performed, confirmed, or independently verified any readiness assessment. A value of verified describes what was declared about an upstream or independent gate — it is never EVIDE’s own verification of the decision.

Readiness Gate Identifier readiness_gate_identifier #readiness-gate-identifier

Conditional string

Canonical Path

handoff.boundary_readiness.readiness_gate.identifier

What It Means

A gate, in this context, is any mechanism — human or automated — that performed the readiness assessment declared in boundary_readiness_status. This field names or identifies that mechanism.

Why It Exists

It lets the declared readiness assessment be traced to something specific, rather than remaining an unattributed general claim.

When To Use It

Required whenever boundary_readiness_status is anything other than candidate — that is, whenever an independent gate is being declared.

Conditional Behavior

Verified in the code: required together with readiness_gate_scope_reference whenever boundary_readiness_status is not candidate. If either is missing under that condition, the request is rejected. Neither field is requested at all when the status is candidate.

Business Example

A diagnostic check used before authorizing a production restart, or the internal procedure code governing a compliance exception review.

Example Value

readiness_gate_identifier"COM-EXC-04"

Common Misinterpretations

The name “gate” does not imply that EVIDE itself performed, ran, or has access to this mechanism. It is a declared identifier for a mechanism that operated entirely outside EVIDE.

What EVIDE Preserves

The declared identifier of the mechanism that performed the readiness assessment.

What EVIDE Does Not Claim

That EVIDE executed, inspected, or independently verified the named mechanism.

Readiness Gate Scope Reference readiness_gate_scope_reference #readiness-gate-scope

Conditional string

Canonical Path

handoff.boundary_readiness.readiness_gate.scope_reference

What It Means

While readiness_gate_identifier names the mechanism or control that was declared to have operated, this field describes the perimeter or scope that mechanism was declared to cover.

Why It Exists

A named gate is more useful when its coverage is also specified — the same diagnostic check might cover an entire facility in one case and a single machine in another.

When To Use It

Required under the same condition as readiness_gate_identifier above: whenever boundary_readiness_status is anything other than candidate.

Relationships

Distinct from readiness_gate_identifier: one names the mechanism, the other describes what it was declared to have covered.

Business Example

For a production-line restart, the identifier might name the diagnostic control used, while the scope reference names the specific machine or line that control covered.

Example Value

readiness_gate_scope_reference"Line 3, extrusion module"

What EVIDE Preserves

The declared scope or perimeter that the named readiness gate was stated to cover.

What EVIDE Does Not Claim

That the declared scope was independently confirmed to be accurate or complete.

Unresolved Signals unresolved_signals[] #unresolved-signals

Conditional array of strings

Canonical Path

handoff.boundary_readiness.unresolved_signals

What It Means

An unresolved signal is a specific element that remained unresolved or unattributed at the moment the readiness assessment was made — the declared “why” behind a verified_partial or unverifiable result, not just the fact that one occurred.

Why It Exists

Without this list, a reader encountering “Boundary readiness: verified_partial” would know that something was incomplete, but not what — which is often the single most useful piece of information for a later reconstruction of the decision.

When To Use It

Required whenever boundary_readiness_status is verified_partial or unverifiable — at least one entry is required in that case.

When Not To Use It

Not used, and normally left empty, when the status is candidate or verified, since in those cases no unresolved gap is being declared.

How To Choose The Value

List each specific element that remained unresolved, as concretely as possible — multiple entries are supported when more than one signal remained open.

Relationships

Directly governed by boundary_readiness_status: required (minimum one entry) when that value is verified_partial or unverifiable.

Conditional Behavior

Verified in the code: if boundary_readiness_status is verified_partial or unverifiable and this array is empty, the request is rejected.

Business Example

For the SOC authorization scenario in the Enterprise Use Cases above, this might read: “Origin of two API requests not yet attributed.”

Example Value

unresolved_signals[]["Origin of two API requests not yet attributed"]

Common Misinterpretations

EVIDE does not itself determine the truth, severity, materiality, or relevance of any listed unresolved signal — it preserves the declared list exactly as entered, without independently assessing its content.

What EVIDE Preserves

The specific signals declared as unresolved at the moment of the readiness assessment.

What EVIDE Does Not Claim

That EVIDE evaluated the truth, severity, materiality, or relevance of any listed signal. It preserves the declaration, not a judgment about it.

How The Fields Fit Together

Conditional Field Relationships

The rules below are verified directly against the validator in HumanStructuredIntakeService.php — not assumed from field names or general documentation patterns.

If…	Then…
`threshold_status` = `not_defined`	Any value submitted in `threshold_reference` is discarded by the server, even if present in the request.
`boundary_readiness_status` ≠ `candidate`	`readiness_gate_identifier` AND `readiness_gate_scope_reference` both become required together. If either is missing, the request is rejected.
`boundary_readiness_status` ∈ {`verified_partial`, `unverifiable`}	`unresolved_signals[]` becomes required, with a minimum of one entry. An empty array is rejected under this condition.
An `evidence_references[]` entry includes a `hash_value`	`hash_scope` and `hashed_by` both become required together for that entry. A partial hash declaration — a value without both of these — is rejected.

A related, non-conditional fact worth noting here: visibility_surface, an internal field inside the canonical payload, is always derived mechanically from boundary_readiness_status through a fixed mapping. It is never a value chosen directly by the person filling in the form.

Referencing What EVIDE Does Not Hold

External Evidence References

An external evidence reference lets a Human Structured Intake point to an artifact — a document, a screenshot, a log file, a policy — that stays under the organization’s own control, without that artifact ever being uploaded to or held by EVIDE. Verified in the code: this reuses, without modification, the exact evidence_references[] structure already documented on the JSON Schema Reference — not a parallel or Human-specific mechanism.

This matters because it resolves a genuine, common tension: an organization often needs to preserve a verifiable declaration about a decision, while deliberately not handing a sensitive internal document to any external system. External evidence references let both happen at once.

Business example. A Compliance Officer bases a decision on an internal document, POLICY-CREDIT-REV7. The organization keeps that document under its own control. The Human Structured Intake can preserve a declared reference to that policy and, when available, its SHA-256 digest — without EVIDE ever receiving the document itself.

Fields Available Per Reference (all individually optional)

`artifact_type`	Free-text declared type — e.g. `screenshot`, `pdf`, `policy_document`. Not a fixed enumeration.
`pointer`	An implementation-specific reference to the artifact’s location. EVIDE does not resolve, dereference, or fetch it.
`declared_origin`	Free-text description of where the artifact came from.
`declared_relationship`	Free-text description of how the artifact relates to this decision.
`declared_description`	Free-text human-readable description.
`declared_retention_status`	One of `persistent_storage`, `rolling_buffer`, `unknown`. Verified in the code: never defaulted automatically — included only if the person actively selects it.

Optional Digest (SHA-256)

A reference can optionally carry a declared SHA-256 digest of the artifact. See the dedicated SHA-256 section below for exactly what this does and does not establish.

Referencing an Artifact’s Integrity

SHA-256

SHA-256 is a cryptographic hash function: it takes any file and deterministically produces a fixed-length digest such that even a tiny change to the file produces a completely different digest. In an external evidence reference, a declared SHA-256 digest allows a later party who holds the actual artifact to check whether it matches what was declared at intake time.

What this is used for in practice: a declared digest can later be compared against a digest freshly computed on an available artifact. If they match, the artifact has not changed since the digest was declared. If they do not match, either the artifact has changed, or it is not the same file that was originally referenced.

Verified in the code: hash validation on this channel is purely syntactic — the server confirms the declared value is exactly 64 hexadecimal characters, nothing more. EVIDE does not receive the artifact and cannot check whether the declared digest actually corresponds to it. The declared value is preserved exactly as entered, never normalized to uppercase or lowercase.

What A Declared Digest Establishes

That this specific digest was declared, by the person submitting the intake, at this specific time.
A basis for a later, independent comparison against an artifact someone else holds.

What A Declared Digest Does Not Establish

Authorship of the artifact.
Provenance of the artifact.
The substantive truth or accuracy of the artifact’s content.
Legal validity, ownership, or originality.
That EVIDE possessed, inspected, or verified the artifact — it remained external throughout.

The distinction that matters is between five separate things: the external artifact itself (never received by EVIDE); the declared reference to it; the declared digest (optional, syntactically checked only); a later hash comparison that someone else may perform; and EVIDE’s preservation of the declaration — the only one of these five EVIDE actually performs.

Boundary Of The Claim

What EVIDE Preserves

The general principle: structured preservation of the declaration and its associated declared evidentiary context, exactly as submitted, canonicalized and hashed in a deterministic, tamper-evident way.

Concretely, When Present

The declared decision type and closure time.
The declared authority context — role, declared identifier, and the verified DAPI identity of the submitting session.
The declared classification and its stability status.
The declared threshold context and its attribution status.
The declared trace reference.
The declared boundary readiness state and any associated gate information.
Any declared unresolved signals.
Any declared external evidence references, including an optional declared digest.

Read This Before Relying On Any Record

What EVIDE Does Not Claim

EVIDE does not determine whether the human decision was correct.
EVIDE does not automatically validate the truth of every declared field.
A declared external evidence reference does not mean EVIDE inspected the external artifact.
A SHA-256 digest does not by itself establish authorship.
A SHA-256 digest does not by itself establish provenance.
A SHA-256 digest does not establish substantive truth or correctness.
Recording authority information does not automatically mean EVIDE independently verified the declared organizational authority.
A field value containing terms such as “verified” must not be interpreted as an independent EVIDE verification, unless the implementation explicitly provides such verification.

Putting It Together

Complete Business Example

Returning to the Compliance scenario from the Enterprise Use Cases: a Compliance Officer, Jane Whitfield, is asked to approve a temporary exception to the standard vendor onboarding checklist, under a documented business justification and a defined review point.

She closes the decision at 16:00 UTC, but records the intake later, at 18:03 UTC, after finishing a call. She declares her role as Compliance Officer, references the internal policy that governs exceptions of this kind, and notes that an internal review board — a mechanism independent of her own decision — confirmed the relevant conditions with complete visibility before she made her call. She references the internal ticket tracking this exception, and separately declares a policy document with its SHA-256 digest, kept internally rather than uploaded to EVIDE.

Every value below is chosen to be internally consistent and compatible with the conditional rules documented above — fields are included because they fit this specific case, not simply to demonstrate that every field exists.

The Resulting Payload

JSON / Payload Example

This is the canonical payload EVIDE constructs from the example above — verified field by field against HumanStructuredIntakeService.php. Fields generated automatically by the server (never read from the form) are marked accordingly.

"evide_schema": "2.1",
"source_system": "evide_web_human",               // server-generated, fixed for this channel
"source_reference": "web:1042:a3f91c2d",          // server-generated
"source_timestamp_utc": "2026-04-07T18:03:00Z",  // server-generated -- when EVIDE processed this intake

"decision": {
  "type": "Compliance exception approval",
  "status": "finalized",                    // always fixed on this channel
  "closure_timestamp_utc": "2026-04-07T16:00:00Z", // declared -- see Decision Closure above
  "summary": "Temporary exception to vendor onboarding checklist" // copied from the common field "title"
},

"authority": {
  "id": "Jane Whitfield",                     // declared (defaults to logged-in user if blank)
  "role": "Compliance Officer",
  "dapi_number": "DAPI-2K9-XXXX",               // always server-generated from the session, never from the form
  "verification": "Linked to internal DAPI reference for the review board"
},

"intervention": {
  "classification_status": "stable",
  "classification_context": {
    "threshold_status": "met",
    "threshold_reference": "Internal policy COM-EXC-04, section 3.2",
    "threshold_authority": { "attribution_status": "attributed" }
  },
  "trace": { "access": "Ticket COMP-2026-0417" }
},

"handoff": {
  "reconstruction_independence": "declared",   // fixed
  "submission_status": "not_submitted",         // fixed at intake time
  "acceptance_status": "not_claimed",           // fixed at intake time
  "boundary_readiness": {
    "status": "verified",
    "visibility_surface": "declared_complete", // derived mechanically from status above
    "readiness_gate": {
      "identifier": "COM-EXC-04 review board",
      "scope_reference": "Vendor onboarding exceptions, Q2 2026"
    }
  }
},

"extensions": ["evidence_references"],
"evidence_references": [
  {
    "artifact_type": "policy_document",
    "pointer": "internal://policies/vendor-onboarding-v3",
    "declared_origin": "internal policy repository",
    "declared_description": "Policy document supporting this exception approval",
    "hash": { "algorithm": "SHA-256", "value": "cabbcf9f83fb765cd82569e477b6b3abf51d81eba9b3b92f8e9904be98a1a2f8" },
    "hash_scope": "full_file",
    "hashed_by": "internal document management system"
  }
]

Note: unresolved_signals is correctly absent here — it is only required when boundary_readiness.status is verified_partial or unverifiable, not verified as in this example.

Related documentation:

JSON Schema Reference — the full payload schema, including evidence_references and the declarations extension shared with EVIDE ANCHOR.

API Reference — endpoints and operational profiles.

Architecture Guide — architectural rationale and design principles.

Human Structured Intake exists so that a declared human decision, and its declared evidentiary context, can survive outside the system that produced it — independently retrievable, deterministically hashed, and time-anchored.

EVIDE preserves that a decision was declared.
It does not decide whether the decision was right.