Three useful stores can produce one unsafe answer
A commercial lending analyst asks an assistant, “Which facilities connected to North Quay Components need action before the ownership change closes?” The question appears suitable for a knowledge graph. It asks about connections. It also appears suitable for vector search because the evidence sits in facility letters, credit papers and correspondence. It finally appears suitable for a relational query because open conditions, facility status and customer identifiers are current operational state.
Put everything into a graph and the assistant may traverse an elegant but stale projection. Put everything into a vector index and it may retrieve a persuasive paragraph without the live case status. Put everything into relational tables and it may answer exact joins while missing a covenant expressed only in a scanned amendment. The mistake is not choosing the “wrong database” in the abstract. It is asking one representation to provide semantics it was not designed or governed to provide.
A banking agent needs a representation contract before it needs a retrieval product. The contract classifies each proposition by query shape, update rate, consistency need, authority, temporal meaning and evidence form. The architecture can then assign documentary similarity to search, authoritative mutable state to transactional systems, and bounded relationship traversal to a graph or relational projection. The final evidence packet joins results under explicit identifiers and times. It does not let one store silently become the source of truth for another.
This paper develops that method through a composite institution called “Harbour Bank.” The bank, customer, records, timings and acceptance thresholds are fictional. The architecture draws on public technical standards, research and product documentation. No deployment outcome or client measurement is claimed.
Begin with propositions, not technologies
The North Quay question contains several propositions that age and fail differently. The customer identity must resolve to the correct legal party. The ownership-change event must be current. The set of related obligors depends on explicit legal and economic relationships. Facility status comes from a book of record. Conditions and covenants may live in documents. “Need action” is not stored anywhere; it is a derived assessment against approved rules and evidence.
Breaking a question into propositions makes the storage choice less fashionable and more testable. Each proposition receives an owner, a read model, a time basis and an admissible evidence class. The assistant is allowed to combine them only after the join keys and snapshots are recorded.
| Proposition | Expected authority | Query shape | Change pattern | Unsafe shortcut |
|---|---|---|---|---|
| Canonical party identity | Customer master or approved party service | Exact lookup and alias resolution | Controlled corrections | Infer identity from a similar company name |
| Current facility status | Lending book of record | Keyed read with status filters | Event-driven and material | Use status described in the latest indexed memo |
| Beneficial-ownership relationship | Approved KYC or party relationship service | Bounded traversal with effective dates | Event-driven, sometimes contested | Treat a graph-extracted mention as a legal relationship |
| Covenant wording | Executed facility and amendments | Lexical, semantic and layout-aware retrieval | Low frequency, versioned | Copy a clause from a similar customer agreement |
| Open action | Workflow case system | Current relational state | Frequent transitions | Derive completion from an email sentence |
| Governing rule | Policy registry | Applicability lookup plus exact evidence | Versioned releases | Rank a superseded policy highly because it is semantically close |
| Action recommendation | No single store | Controlled rule and evidence synthesis | Recomputed for the request | Persist model prose as authoritative case state |
This decomposition also clarifies terms that are often blurred:
- Relational state means structured facts whose integrity depends on keys, constraints, transactions and controlled updates. It is not synonymous with “anything in SQL.”
- Vector search means candidate retrieval by proximity in an embedding space, usually combined with filters and other ranking signals. Similarity is not identity, truth or authority.
- Graph traversal means following typed relationships between identified nodes. A graph database can execute it, but so can recursive relational queries for bounded workloads.
- GraphRAG means a family of retrieval-augmented approaches that construct or use graph structure to select and summarise context. It is not a general replacement for operational databases.
- Knowledge graph means an organised set of entities and relationships with an explicit data model or semantics. It may contain asserted, inferred and extracted edges, which must not be treated as equivalent.
The W3C RDF 1.1 concepts specification defines a graph-based data model using triples, while SPARQL 1.1 specifies query semantics over RDF datasets. These standards make graph meaning precise. They do not establish that a relation extracted by a language model is correct, current or authorised for a credit decision.
Representation is a claim about semantics, not a storage format. A JSON document in a vector index can carry exact identifiers. A relational table can represent a graph. A property graph can hold transactional state. The decision should turn on the guarantees used by the workload, not on the shape of the marketing diagram.
The six tests in the representation contract
Harbour Bank assigns every proposed data use six tests. The tests are evaluated for the proposition, not for the application as a whole. A single agent request can therefore produce several storage plans.
The identity test asks whether the query needs an exact party, facility, account, policy or document version. Similarity can generate candidates, but a controlled resolver must select the identifier. The temporal test distinguishes facts valid in the business world from records visible to the system at a particular transaction time. “Owner on 30 June” differs from “owner recorded on 30 June.”
The update test identifies the event that makes a representation stale and the path that invalidates it. The consistency test describes which combinations of reads must agree. A facility status and its open action may need the same case snapshot. Documentary retrieval may tolerate a short index lag if the response is explicitly marked incomplete and no decision is executed.
The authority test names the system or governed document allowed to support the proposition. The evidence-form test names what must reach the reviewer: a row receipt, relationship path, page region, exact clause or source version. A natural-language summary alone is rarely enough for a consequential banking assertion.
| Test | Question for the architect | Typical release evidence | Stop condition |
|---|---|---|---|
| Identity | Can two plausible entities match the request? | Resolver test set, stable IDs and ambiguity behaviour | Unconfirmed candidate controls the read |
| Time | Is the fact current, historical or known-as-of? | Valid-time and transaction-time fixtures | One timestamp is used for several meanings |
| Update | What event changes or revokes it? | Change-data capture trace and reconciliation | No bounded invalidation path exists |
| Consistency | Which reads must form one coherent view? | Concurrency and snapshot tests | Cross-store join can mix incompatible states |
| Authority | Which owner may attest this proposition? | Data contract and ownership approval | Derived index is called the source of truth |
| Evidence | Can a reviewer open and locate support? | Source ID, version, path or page offset | Only generated prose survives |
The six tests prevent a common architecture failure: selecting a graph because the question contains relationships, then discovering that the edges need transactional corrections, historical reconstruction, privacy filtering and evidential provenance. Those needs may still support a graph. They simply require a graph whose data and operations satisfy the contract.
Relational state is for invariants and controlled change
Operational case state has rules that should survive every model response. A facility cannot be both closed and awaiting first drawdown under the same lifecycle definition. An action cannot be completed before it was opened. A case must reference an existing party. A status transition may require an authorised actor, a reason and a prior state. These are integrity constraints, not retrieval preferences.
Relational databases are strong when a workload depends on exact keys, uniqueness, referential integrity, transactions and declarative predicates. PostgreSQL’s documentation explains multiversion concurrency control and the behaviour of transaction isolation levels. Google’s original Spanner publication describes an architecture for externally consistent distributed transactions. Neither source says that every bank state problem needs one product. Both illustrate why concurrency and time semantics must be chosen, tested and made visible.
For Harbour Bank, the party, facility, case and action records remain in governed transactional services. An assistant reads through purpose-scoped APIs. It does not write tables directly. A recommendation becomes a draft record with a separate type and owner; it does not overwrite an approved status.
The state machine also establishes retrieval meaning. “Open action” is a query over defined states, not a language interpretation of comments. “Approval” is an event with an authorised principal. A graph projection can expose links from facility to actions for traversal, but the transactional service owns whether an action is open.
Relational state is not automatically safe. Weak schemas can store untyped blobs. Long-running read replicas can lag. Application code can bypass constraints. Distributed joins can mix snapshots. The contract therefore records the consistency level, read endpoint and as-of token used for a decision packet. If two services cannot offer a shared snapshot, the assembler records their individual versions and checks whether the difference is material.
Use a transaction when a false combination of individually valid facts can change the decision. If a facility closes while its exception case is read, the packet should either reflect the before state or the after state, not an accidental mixture.
Vector search is a candidate generator, not a fact table
Executed agreements, policy manuals, committee papers, correspondence and scanned amendments contain language that cannot be reduced to a stable set of columns. Exact lexical search finds clause numbers and product codes. Dense retrieval finds paraphrases and conceptually related passages. A hybrid system can fuse them and rerank candidates.
Approximate nearest-neighbour indices trade exactness for efficient candidate search. The HNSW paper describes a graph-based approximate search method. Cloud services expose related capabilities through Azure AI Search vector search, Amazon OpenSearch Service k-NN and Vertex AI Vector Search. Their filtering, indexing, update and consistency semantics differ. A bank should certify the adapter it uses rather than infer equivalence from the term “vector.”
An embedding represents statistical features useful for ranking. It does not preserve a transaction boundary, prove that a clause is executed, or distinguish a current source from a retired one unless metadata and filtering enforce that distinction. Even then, the filter is only as good as the metadata pipeline.
Harbour Bank uses search for a narrow task: find candidate source passages that may support or contradict a named proposition. Each chunk carries a stable document ID, version, page or section offsets, document status, legal entity, customer scope where relevant, confidentiality label and extraction version. The search index never attests that a document is in force. The policy registry or source system supplies that status.
The final packet records the ranked list before and after admission. This distinguishes retrieval failure from filtering failure. If the executed amendment was absent from the candidate list, improve search or parsing. If it was retrieved and rejected because its customer ID was wrong, improve metadata or resolution. If it entered context but the draft ignored it, improve evidence assembly or generation. One “RAG accuracy” score hides those causes.
External benchmarks help test general retrieval behaviour. BEIR reports heterogeneous results across datasets and retrieval methods. Its lesson for the architecture is not a universal winner. It is that performance varies with the corpus and information need. Harbour Bank needs internal slices for identifiers, rare exceptions, tables, version conflicts and multi-document questions.
GraphRAG solves a particular retrieval problem
The term GraphRAG now covers several designs. Some extract entities and relations, build communities, summarise them and use those summaries for broad questions. Some traverse an existing enterprise knowledge graph. Some expand vector results through document-to-entity edges. Some use a graph only during indexing. These systems do not share one consistency or evidence model.
Microsoft Research’s From Local to Global: A Graph RAG Approach to Query-Focused Summarization studies a method that creates an entity knowledge graph and community summaries from a corpus, then uses those structures for global questions over large text collections. Microsoft publishes an open GraphRAG repository and project documentation. That work provides a useful, inspectable reference. It does not claim that extracted graph edges should replace a bank’s party, facility or entitlement records.
GraphRAG is most attractive when the question requires corpus-wide thematic synthesis or multi-hop discovery that isolated chunks miss. It can reveal clusters of concerns across many credit papers, map recurring operational dependencies, or retrieve documents connected through named concepts. It becomes dangerous when extracted relations are silently promoted into operational or legal facts.
The derived graph needs its own evidence status. An edge such as North Quay Components -> supplied_to -> East Port Motors might be extracted from a meeting note. That is a claim observed in a source, not a verified commercial dependency. Another edge such as Party 4182 -> guarantees -> Facility 7721 may come from an approved relationship service and carry a stronger authority. Storing both edges in one graph without type, origin and confidence invites an unsafe traversal.
| Edge class | Example | Authority | Permitted use | Required display |
|---|---|---|---|---|
| Authoritative state | Party is obligor for facility | Governed lending or party service | Scope and exact relationship query | Source service, effective interval |
| Document assertion | Memo states supplier dependency | Versioned source document | Discovery and evidence candidate | Quoted span and document status |
| Model extraction | Extractor proposes control relation | Derived processing artefact | Candidate generation only | Extraction version and confidence |
| Human-adjudicated relation | Analyst confirms same beneficial owner | Approved workflow record | Defined case purposes | Actor, evidence and approval time |
| Inference | Shared address suggests possible link | Rule or model output | Investigation lead only | Rule, inputs and “unverified” status |
| Community membership | Entities co-occur in corpus cluster | Graph algorithm output | Global summarisation | Build version and no factual implication |
A graph edge is not an evidential grade. Its type and provenance determine what a downstream agent may say.
A property graph does not remove the need for a ledger
A graph database makes relationship queries expressive. A path such as customer to owner to director to related borrower is natural to state and inspect. A property graph can attach effective dates, source IDs and confidence to nodes and edges. It can also index labels and attributes. None of that automatically establishes transaction authority or bitemporal history.
Harbour Bank distinguishes an authoritative relationship service from a retrieval graph. The relationship service owns a limited set of adjudicated edge types with lifecycle and approval rules. Its implementation could be relational, graph-native or both. The retrieval graph joins authoritative edges with document-derived nodes for discovery. It is a projection with a declared lag and is never the sole basis for changing an account or facility.
Google Cloud documents Spanner Graph as graph capabilities integrated with Spanner data, illustrating one route to graph and relational access over governed data. Google’s Zanzibar paper describes relationship-based authorisation at large scale, showing that graphs can support high-consequence access decisions when the relation model, consistency tokens and service contract are explicit. These examples do not imply that a document-extracted graph should be used as an entitlement graph.
The ledger remains necessary because corrections matter. Suppose a director link was entered with the wrong effective date and used in a related-party review. The institution needs the original assertion, correction, approval and downstream cases that depended on it. Overwriting one graph property loses that chain. Append-only events or bitemporal rows can preserve it, while a graph projection serves current and historical traversal.
Graph engines also make unbounded traversals easy to request. A five-hop expansion through addresses, directors and transactions can pull unrelated people into a context packet. The compiler should constrain edge types, direction, depth, valid time, purpose and node classes. It should reject a traversal whose estimated set or sensitivity exceeds the workflow’s allowance.
One question, three read plans
Harbour Bank’s compiler turns the North Quay request into three plans. The state plan reads the current ownership-change case, facilities and actions under one bounded consistency token. The relationship plan traverses approved party and facility edges as of the closing date. The documentary plan retrieves executed agreements, amendments and the applicable procedure within the resulting facility scope.
The compiler does not issue all three requests at once. It needs the canonical party and case first because those IDs constrain the graph and document scopes. It may read relationships before documents because the related facility set determines which agreements are eligible. It can parallelise reads only where the dependency graph permits it.
The plan returns typed results:
| Result type | Required fields | Freshness rule | Failure behaviour |
|---|---|---|---|
StateFact |
proposition, value, service, record version, as-of token | Recheck on material case event | Mark packet stale or rebuild |
RelationshipPath |
node IDs, typed edges, source, effective interval | Match decision effective time | Remove path if any edge is ineligible |
DocumentSpan |
document and version IDs, page/offset, status, extraction build | Match required policy/document validity | Do not substitute an unversioned copy |
DerivedAssertion |
method, inputs, confidence, permitted use | Recompute when any dependency changes | Cannot satisfy authoritative evidence slot alone |
Contradiction |
propositions, competing evidence and reason class | Preserve until adjudicated | Prevent definitive wording |
Unknown |
required proposition and search coverage | Re-evaluate after missing source recovers | Route or abstain according to workflow |
The assembler checks whether all required propositions have eligible support. It does not flatten state rows, graph paths and document spans into indistinguishable text. Their roles survive into the prompt and reviewer view. If the model says an ownership link is confirmed but the path is derived from a memo extraction, the output validator rejects the evidence role mismatch.
Consistency is a question about decisions
“Strong consistency” and “eventual consistency” are too coarse for this architecture. The useful question is which stale or mixed observations could change the decision or its scope. A three-minute lag in a community summary may be acceptable for thematic research. A three-minute lag in a restriction or facility closure may not be acceptable for an operational recommendation.
Harbour Bank defines consistency groups. Party identity, facility status and the ownership-change case form the scope group. Those reads must be mutually compatible. Executed documents form an evidence group with immutable versions and a current document-status read. Derived graph summaries form a discovery group and may be rebuilt asynchronously because they cannot author decisive propositions.
A packet has an expiry condition, not merely a clock-based time to live. A change to case status, party relationships, document status, policy applicability or analyst entitlement invalidates relevant parts. Some events can cause a targeted refresh. Others require rebuilding the whole scope because the eligible resource set has changed.
If the graph projection is behind its source, the plan can fall back to an exact source-service query for narrow paths. It must not silently proceed and label the projection current. If the source cannot answer within the workflow latency, the assistant presents the incompleteness and routes the case. Availability does not override evidence semantics.
Bitemporal meaning prevents historical fiction
North Quay’s ownership changes on 1 August, but the approved record arrives on 3 August. An analyst reconstructing the 2 August decision needs two views. Valid time asks when the relationship applied in the business domain. Transaction time asks when Harbour Bank recorded it. A graph that stores only effective_from may later make the 2 August packet look as though the bank already knew the change.
The authoritative relationship ledger retains both intervals. Projections include them. A query for “what was true on 2 August using everything known now” differs from “what the system could have known at 15:00 on 2 August.” Model-risk review and complaint investigation often need the latter.
Document status has the same issue. An amendment may be signed on one day, ingested the next and verified later. The system should not retroactively claim that the signed clause was available to an earlier reviewer. The W3C PROV data model supplies a general vocabulary for entities, activities and agents in provenance. Harbour Bank uses compatible ideas but adds bank-specific document, approval and temporal rules.
The workload-to-store matrix
The matrix is a design starting point, not a procurement score. “Primary” means the representation is normally responsible for the stated read semantics. “Secondary” means it can project, index or assist. Every row still needs the six contract tests.
| Workload | Relational state | Authoritative graph | Derived GraphRAG | Vector or hybrid search | Reason |
|---|---|---|---|---|---|
| Exact current case status | Primary | Secondary projection | No | No | Transaction and lifecycle invariants dominate |
| Current typed ownership path | Relational implementation possible | Primary when traversal is material | No | No | Adjudicated edges and effective time dominate |
| Find covenant paraphrase in executed documents | Metadata/status support | Scope support | Expansion possible | Primary candidate generator | Language variation and source offsets dominate |
| Corpus-wide themes across credit reviews | Aggregate facts | Entity anchors | Primary discovery aid | Secondary local evidence | Global synthesis across documents dominates |
| Entitlement decision | Policy data support | Primary only if certified for authority | Never | Never | Explicit, tested relationship semantics required |
| Workflow write or approval | Primary through governed API | Projection after event | Never | Never | Authorised transition and audit record dominate |
| “Why are these parties connected?” | Source rows for edge receipts | Primary traversal | Discovery for asserted links | Documents supporting each edge | Path plus original evidence required |
| Historical “known at the time” review | Bitemporal ledger | Temporal projection | Rebuild by historical corpus | Versioned index or exact source access | Transaction time and immutable dependencies dominate |
| Similar-case discovery | Exact filters and labels | Relationship features | Cluster or neighbourhood aid | Primary ranking tool | Similarity is useful but non-authoritative |
| Policy applicability | Structured registry | Dependency representation | No | Retrieve governing text after selection | Deterministic scope and version selection dominate |
The matrix often leads to fewer technologies than expected. A bounded three-level relationship query over modest authoritative tables may not justify a separate graph engine. A graph-native service becomes stronger when traversal depth, path explanation, heterogeneous edge types and update volume make recursive relational logic hard to govern or scale. GraphRAG becomes stronger when global questions over a large documentary corpus are common and users understand that summaries are derived.
Select the smallest set of representations that can meet the contracts without semantic impersonation. Adding a graph should remove a demonstrated failure or complexity, not decorate the architecture.
A composite walkthrough: north quay’s ownership change
The analyst is assigned to case OC-8841 for party P-10428. Her question is submitted with purpose ownership_change_credit_review. The agent service carries its own identity and a delegation limited to the case. The compiler confirms that the analyst may access commercial credit evidence for this legal entity but may not access separate financial-crime investigation material.
First, the party resolver finds two similarly named businesses. The case already references P-10428, so the compiler does not let vector similarity choose. It displays the registered name and entity for confirmation. The case service returns status evidence_pending, proposed closing date, linked facilities and a consistency token.
Second, the relationship service traverses only approved edge types: direct owner, beneficial owner, guarantor, obligor and facility. It uses the closing date as valid time and the packet build time as transaction time. An extracted shares_address_with edge exists in the retrieval graph, but the workflow does not permit that edge to expand credit scope. It may appear later as an unverified investigation lead only to an authorised user.
Third, the compiler searches within the admitted facilities and parties. Exact search finds a covenant number. Dense search finds an amendment whose wording refers to “change in control” rather than “ownership change.” The source-status service confirms that the amendment is executed and current. A board minute retrieved through GraphRAG mentions a future group guarantee, but the minute is a proposal and cannot prove that the guarantee exists.
The evidence contract requires: current facility status, current ownership path, the change-of-control clauses, evidence of any lender consent, and the approval route. Four slots are satisfied. No approved consent is found. The system says that no admissible consent evidence was found in the searched sources as of the retrieval time. It does not say consent does not exist.
The model drafts a facility-by-facility assessment. Each sentence cites a typed item. It can state that facility F-19 contains a named clause and that the approved ownership path triggers review under the applicable policy. It cannot state that the bank must accelerate the facility, that a suspicious relationship exists, or that the ownership record is legally conclusive. Those conclusions fall outside the assistant’s authority and may require legal, credit or financial-crime judgement.
The analyst opens the executed amendment at the cited page, checks the state receipts and sends the assessment through the approved credit workflow. An authorised officer makes any decision. The officer’s action is written to the case service; the event later updates graph projections and invalidates related context caches.
Evaluation, assurance and counterevidence
Authority and privacy boundaries stay outside retrieval scores
A result can be perfectly relevant and impermissible. The bank’s relationship graph may contain financial-crime edges, employee relationships, whistleblowing restrictions or information barriers. A traversal that begins with an authorised customer can cross into a protected resource in one hop. Depth limits alone do not protect it.
NIST SP 800-162 describes attribute-based access control using subject, object, action and environment attributes. Harbour Bank applies that principle to each resource and edge. The graph adapter receives a compiled predicate containing principal, delegation, purpose, case, entity, permitted edge types, sensitivity labels and time. The vector adapter receives the same resource scope expressed in its certified filter grammar. A result is checked again before content reaches the model.
The architecture follows four non-negotiable boundaries:
- The model cannot broaden entity scope, add edge types or remove filters.
- A derived graph cannot grant access to a source document.
- A user interface cannot reveal that a denied node, investigation or document exists.
- Read authority does not imply authority to update a case, approve credit or file a regulatory report.
Graph and vector services also generate operational data. Query text, node IDs, retrieved snippets, embeddings and traces can contain personal or confidential information. Logs use pseudonymous identifiers where possible, content logging is disabled by default, and access follows the same purpose boundary. Diagnostic samples enter a separate governed workflow with approval and retention.
Security trimming after a broad traversal is not a privacy architecture. Candidate generation, caches, logs and model input must all remain inside the authorised set.
Failure modes differ by representation
Architecture review should ask how each representation fails, how the failure becomes visible and which component may compensate. Redundancy is not useful if two stores inherit the same defective source or metadata.
| Failure mode | Likely representation | Observable symptom | Required response |
|---|---|---|---|
| Stale status in indexed memo | Vector search | Plausible but retired state cited | Require live state read and document-status admission |
| Extracted edge treated as verified | Derived graph | Unsupported relationship enters scope | Separate edge classes and deny authority to extraction |
| Projection lag after revocation | Graph projection | Removed relation remains traversable | Consistency token, lag monitor and source fallback |
| Entity collision | All | Evidence from namesake party joins packet | Stable IDs, confirmation and negative identity tests |
| Mixed transaction snapshots | Relational services | Impossible combination of case and facility states | Snapshot contract or explicit version compatibility check |
| Approximate-search miss | Vector index | Decisive clause absent despite correct scope | Candidate-recall tests, lexical path and exact source lookup |
| Community-summary distortion | GraphRAG | Theme presented as source fact | Open originals; summary cannot satisfy decisive slot |
| Deleted source remains in cache | Search or graph cache | Revoked content appears after deletion | Event invalidation, cache lineage and erasure test |
| Unbounded traversal | Graph | Excessive or sensitive neighbourhood | Edge allowlist, cost guard and cardinality stop |
| Broken source offsets after reparse | Vector index | Citation opens wrong page region | Immutable extraction version and citation migration tests |
Graph extraction can compound mistakes. One mistaken entity merge creates many wrong paths. Community summarisation can repeat the error at higher levels. Vector systems fail more locally but can systematically miss rare terminology or tables. Relational systems can preserve wrong data with excellent consistency. The representation cannot repair an ungoverned assertion.
The safest fallback is often “not established.” Cross-store disagreement becomes a first-class contradiction. The system does not vote among stores because their authority differs. A current book-of-record status outranks a memo describing the same facility. An executed amendment may override a generic product guide for that contract. The evidence schema carries those precedence rules.
Evaluation starts with store-specific claims
Harbour Bank does not run one end-to-end accuracy test and declare the architecture ready. It creates claims for each boundary, then an integrated decision benchmark. Thresholds below illustrate a test design and are not reported performance.
The relational claim is that state reads respect lifecycle, snapshot and authorisation rules. Tests generate concurrent transitions, permission changes and retries. The graph claim is that allowed traversals return complete authoritative paths within declared depth while excluding derived or denied edges. The search claim is that required document spans enter the candidate set across exact, semantic, table and exception slices. The assembly claim is that only eligible items satisfy proposition slots.
| Evaluation slice | Primary measure | Illustrative acceptance statement | Why it matters |
|---|---|---|---|
| Party resolution | Precision at confirmed identity and ambiguity recall | No automatic selection in high-risk ambiguous fixtures | Prevents cross-customer evidence joins |
| State snapshot | Invariant violations and incompatible version rate | Zero prohibited state combinations in concurrency suite | Protects operational meaning |
| Authoritative paths | Path precision and conditional recall by edge type | Every returned edge has eligible authority and time | Prevents extracted relations from becoming facts |
| Denied traversal | Forbidden node or edge admission | Zero admissions in adversarial entitlement fixtures | Tests privacy boundary, not ranking |
| Documentary candidates | Proposition recall before and after filters | Required evidence retained across query slices | Separates retrieval from filter loss |
| Source location | Page or offset correctness | Reviewer opens the cited support directly | Makes evidence usable |
| Packet coverage | Required propositions supported, contradicted or unknown | No required slot silently omitted | Tests decision usefulness |
| Temporal replay | Historical packet reconstruction | Same dependency versions reproduce the admitted set | Supports assurance and challenge |
| Event invalidation | Stale packet survival after material change | Relevant packets blocked within the stated control bound | Tests operational control |
| Human usefulness | Correctly resolved cases, review time and override reason | Qualitative and quantitative review by consequence tier | Avoids optimising only technical metrics |
Adversarial fixtures matter. Create two parties with near-identical names, a revoked graph edge, a superseded agreement, a relation visible only to another purpose, a decisive clause embedded in a table and a community summary that overstates a source. Evaluate the traces, not only the final prose. A final answer can be accidentally correct after an unauthorised read.
Independent validation should rebuild expected sets from source systems rather than from the same projections under test. Reviewers inspect a sample of paths, negative cases, temporal boundaries and correction events. Model changes trigger generation tests; graph or index changes trigger retrieval tests; source-contract changes can trigger the full suite.
Latency and cost follow the dependency graph
A polyglot plan adds calls, but one large search does not make the underlying dependencies disappear. The architecture can control latency by resolving scope early, parallelising independent reads, bounding graph expansions and caching only non-sensitive, versioned artefacts whose reuse is permitted.
The cost model separates indexing, online query, model input and assurance. GraphRAG can incur substantial extraction and summarisation work when a corpus changes. Vector indices incur embedding and rebuild costs. Transactional services incur availability and consistency costs. A decision should compare these against the question mix and failure cost, not only token reduction.
Harbour Bank measures p50, p95 and tail latency at each stage, but it also measures incomplete-fast responses. A packet that returns quickly without the amendment is not a latency success. The service-level objective includes evidence completeness and declared source availability.
Performance optimisations must preserve semantics. A cached relationship path includes its principal, purpose, edge allowlist, valid time, dependency versions and invalidation events. A cached GraphRAG community summary is a derived corpus artefact, never customer-scoped authority. Cross-user reuse is prohibited unless the key and content classification prove equivalence. The companion context-cache architecture treats those rules in depth.
Procurement through semantic test cases
Product comparisons often count supported features: vector search, graph queries, filters, transactions, encryption and managed scaling. Harbour Bank instead sends vendors and internal platform teams semantic fixtures. Can the system represent two time axes? Does a missing filter attribute fail closed? Can it distinguish an authoritative edge from an extraction? Can a historical graph query be tied to source versions? Does approximate search apply filters before or after candidate generation? Can a source deletion invalidate every derived view?
The answers are recorded in an adapter capability matrix. Unsupported semantics are not filled with prompt instructions. A decision type may use only adapters certified for its contract.
| Capability question | Evidence requested | Unacceptable answer |
|---|---|---|
| How are authoritative and derived edges separated? | Schema, policy test and result trace | “The model sees a confidence score” |
| How is historical knowledge reconstructed? | Valid-time and transaction-time query fixture | Current graph plus log search |
| Where do vector filters apply? | Documented execution plus conditional recall test | Filtered citations after broad retrieval |
| How are source corrections propagated? | Event path, lag bound and reconciliation | Nightly rebuild with no failure state |
| Can reads share a consistency marker? | Token or version compatibility contract | “The services are usually current” |
| What reaches provider diagnostics? | Data-flow and logging configuration evidence | Only a general privacy statement |
| Can citations survive reprocessing? | Immutable source/version and offset mapping | Page number generated from current parse only |
| How does a timeout fail? | Typed incomplete result and workflow behaviour | Return whatever results arrived |
Managed services remain useful. The point is to place them behind a bank-owned representation and evidence contract. Portability then means preserving query and control semantics, not pretending every backend implements the same operations.
Implementation in four controlled increments
The first increment uses relational state plus hybrid document retrieval for one decision type. It proves identity, scope, source versioning and evidence assembly. No graph is needed until a measured query or maintenance problem requires it.
The second increment adds a governed relationship read model for a small set of approved edge types. A recursive relational implementation may be sufficient. Teams test path semantics, temporal boundaries and access filters before considering a separate graph engine.
The third increment adds document-derived graph expansion for discovery. Every derived node and edge carries source, extractor, confidence and permitted use. It cannot widen customer scope or satisfy authoritative proposition slots. Reviewers can open the original span.
The fourth increment evaluates corpus-level GraphRAG summaries for named research questions, such as recurring control concerns across de-identified review papers. It runs in a separate purpose and data boundary from live customer decision support. Community outputs are evaluated for coverage, attribution, stability and contradiction loss.
Each increment has an exit decision. If hybrid search already answers the material workload and relationship queries remain shallow, stop. If graph maintenance introduces more unresolved identity errors than retrieval benefit, stop. If community summaries cannot retain source position or materially improve global questions, stop. A mature architecture includes the option not to add a component.
Stable identifiers are the join architecture
Polyglot systems are often drawn as boxes connected by arrows. The harder design sits inside the join. A vector result names a document and perhaps a customer. A graph path names parties and facilities. A state API returns case and facility records. If those names come from separate matching logic, the evidence assembler can create a coherent story about the wrong entity.
Harbour Bank defines a canonical identifier policy. Party, facility, case, document and policy identifiers are minted by named authorities. Projections retain the authority namespace and source version. Human-readable names are display attributes, not joins. Historical mergers and identifier changes create explicit alias records with effective intervals; they do not overwrite old receipts.
Document identity needs more care than a file path. The same executed amendment can be stored in several repositories, rendered to a new PDF, extracted twice and copied into a case bundle. The evidence system distinguishes the business document identity from the binary object identity, version identity and extraction identity. Deduplication may group copies while citations remain anchored to the admitted version and extraction.
Graph entity resolution follows the same discipline. A proposed node created from text is assigned a derived identifier and may link to canonical candidates. It does not inherit the canonical ID until an approved resolver confirms the match. This prevents a language model from merging two directors because they share a name and employer. Candidate links remain visible to the discovery process without contaminating authoritative paths.
| Identifier | Minting authority | May be inferred? | Join rule | Correction behaviour |
|---|---|---|---|---|
| Party ID | Customer or party master | Candidate only | Exact namespace plus ID | Append alias or merge event with review |
| Facility ID | Lending book of record | No | Exact entity and facility ID | Preserve old version and correction receipt |
| Case ID | Workflow service | No | Exact case type and ID | Case links can change through controlled event |
| Business document ID | Document registry | Candidate during ingestion | Confirmed registry mapping | Retain prior mapping and duplicate relationship |
| Object hash | Content pipeline | Computed exactly | Cryptographic hash and algorithm | New binary creates new object identity |
| Extraction ID | Parsing service | No | Object hash plus parser build | New extraction does not erase old offsets |
| Derived graph node | Graph build | Yes, explicitly derived | Never an authoritative join by itself | Rebuild or adjudicate with lineage |
Identifier quality has its own evaluation set. Include transliteration, punctuation, former names, reused trading names, joint facilities, branch codes and identifiers that changed after a migration. Measure false merges separately from missed matches because a false merge can cross a customer boundary. Require confirmation for consequence tiers where ambiguity remains.
A cross-store join is an authorisation event. The assembler must prove that records refer to the same admitted resource, not merely that their labels resemble each other.
Implementation and operating detail
Change propagation is part of correctness
Every projection creates a period during which two representations disagree. That period may be milliseconds or days. It may be bounded and observable, or it may be unknown. Calling the system “near real time” does not establish whether a revoked relationship, corrected document status or closed facility can survive long enough to affect a decision.
The event contract names the source event, ordering key, consumer, idempotency rule, expected propagation bound and reconciliation method. Critical revocations use a direct invalidation path as well as the ordinary indexing stream. A vector chunk, graph edge, community summary and cache entry all retain dependency IDs so the invalidator can find affected artefacts.
An outbox or equivalent atomic publication pattern prevents a source change from committing without its event. Consumers are idempotent because retries are expected. Ordering is defined per entity or document, not assumed across the whole estate. A late update carries the source version; consumers reject it if a newer version is already applied.
Reconciliation is not a nightly comfort check. It compares source and projection counts, versions and selected hashes by risk tier. It can identify a graph edge missing after an update, a search document whose status differs from the registry, or a cache entry whose dependency was deleted. Material mismatches stop affected decision types rather than merely opening a low-priority ticket.
| Change | Required propagation | Interim behaviour | Reconciliation question |
|---|---|---|---|
| Access revocation | Immediate deny path plus projection update | Deny from source policy even if index lags | Can any adapter still return the resource? |
| Facility closure | Within decision freshness contract | Re-read source before final packet | Does any open-action projection remain? |
| Document supersession | Status update before new version is promoted | Old version may be historical evidence only | Are current queries still admitting it? |
| Relationship correction | Edge tombstone and replacement with temporal receipt | Source lookup or route if path is material | Do historical and current paths both reconcile? |
| Parser correction | New extraction and citation migration map | Existing packets keep old extraction receipt | Do new citations open the corrected span? |
| Entity merge or split | Governed identity event and dependent review | Block automatic joins in affected scope | Which prior packets used the old mapping? |
| GraphRAG rebuild | New immutable graph and summary release | Queries stay on prior approved release | Are source coverage and attribution preserved? |
GraphRAG rebuilds deserve release semantics. Re-extraction can rename entities, split nodes and change communities even when the source corpus is unchanged. Harbour Bank publishes an immutable graph release with its source set, extractor, prompts where used, model version, clustering parameters and summary version. It compares new and old releases on entity stability, edge attribution, community drift and evaluation questions before promotion.
Vector migrations need similar care. Changing the embedding model or chunker can alter candidate recall. The team builds a parallel index, runs the frozen benchmark, examines regressions by slice and promotes through an alias only after approval. A rollback must restore metadata, filters and source-status behaviour as well as vectors.
Evidence precedence is not a voting scheme
When stores disagree, a naive agent may count sources or prefer whichever retrieval score is highest. Harbour Bank instead defines precedence by proposition. The book of record owns current facility status. An executed contract owns its wording. A policy registry selects the governing policy version. A graph path can establish an approved relationship only when its edges come from the assigned relationship authority.
Precedence does not mean suppressing contradictions. A customer letter may dispute a party record. A credit paper may refer to an amendment that the registry marks unexecuted. The packet presents the conflict and its evidence roles. It does not allow a lower-authority source to overwrite state, but it can require human investigation.
Harbour Bank encodes precedence in the decision schema rather than a universal hierarchy. A signed facility amendment may govern a contract term, while a policy defines an internal approval route. Neither universally outranks the other because they answer different propositions. A supervisory publication may inform control design without deciding a customer case. A relationship asserted in a customer document may be evidence to review, not a master-data update.
Output validation checks every consequential claim against this schema. If the model cites a community summary for current facility status, the claim fails even when the summary happens to be correct. If it cites a current state row for contract wording, the claim fails because the state row cannot evidence the clause. This makes evidence role a machine-checkable property rather than an editorial preference.
Graph quality needs more than edge precision
Graph teams often report entity precision, relation precision and coverage. These are necessary but incomplete for a decision-support graph. The material unit is a path used for a permitted proposition. Two individually correct edges can form an inapplicable path if their effective intervals do not overlap. An accurate edge can still be unauthorised for the purpose. A community can be stable while omitting a rare but decisive source.
Harbour Bank evaluates authoritative and derived graphs separately. The authoritative graph is tested for temporal path correctness, source receipts, entitlement behaviour, correction handling and bounded completeness for named edge types. The derived graph is tested for extraction attribution, entity resolution, source coverage, calibration and whether expansion improves evidence retrieval without widening scope.
| Graph measure | Definition | Required slice | Failure it reveals |
|---|---|---|---|
| Edge precision by class | Adjudicated correct edges divided by reviewed returned edges | Authoritative, asserted, extracted and inferred | Evidence grades being mixed |
| Temporal path validity | Paths whose edge intervals overlap at query time | Closing dates and historical boundaries | Individually valid edges forming impossible path |
| Path authority rate | Paths supported only by permitted edge classes | Purpose and consequence tier | Discovery edges authoring decisions |
| Source attribution completeness | Derived edges with openable source span | Parser and media type | Untraceable extraction |
| Expansion contribution | Required evidence found because of graph expansion | Query taxonomy | Graph adds cost without retrieval value |
| Scope amplification | Additional parties or documents introduced per seed | Edge type and depth | Privacy and cardinality risk |
| Correction convergence | Time and completeness of edge repair across projections | Material correction class | Stale relation survival |
| Community stability | Change under controlled rebuilds | Source and model version | Summary volatility and regression risk |
| Contradiction retention | Conflicting assertions preserved through summarisation | Rare exceptions and disputed relations | Smooth narrative hiding material conflict |
Global summaries need question-level evaluation. Reviewers identify required themes and counterevidence in a fixed corpus. The system is scored for coverage, attribution, contradiction preservation and unsupported generalisation. A fluent summary with high thematic overlap can still fail if it turns tentative document claims into established facts.
Graph cardinality is also a control measure. For each workflow, the team establishes expected node and document expansion distributions. A sudden increase may signal a malformed edge, entity merge or missing scope predicate. The compiler stops before retrieving content when the planned neighbourhood exceeds its bound and offers a narrower, reviewable query.
When a single representation is enough
Polyglot architecture has operational cost. It adds data contracts, projections, monitoring, access adapters and incident paths. Harbour Bank therefore uses a counter-test: can one governed representation meet the full workload contract without disguising derived data as authority?
A relational design may be enough when relationships are shallow, edge types are stable and query volume is modest. Recursive common-table expressions or materialised paths can serve facility and guarantor traversal while retaining the transactional ledger. Search remains necessary only if the decision uses unstructured documents.
A search-led design may be enough for research over a static, public or uniformly authorised document collection where no live customer state is joined. Metadata and immutable source versions can provide scope. GraphRAG may improve global synthesis, but a vector and lexical baseline should establish whether the benefit is material.
A graph-native design may be enough for a bounded relationship service if the engine supplies the required transactions, temporal model, access controls and audit evidence. “Graph-native” does not remove relational principles such as uniqueness, lifecycle and controlled writes. It changes the physical and query model.
| Situation | Simplest credible design | Trigger for another representation |
|---|---|---|
| Current case dashboard with exact joins | Transactional relational service | Material deep path queries or documentary evidence |
| Clause search over approved, versioned contracts | Hybrid lexical and vector search with status service | Multi-hop entity discovery that improves measured recall |
| Shallow guarantor relationships | Relational adjacency table and recursive query | Path complexity, explainability or scale exceeds tested bounds |
| Global themes over a fixed research corpus | Lexical/vector baseline, then GraphRAG experiment | Graph summaries improve attributed coverage on fixed tests |
| Highly connected adjudicated party network | Governed graph service plus event ledger | Transactional workflows still need controlled state service |
| One-off investigation | Analyst tools with recorded queries | Repeatable decision use requiring formal contracts |
The decision record includes the rejected options. It may say a graph engine was not selected because paths were limited to two hops and a relational implementation passed the latency and explanation tests. It may say GraphRAG was deferred because baseline hybrid retrieval already met global-question coverage, while extraction introduced unstable entity merges. Such records demonstrate judgement better than a maximal architecture.
Operating ownership mirrors evidence ownership
No single “AI platform team” can own the full architecture. Data owners define authoritative propositions and correction paths. Workflow owners define decision types and human authority. Search engineers own candidate generation. Graph engineers own traversal and projection semantics. Security owns access-control patterns and negative tests. Model-risk and validation functions challenge the claims appropriate to the institution’s framework.
The release record maps each failure to an accountable owner. An incorrect party merge does not become a prompt-engineering ticket. A stale policy status does not become a vector-model retraining request. A missing clause may belong to document ingestion, retrieval or evidence assembly depending on the trace.
Production monitoring follows the same layers. State monitors watch invalid transitions and snapshot failures. Graph monitors watch lag, scope amplification, edge-class mix and correction convergence. Search monitors watch source coverage, conditional recall, filter errors and citation validity. The packet layer watches evidence coverage, contradictions, stale dependencies and authority-role violations.
Incidents preserve the original packet and projection versions. Repairs are appended. If an entity merge affected earlier decisions, lineage identifies the packets that used it and the workflow owner decides which require review. The system does not silently regenerate old answers and erase the evidence of what happened.
A release card with falsifiable claims
Before enabling North Quay-like cases, the team publishes a release card for the decision type. It names the approved propositions, stores, edge classes, document collections, freshness bounds, historical limitations, test fixtures, unresolved risks and human authority. It states what the system has not been tested to do.
One claim might be: “For the ownership-change workflow, canonical party and facility state is read from named services; only adjudicated owner, obligor, guarantor and facility edges may expand scope; executed-document search is limited to the resulting IDs; derived graph edges may propose discovery queries but cannot satisfy an authoritative evidence slot.” That claim is narrow enough to test.
The release card does not say the system “understands relationships,” is “fully compliant,” or “eliminates hallucination.” It records conditional evidence. If a new edge type, entity, jurisdiction, media class or graph release enters scope, the corresponding tests rerun. If a service cannot provide transaction-time history, the historical replay limitation remains visible.
Harbour Bank’s illustrative readiness conditions include:
- no forbidden node, edge or document admission across the certified negative suite;
- no automatic party resolution for high-consequence ambiguous fixtures;
- correct temporal paths across every effective-date boundary case;
- required document evidence located with openable source offsets;
- every decisive claim supported by an eligible evidence role;
- projection lag and invalidation behaviour within the stated control bounds;
- successful independent reperformance of selected packets from dependency receipts;
- defined human escalation for missing, contradictory or contested evidence.
These conditions do not prove legal compliance or correct credit outcomes. They establish that the representation design behaved as specified for the tested scope. Business, legal, privacy, security and risk owners still decide whether that scope is appropriate.
Keep the model above the read plan, not inside the trust root
Language models can help decompose the analyst’s wording, generate bounded search variants, classify candidate passages and draft an explanation. Those are valuable tasks. None requires the model to decide which customer records exist, which relationship edge grants scope, which document version governs or which state transition is authorised.
Harbour Bank exposes typed tools. resolve_party_candidates returns masked, permitted candidates and requires an explicit selection when ambiguity is material. read_case_snapshot accepts a canonical case ID and returns typed fields plus a version. traverse_relationships accepts only an approved edge vocabulary, bounded depth and effective time. search_documents requires a compiler-issued scope token. The model cannot invent a tool parameter outside the schemas, and every call is reauthorised by the receiving service.
The model may suggest that “change in control” is a useful synonym for “ownership change.” The search planner validates that term and executes it inside the existing facility and document scope. The model may suggest following a supplier_of edge, but the compiler rejects it because the credit workflow does not permit that edge to expand scope. Rejection becomes a structured event, not text that the model can negotiate.
Output is validated at the proposition level. The draft carries claim IDs, values, evidence item IDs and a requested speech act such as describe, compare, recommend_for_review or request_approval. The validator checks that each evidence item is eligible for the proposition and that the speech act is allowed. A high model probability does not compensate for a missing source receipt.
There is no need to retain hidden reasoning text to assure the result. The useful record is the typed request, read plan, tool calls, candidate and admission outcomes, evidence ledger, model and prompt release, structured claims, validation results and human action. This record shows what the model saw and what the controls decided without treating private reasoning as evidence.
| Model contribution | Allowed input | Deterministic boundary | Stored assurance artefact |
|---|---|---|---|
| Intent proposal | User wording and permitted workflow catalogue | Approved decision type and ambiguity rule | Candidate intents and selected type |
| Query expansion | Admitted terms and proposition | Scope cannot change | Search variants and planner version |
| Passage classification | Admitted candidate text | Document status and authority remain external | Classification with source ID |
| Relation extraction | Versioned source span | Edge remains derived until adjudicated | Extractor version, span and confidence |
| Drafting | Typed evidence ledger | Claim schema, evidence role and authority | Structured claims and validation result |
| Explanation | Validated claims and receipts | No new facts or broader conclusion | Display text linked to claim IDs |
This division also supports model replacement. A new model can be evaluated against the same typed tools, plan traces and claim validators. It may improve language or evidence use without changing the authoritative state and relationship services. If the model begins calling tools differently, trajectory tests reveal the change before release.
A detailed negative trace
One North Quay fixture is designed to look helpful while violating three boundaries. A relationship manager’s note says that North Quay “appears controlled by” a director of another borrower. The extractor creates a tentative controlled_by edge. The other borrower has a financial-crime investigation that the credit analyst cannot access. A retired credit paper contains a strong change-of-control clause and is highly similar to the query.
The model proposes a graph expansion from North Quay through the tentative edge. The compiler checks the edge class and denies scope expansion because extracted assertions are not approved ownership relations. It does not reveal the protected borrower or investigation. The document search still runs inside the two admitted facilities. It retrieves the retired credit paper as a candidate because the wording is close, but the source-status check marks it inapplicable. Its text never enters the model context.
The live agreement is a poor scan whose clause was missed by the standard parser. Lexical and vector retrieval both fail. A document-coverage rule notices that an executed agreement is present but no extractable change-control section was found. The packet is marked incomplete and sent for manual document review. It does not use the retired paper as a substitute.
The expected final state is not an answer. It is a controlled unknown with the facility IDs, missing evidence class, searched collections and manual route. The test passes only if no protected identifier, tentative relationship content or retired clause reaches the model prompt, traces available to the analyst, or generated response.
This trace reveals why end-to-end answer scoring is insufficient. A model could guess that review is required and receive a positive label while the system had read a protected investigation. Conversely, an appropriate abstention might appear less “helpful” than an answer. Boundary tests must inspect intermediate sets and information flows.
Economics should include semantic maintenance
The headline costs of these representations are easy to list: database capacity, vector embeddings, graph construction, model tokens and engineering. The larger cost often sits in semantic maintenance. Teams must define identifiers, approve edge types, resolve corrections, version documents, label authority and keep evaluation fixtures current. A GraphRAG build that produces attractive summaries can still be uneconomic if every release requires extensive manual entity repair for a workload already served by hybrid search.
Harbour Bank estimates total cost by workload and control obligation. The baseline includes source onboarding, indexing, online reads, resilience, monitoring, validation, access reviews, incident response and historical reconstruction. It also estimates the cost of a wrong join or stale scope, not as an invented currency figure but as consequence tiers and required controls.
| Cost or burden | Relational state | Authoritative graph | Derived GraphRAG | Vector search |
|---|---|---|---|---|
| Initial semantic design | Schemas, invariants and APIs | Edge ontology, temporal and path rules | Extraction, resolution, communities and summaries | Chunk, metadata, embedding and ranking design |
| Change maintenance | Migrations and event contracts | Edge lifecycle and projection reconciliation | Rebuild comparison and entity repair | Re-embedding, reindexing and benchmark rerun |
| Assurance | Concurrency, transition and access tests | Path, temporal, authority and scope tests | Attribution, stability and global-question tests | Recall, filter, source and citation tests |
| Incident analysis | State and event replay | Path and correction lineage | Graph release and summary dependencies | Candidate, index and parser versions |
| Human stewardship | Data ownership and correction | Relation adjudication | Entity and extraction review | Judgement labels and document status |
| Avoided complexity | Exact facts stay out of prompts | Repeated path logic becomes explicit | Broad corpus structure becomes retrievable | Language variation becomes searchable |
The investment case should name which failure or review effort each component reduces. An authoritative graph may be justified by repeated, expensive path reconciliation across several workflows. GraphRAG may be justified by material improvement in attributed global analysis over thousands of documents. A vector service may be justified by demonstrable clause recall beyond exact search. If the evidence does not show the benefit, the component remains an experiment.
Cost controls must not change evidence semantics. Lowering vector candidate counts can remove rare clauses. Using an older graph summary can miss corrections. Reading from a cheaper stale replica can mix case states. Any optimisation is evaluated against the decision benchmark and receives its own rollback condition.
Questions an architecture committee should ask
The committee can test whether the proposal is representation-led or workload-led with direct questions. Which exact propositions will the graph author? Which edges are extracted, asserted or adjudicated? What event makes each projection stale? Which time does “as of” mean? How is a document result joined to a party without a name match? What happens when the vector result, graph path and state service disagree?
It should also ask what has been deliberately excluded. Are financial-crime relationships inaccessible to the credit purpose? Can community summaries contain customer information? Does a source deletion reach embeddings, chunks, graph nodes and caches? Can a model-generated relation ever expand the authorised scope? Which human role can approve a new edge type or evidence-precedence rule?
The final questions concern proof. Is there an adjudicated fixture for every material query shape? Can an independent reviewer rebuild a packet from receipts? Do negative tests inspect intermediate reads? Has a simpler relational or hybrid design been measured? Are vendor capabilities validated through semantic fixtures rather than documentation alone?
These questions turn architecture review into a falsifiable decision. The committee can approve one decision type with named restrictions, ask for evidence, or reject a component whose semantics are unclear. It does not need to approve “the enterprise knowledge graph” as an undifferentiated idea.
Source position: what each body of work supports
This synthesis uses sources for bounded propositions. The GraphRAG paper and implementation support a corpus-graph approach to query-focused summarisation, especially global questions. They do not support using extracted edges as banking facts. RDF, SPARQL and PROV provide formal data and provenance concepts; they do not define local credit authority. PostgreSQL and Spanner materials support discussion of transactions, concurrency and consistent reads; they do not select a bank’s database.
The HNSW paper and cloud vector documentation support approximate candidate retrieval and implementation considerations. BEIR supports the observation that retrieval effectiveness varies across datasets and methods. NIST attribute-based access-control guidance supports explicit decisions over subject, object, action and environment attributes. Zanzibar supports the feasibility of a rigorously defined relationship service with consistency semantics, not a general claim that all knowledge graphs are safe for authorisation.
| Source | Position used here | Position not attributed to it |
|---|---|---|
| Microsoft GraphRAG paper | Graph-derived communities and summaries can address global corpus questions | Extracted relations are operational facts |
| Microsoft GraphRAG code and documentation | Inspectable reference workflow and implementation concepts | Production fitness for any bank decision |
| RDF 1.1 and SPARQL 1.1 | Formal graph data and query concepts | Evidence grade or legal meaning of edges |
| W3C PROV-DM | General provenance concepts for entities, activities and agents | Complete banking evidence policy |
| PostgreSQL MVCC and transaction isolation | Concrete concurrency and isolation semantics | Universal technology recommendation |
| Spanner publication | Distributed transactional and time design example | Requirement to use Spanner |
| Zanzibar | Relationship-based authorisation with defined consistency semantics | Permission to reuse retrieval graphs for access control |
| HNSW | Approximate nearest-neighbour index method | Truth or authority from vector proximity |
| BEIR | Heterogeneous retrieval evaluation and variable performance | Bank-specific acceptance threshold |
| Azure AI Search, Amazon OpenSearch, Vertex AI Vector Search | Current vendor descriptions of vector capabilities | Semantic equivalence across products |
| Spanner Graph overview | Example of graph and relational capabilities in one managed system | Automatic authority or correct bank schema |
| NIST SP 800-162 | Attribute-based access-control concepts | A complete RAG permission implementation |
This is a technical design position, not legal advice, a product endorsement or evidence that the composite pattern has been deployed. Product behaviour and supervisory expectations should be checked for the institution, jurisdiction, service version and date of use.
The decision rule
Choose relational state when the question depends on current authoritative values, controlled transitions, exact identity and transactional invariants. Choose vector or hybrid search when the task is to find candidate language in versioned documentary evidence. Choose an authoritative graph when repeated, typed, temporally governed path queries are central and a graph representation simplifies them without weakening the ledger. Choose GraphRAG when corpus structure materially improves documentary discovery or global synthesis, and keep every derived assertion connected to its sources and evidence grade.
Most consequential banking questions need more than one of these. That does not justify a free-form join inside a prompt. The compiler should sequence reads, enforce shared scope, record time semantics, validate authority and preserve evidence roles.