RAG systems can retrieve relevant content from contracts, policies, procedures, and other corporate documents.
While working with clients, we have encountered processes that also require the system to determine which document has priority, which version applies, which rule was valid during a given period, and how conflicts between sources should be resolved.
These requirements call for an architecture that combines semantic search with structured management of sources and rules.
Relevance and priority
A semantic search system ranks content according to its similarity to the user’s request.
The priority of a source depends on organisational, contractual, and temporal criteria.
A document may be highly relevant to a question while containing an expired rule, referring to a different business function, or having already been replaced by a later version.
Semantic ranking helps identify relevant content. Determining which provisions apply requires additional information about the sources and the relationships between them.
Contracts, policies, and related documents
A corporate repository may include a main contract, several annexes, subsequent amendments, general policies, procedures for individual business functions, and communications introducing temporary exceptions.
The system described here must recognise the relationships between these documents.
Relevant attributes include the source type, version, effective date, validity period, organisational scope, approval status, and any documents that have been amended or replaced.
These attributes provide the basis for determining which provisions apply to the case under review.
A possible architecture
The core components required to build the system are document AI, language models, semantic search, and deterministic components.
The pipeline starts with the ingestion of corporate documents and ends with a proposed outcome that can be reviewed by a person.
The following sections describe the main components of the system at a conceptual level.
1. Source ingestion
Documents may come from document management systems, shared folders, business applications, databases, record management systems, email accounts, and contract repositories.
Each item must retain a link to the original file and to the system from which it was retrieved.
Version management begins at this stage. A new file should not automatically overwrite the previous one, as an older version may still be required for historical checks.
2. Document parsing
Documents are converted into a representation that the system can process.
The parser identifies titles, sections, clauses, annexes, tables, and references to other sources.
Document structure contributes to the interpretation of the content. A provision contained in a section dedicated to exceptions has a different scope from a general clause. A table may define different conditions for different categories. An annex may amend only selected parts of the main document.
3. Metadata extraction
The system associates each document with information such as its source type, issuing entity, version, publication date, effective date, expiry date, geographical and organisational scope, approval status, and relationships with other sources.
Language models can support this phase, especially when the information is contained in unstructured documents.
An authorised user may review the most relevant metadata before the document enters the knowledge base.
4. Rule extraction
The provisions contained in the documents are converted into a structured representation.
A rule may describe the conditions under which it applies, the expected behaviour, the parties involved, any exceptions, its validity period, and its organisational scope. It must also retain a reference to the original source and include information about its extraction and approval status.
The extracted rule remains linked to the document and to the section from which it was derived, allowing users to verify the original content directly.
This link is also useful when a new version of the document is ingested. The system can identify which structured rules require further review.
5. Rule resolution engine
The rule resolution engine is the core of the system. It receives a given input, selects the applicable provisions, and manages any conflicts between them.
The criteria depend on the organisation and the process being modelled. They may include source priority, temporal validity, the specificity of a provision, organisational scope, approval status, and the relationship between a main document and its annexes.
A later version may replace an earlier one. A specific provision may apply within a narrower scope than a general policy. An exception may apply when certain conditions are met. An annex may amend selected clauses while leaving the others unchanged.
These criteria must be explicit, configurable, and verifiable. Their execution can be handled by deterministic components, while language models support the interpretation and structuring of the sources.
6. Outcome generation
The system produces a proposed outcome based on the rules considered applicable.
The result must identify the sources and versions considered, the rules applied, the provisions excluded, the conflicts detected, and the criteria used to resolve them.
The explanation allows an authorised user to reconstruct the process followed by the system. Each conclusion remains linked to the documents and structured rules that produced it.
Cases involving incomplete information, unresolved conflicts, or low-confidence extractions can be flagged for a more thorough manual review.
7. Human review
More sensitive processes may include a review stage before the outcome is confirmed.
The user can approve the proposal, correct metadata, amend a rule, add a missing source, identify a relationship between documents, or introduce an exception.
Each intervention is recorded together with the user who made it, the date, the previous state, and the updated state. The system logic can then be updated while preserving the history of changes.
Version management
Contracts, policies, and procedures change over time.
The system must retain the relevant versions, their validity periods, the relationships between documents, and the rules extracted from each version.
The same principle applies to outcomes. A previous assessment must remain linked to the documents, rules, and resolution criteria available when it was produced.
This structure allows the organisation to reconstruct the documentation that applied on a specific date and understand why a particular result was generated.
Auditability
Auditability is a central design criterion for this architecture.
For each process, the system must record the documents available, the versions selected, the metadata used, the applicable rules, the conflicts identified, the resolution criteria executed, and any subsequent human interventions.
This traceability supports error analysis, system maintenance, internal controls, and the progressive formalisation of corporate rules.
The role of language models
Language models can support document classification, metadata extraction, clause identification, structured rule generation, the detection of potential conflicts, and the production of explanations for users.
Components that directly affect source priority and rule applicability should use explicit logic. This division makes the process easier to verify.
The architecture may also include confidence thresholds. Extractions with an adequate confidence level can follow the standard workflow, while uncertain or ambiguous cases are submitted to an authorised reviewer.
The role of RAG
RAG remains useful for retrieving relevant documents and passages, supporting natural-language search, presenting evidence, and generating source-grounded explanations.
The rule resolution engine handles applicability, priority, temporal validity, and conflicts between provisions.
The architecture combines document retrieval, structured representation of the knowledge base, rule execution, traceability, and human supervision.
At Estro, we design AI systems for corporate processes in which sources, rules, and outcomes must remain verifiable.