Counterparties and entities

What "RESOLVED" means depends on the nature of the transaction. A transfer to a person is resolved without any identity being created: that is the right answer, not a failure. A cash withdrawal is resolved without a merchant. A card purchase, however, requires its counterparty.

resolved: every dimension the archetype requires is present. partial: the nature is known, but a required dimension is missing, or signals contradict each other, in which case the engine declines to conclude. unresolved: even the nature is unknown. Technical errors (401, 409, 503) are never a semantic outcome: they do not carry this field.

The vocabulary is french and it is the database's (the vocabulary of resolution archetypes), kept as is for ti_v1. inconnu: the very nature of the transaction is unknown. non_couvert: the nature is known but no policy covers it (missing = [resolution_policy]).

The dimensions required by the archetype that are absent.

What the normaliser read. Strings, not scores.

null is a result, not a failure: an honest unknown.

The stable identifier of the entity in the graph, as a bare UUID, with no prefix. It is opaque: do not assume any structure in it. The same identifier designates the same entity from one response to the next and from one workspace to the next (the graph is shared; the identifier is not data belonging to your workspace). It is quoted as is in series[].evidence in the form entite:<uuid>.

How the pattern matched the descriptor. Two length ratios, which are properties of the text and not proof of identity. match says by which route (jetons: a whole alias in the descriptor; tronque: a descriptor fragment cut short by the bank). pattern is the matched alias, in plain text.

Four different things that look alike, and that this block refuses to confuse. The entity type (counterparty.kind: brand, legal entity, payment intermediary) says what it is. The activity (activity) says what it does, in industry names. The category (category, outside this object) says where the money went, in budget lines. The transaction type (transaction_type) says what happened. None is derived from another. And there is no category = subscription: a subscription is not a kind of spending, it is a model of commercial relationship. null when the graph knows nothing about this entity: an abstention, not a failure.

The trade, on two levels (parent then code). It stops at the parent when the source stops there: a utility role says "network" without saying which one, and utilities is then returned, never utilities.electricity. What is not known is not filled in.

What is usual in this trade, not a verdict on this transaction. A streaming service sells by subscription; an electricity supplier bills repeatedly without anyone subscribing; a supermarket sells per purchase. It is a plausibility that reinforces a rhythm already observed in the workspace. On its own, it never concludes: commonly_subscription_based on an isolated transaction does not make a subscription, and it is the series (series[].type = subscription) that decides.

The roles the entity holds in the graph (merchant, utility, government, financial_institution, payment_intermediary…). A role is not a trade, but it says enough to derive one when no catalogue covers the entity.

A brand is not a legal entity. "Netflix" is what you read on the statement; "Netflix Inc" is what contracts. The two exist separately in the graph, linked by brand_of, because merging them would erase the day a brand changes owner. null when no parent company is known, not when there is none.

The same identifier space as counterparty.entity_id: a bare, opaque, stable UUID.

Where what we assert comes from. nature ranks knowledge by declared authority, in this order: curated (a person verified it), deterministic (derived mechanically from a fact already held), provider (a third party states it), inferred (we deduced it), participant (a single client said so). This order is declared, not deduced from a number: without it, a deduced 0.95 would beat a verified 0.90. strength only breaks ties at equal nature, and is not calibrated. And no global knowledge comes from a single client: what a workspace observes stays in that workspace. A participant nature can never become a truth of the shared graph.

Always non_calibree in this version, and that is a constraint, not a convention: the value is a vocabulary in the database, the columns that carry it reference it, and a guard rejects any literal outside the vocabulary at every producer. When a real calibration exists, it will enter through a declared migration, together with the corpus that supports it.

How the provenance was established. The keys vary: derivation (categorie_de_depense_vers_activite, role_vers_activite…), categorie_source or role, and note, a constant sentence in French. None of these values is a number.

Says why no identity was established.

A category is not an identity. When the descriptor names a trade ("BOULANGERIE DUPONT", "PHARMACIE DE LA GARE") rather than a known merchant, the response returns that trade here and leaves counterparty at null. Returning "Boulangerie" as the counterparty would amount to naming a shop aisle instead of a business. And it is a budget line, not a trade. This category answers "where did this money go?", from the person's point of view. What the entity does is another field, counterparty.semantics.activity, and the two do not substitute for each other: EDF sells electricity (activity = utilities.electricity) and the spend files under logement.electricite. source says where the line comes from: entity_graph when it is carried by the recognised merchant, generic_trade_entry when it is deduced from a trade word read in the descriptor. The first is bounded by confidence.entity: a poorly recognised merchant does not yield a reliable category. When a rule of your organisation set the category (see customization), source is absent: slug and label then come from the Noryo catalogue, and neither Noryo origin would be true.

Why the engine declined to name, when it could have. trade_not_identity: a trade was recognised, not a merchant. atm_operator_not_counterparty: on a cash movement, the recognised bank operates the cash machine; it is not on the other side. account_bank_not_counterparty: on a bank fee, it is the account's own bank, and naming it teaches nothing. person_named_not_brand: the descriptor names a person, and the recognised merchant belongs to the transfer reference. An abstention is not a failure: policy.outcome can remain resolved if the archetype did not require an entity.

The payment facilitators read in the descriptor (PAYPAL *NETFLIX yields one). They are never the counterparty. evidence is a code and a source, and no longer the matching pattern itself, which is an internal rule.

The facilitator's entity in the graph, when it is there.

The facilitator's code in the reference catalogue.

What the transaction means, as opposed to payment, which says how the money moved. evidence is a rule code, not an explanation: the rule's internal note came out here in an earlier version; the responses created at that time carry legacy_note_redacted.

rail_rule: the rail alone decided. descriptor_rule: the descriptor alone. descriptor_sense_rail_mechanism: the descriptor gives the meaning, the rail the mechanism, with no conflict. rail_and_descriptor_agree: both say the same thing. descriptor_refines_rail / rail_refines_descriptor: one narrows down the other. rail_descriptor_conflict: contradiction, no certainty manufactured (see signal_conflicts). no_rule: nothing applies. The +counterparty_nature suffix says that the nature of the counterparty refined the type.

What the engine understood of the rail and the payment mechanism.

A constant explanatory sentence, in French, restating the difference between rail and transaction_type. Not data.

The signals that contradict each other. When there are any, policy.outcome is partial: the engine declines to conclude.

A sentence, in French: how the conflict was arbitrated.

The outcome of the "sub-merchant" lane (a facilitator carries the real merchant). none: lane not opened. no_candidate: opened, no entity. resolved: a single entity. ambiguous: several, abstention. Absent on the oldest responses, created before this lane existed.

The outcome of the "truncated descriptor" lane (the bank cut the name short). Same values as submerchant_lane. Absent on the oldest responses, created before this lane existed.

The name is kept for ti_v1; this is not a confidence. Each of these numbers is a declared constant, set by the person who wrote the pattern or the rule, and read as is. Every transaction that hits the same pattern receives the same number. Measured on 644 descriptors: precision as a function of the threshold is not monotone: 0.85 gives 0.86 precision, 0.88 gives 0.33, 0.92 gives 0.25, 0.97 gives 0.79. This number does not rank right above wrong. Use it neither as a probability nor as a threshold: use policy.outcome. 0 has a precise meaning per field: abstention (entity), unknown role (counterparty), conflict with no common ancestor (transaction_type). location is always 0: nothing is resolved on this axis in this version.

Always non_calibree in this version, and that is a constraint, not a convention: the value is a vocabulary in the database, the columns that carry it reference it, and a guard rejects any literal outside the vocabulary at every producer. When a real calibration exists, it will enter through a declared migration, together with the corpus that supports it.

Durations, in milliseconds. Nothing to do with a confidence.

The versions that produced this response. A client that keeps a number must keep the version alongside it: the same value, under another version, may no longer measure the same thing.

The ontology of the entity graph (onto_v1).

The transaction type rules (txtype_v1).

The resolution engine (ti_v4).

The same value as policy.policy_version.

Always non_calibree in this version, and that is a constraint, not a convention: the value is a vocabulary in the database, the columns that carry it reference it, and a guard rejects any literal outside the vocabulary at every producer. When a real calibration exists, it will enter through a declared migration, together with the corpus that supports it.

The trade, on two levels (parent then code). It stops at the parent when the source stops there: a utility role says "network" without saying which one, and utilities is then returned, never utilities.electricity. What is not known is not filled in.

What is usual in this trade, not a verdict on this transaction. A streaming service sells by subscription; an electricity supplier bills repeatedly without anyone subscribing; a supermarket sells per purchase. It is a plausibility that reinforces a rhythm already observed in the workspace. On its own, it never concludes: commonly_subscription_based on an isolated transaction does not make a subscription, and it is the series (series[].type = subscription) that decides.

The roles the entity holds in the graph (merchant, utility, government, financial_institution, payment_intermediary…). A role is not a trade, but it says enough to derive one when no catalogue covers the entity.

A brand is not a legal entity. "Netflix" is what you read on the statement; "Netflix Inc" is what contracts. The two exist separately in the graph, linked by brand_of, because merging them would erase the day a brand changes owner. null when no parent company is known, not when there is none.

The same identifier space as counterparty.entity_id: a bare, opaque, stable UUID.

Where what we assert comes from. nature ranks knowledge by declared authority, in this order: curated (a person verified it), deterministic (derived mechanically from a fact already held), provider (a third party states it), inferred (we deduced it), participant (a single client said so). This order is declared, not deduced from a number: without it, a deduced 0.95 would beat a verified 0.90. strength only breaks ties at equal nature, and is not calibrated. And no global knowledge comes from a single client: what a workspace observes stays in that workspace. A participant nature can never become a truth of the shared graph.

Always non_calibree in this version, and that is a constraint, not a convention: the value is a vocabulary in the database, the columns that carry it reference it, and a guard rejects any literal outside the vocabulary at every producer. When a real calibration exists, it will enter through a declared migration, together with the corpus that supports it.

How the provenance was established. The keys vary: derivation (categorie_de_depense_vers_activite, role_vers_activite…), categorie_source or role, and note, a constant sentence in French. None of these values is a number.