When sources disagree
What your agent sees when two sources give different values, when a line waits for a person, how protected details and payment routes are guarded, and how a conflict is settled.
In short
Hyperstruck never quietly picks between two sources. A newer value replaces an older one when it clearly takes its place. Otherwise both stay on record with the newest first, and where the change cannot be told apart from a mistake, the line is marked conflicting and waits for a person.
Two values on one line
On a detail that holds one value at a time, such as a clinic day or a delivery address, a later claim ends an earlier one when it takes its place. It can say so ("moved to Thursday", "use the new address instead"), or give a new value that can be linked to the earlier one. The earlier claim is then kept as history, and your agent reads it as "Earlier, until 4 November 2026", followed by what replaced it. A detail that holds several values, such as the doctors at a clinic, keeps each one instead, and a person can always end a claim by correcting it.
When the two can't be linked, or an older source that doesn't say it replaces anything arrives after a newer one, nothing ends. Both claims stay live, the newest leads, and the other is shown beside it as "Also on record, 28 October 2026", each with its date and source. The line still reads settled: your agent has a current value, and it can see there is another one.
A conflicting line
A line is marked conflicting when Hyperstruck cannot tell from what the sources say whether a change was meant. Your agent is still shown the newer claim first and the other beside it, but the line waits for a person or an API key to settle it.
A conflicting line says why in conflict_kind, and says the same in plain words in reason_sentence:
conflict_kind | reason_sentence reads |
|---|---|
two_values_one_key | "Two documents give different values for clinic days, and neither replaces the other." |
protected_change | "A document changed payee account, which is protected. The change waits for your decision before it replaces the value in use." |
partial_change | "A document changed part of delivery window and left the rest unsaid." |
cross_key_undecided | "A later statement on site contact may replace delivery contact." |
same_value_change_stated | "A document says invoice terms changed, but the value reads the same." |
readers_disagree | "The documents that mention clinic days don't agree on what it says." |
two_values_one_key is raised when a passage reads as a replacement but does not clearly name what it replaces, when the two values cannot be compared (a bare "4" against "4 sites"), or when two merged entities each hold a value for the same detail. When a conflict spans two lines (cross_key_undecided), conflicts_with names the other line.
Every state a line can be in
state | Meaning |
|---|---|
settled | A current claim answers the line |
unanswered | Claims are on record, but none can answer the line itself: each is about one occasion, a view, a forecast, a condition, the past, part of the value or a neighboring case, or was said in passing |
conflicting | The line waits for a decision (above) |
open | An obligation is still owed |
done | An obligation was met |
ended | Nothing holds on the line any more, or an obligation was dropped |
Settling a conflict
A person or an API key settles a conflicting line by sending a verdict: either one claim stands, or both do. Send it with POST /verdicts. The line then shows who settled it and when: "Both stand, as Mei Tanaka settled on 28 October 2026". Every line still waiting is listed by GET /to-decide.
Protected details
Some details do real harm if they are wrong: a payee, a bank account, a delivery address. Mark an attribute protected and its current value can only be replaced with a person's approval.
A change to a protected detail is held when it comes from:
- an API key, or
- a source anyone could have written, such as a web search tool.
A held change waits beside the current value as a protected_change, and your agent keeps using the value it had. The text your agent reads says "A change to Ends 8765 (21 October 2026, by Harlow Sync key) waits for a person.", and the item's label reads "Held for a person, 21 October 2026".
An API key may mark an attribute protected. Only a person who may change the agent, such as its home-space steward or an org admin, may remove the mark. Set it with the attribute's nature.
Bank accounts and PayIDs
A payment route, such as a bank account or a PayID, never leads until a person confirms it, in the dashboard or by settling it while signed in. An API key cannot confirm one, and typing it into a message or a chat is not a confirmation.
Until then, the line reads conflicting with conflict_kind protected_change, and each route is labeled "Not confirmed, 21 October 2026". Your agent reads every route with its source and date, oldest first, then the instruction: "Not confirmed: Ends 8765 (Harlow Freight accounts, 21 October 2026). Confirm in the dashboard before paying."
A document never ends a payment route nobody has confirmed. When a second route arrives for the same payee, both wait for a person to say which is right.
A payment route is always protected, so a read shows "Ends 8765" in place of the account number unless a curator asks to see it. See protected values are withheld.
Claims from sources anyone could write
When resolve gathers claims for your agent before a task, it leaves out claims from a source an attacker could reach, such as an open-web search tool. If that leaves an entity with nothing to show, resolve tells your agent that a claim exists and to look it up, so it never assumes nothing is known. The claims are still listed by the Claims API and Claims search, each with its source.