Resolving overlapping sources
Real data disagrees. The policy system says a premium is one amount; a benchmarking feed says another. Fusion groups records for the same entity across every source bound to a class, picks one value per attribute, and returns the reasoning with it, so a decision made on that value can be explained.
Request a fused entity#
GET /v1/system/view-gateway/fuse/Policy?key=policyNumber
The gateway reads every view bound to Policy, applying each view's governance separately. A source the caller may not read is skipped and noted. It then groups rows by the identity key: the key parameter, else the class's declared identity key, else id. Matching is exact; fuzzy entity resolution is Planned.
How a value wins#
Each attribute is resolved independently:
- Discard what cannot win
Candidates whose validity has ended, and candidates from untrusted sources with zero accuracy, are dropped with a reason.
- Weigh each candidate
A weight combines the source's accuracy, the value's freshness, the record's completeness, context fit and the fact's own confidence. A source that marks its own value as conflicting is halved.
- Respect authority
A trusted source that is declared authoritative for an attribute limits the winners to authoritative candidates for that attribute.
- Group agreeing values
Values within a per-attribute tolerance count as agreeing. Any disagreement marks the attribute as a conflict.
- Choose the winning group
By total weight, then highest single weight, then trust tier, then freshness, then non-self-conflicting, then source ID. The same input always gives the same winner, whatever the source order.
- Score confidence
The winner's share of weight times its best weight. It is halved on conflict and raised slightly, up to 10%, when sources agree.
Trust tiers rank sources: authoritative or system of record highest, then curated or primary, then raw or enrichment. Set the tier on each view.
What comes back#
{
"premium": {
"value": 12000.0,
"winningSource": "policy-admin-view",
"winningTrustTier": "authoritative",
"conflict": true,
"confidence": "...",
"whyWon": "...",
"lineage": {
"winning_source_id": "policy-admin-view",
"contributing_source_ids": ["policy-admin-view", "benchmark-view"],
"dropped_with_reason": {"benchmark-view": "outweighed"},
"weight_by_source": {"...": "..."}
},
"candidates": [
{"sourceView": "policy-admin-view", "won": true},
{"sourceView": "benchmark-view", "won": false, "droppedReason": "outweighed"}
]
}
}
The lineage is returned with every read. Store it alongside any decision that used the value; the platform does not persist fused records.
Steward overrides#
A data steward can settle an attribute by hand, either for one record or for a whole class. An override can pin a source (mode=source) or set a value directly (mode=value). A record-level override beats a class-level one, wins with confidence 1.0, and records its author and reason.
Failure behavior#
- If a source fails to read for a class fused from two or more sources, the request fails closed rather than fusing a partial picture.
- If the fusion engine is unavailable or rejects the input, the response contains no rows and a failure code, never an unarbitrated value.
Using a fused entity in a decision#
Pass the fused values into the decision as input, and keep the lineage with the receipt:
fused = gateway.get("/v1/system/view-gateway/fuse/Policy", params={"key": "policyNumber"}).json()
policy = {attr: v["value"] for attr, v in fused["entities"][0]["attributes"].items()}
result = decide(policy) # your decision call
audit.write({
"receipt": result.receipt_hash,
"inputs": {attr: v["lineage"]["winning_source_id"] for attr, v in fused["entities"][0]["attributes"].items()},
"conflicts": [attr for attr, v in fused["entities"][0]["attributes"].items() if v["conflict"]],
})
The response field names in this example are illustrative; see the gateway's API schema for the exact shape. Binding fused entities straight into pack state, so that the receipt includes the lineage, is Planned.
Current limits
- On the live path the gateway sends each candidate's source, trust tier and value, so arbitration today is driven mainly by trust tier. Freshness, authority scopes and tolerances apply when you call the fusion engine with that metadata directly.
- Steward overrides apply when a single source contributes; with several contributing sources the fusion engine decides.
- Rules such as "always prefer source X" or "most recent wins" are expressed through trust tiers and freshness, not as named strategies.