Source Authority and Business Meaning

An enterprise AI system needs to know which evidence may answer which business question. Finding a document with the right words is only the beginning. A travel policy, a payroll record and a manager’s email can all describe an allowance while answering different questions about policy, payment and an individual exception. Treating them as interchangeable creates confident answers that have no defensible business basis.

Source authority is the accepted right of a particular source to establish a particular fact or rule within a defined scope. Business meaning explains what that fact or rule represents: the event, population, unit, status, time and exceptions. Together they determine whether a document or data field can support the proposed AI use. Neither a familiar filename nor a senior person’s informal approval supplies the missing definitions.

This guide is for data owners, business analysts and technology leaders preparing an internal knowledge service or decision assistant. The practical objective is an inspectable source agreement before development: which sources the system may rely on, how conflicts are resolved and which questions must remain unanswered. It is one part of an enterprise data and AI readiness assessment, with particular value where Saudi organisations operate across Arabic and English records, several legal entities or changing policies.

Separate authority, provenance and evidence quality

Authority concerns the business claim a source is entitled to establish. Provenance concerns how the source or derived record came into existence. Quality concerns whether the content is sufficiently accurate, complete and usable for the intended question. These properties interact, but one does not establish the others. A perfectly traceable draft remains a draft; an authoritative policy can be badly scanned; an accurate payment entry may record an exception rather than the general rule.

The W3C PROV overview provides a useful technical basis for describing data origins, transformations and responsible actors. A provenance record helps an assessor investigate a source. The organisation must still decide what the source is authorised to mean in its own processes. This distinction prevents a lineage diagram from being mistaken for a business approval or a guarantee of truth.

Different evidence can be authoritative for different questions

Source	Potentially establishes	Does not establish by itself
Approved policy version	The stated rule for its covered population and effective period	That a particular person satisfies every condition
System transaction record	A recorded payment, request or status transition	That the recorded action complied with policy
Authorised exception record	A bounded departure approved through the relevant process	A general rule for other employees or future cases
Training presentation	An explanation prepared for a stated audience	Replacement of the governing policy
AI-generated summary	A derived interpretation to inspect against its sources	A new authoritative policy or entitlement

Record these distinctions at the claim level. Calling an entire repository “authoritative” is usually too coarse. The same repository may contain approved policies, consultation drafts, archived versions and working copies. The assessment should establish which metadata and review process distinguish them, and whether those distinctions survive export, document splitting and indexing.

A worked example: travel allowance means more than an amount

Consider a fictional employer preparing a travel-allowance assistant. Policy R3 allows SAR 220 for each eligible overnight stay. Policy R4 allows SAR 240 and takes effect on 1 July. Both policies state that the version is selected by the trip’s departure date. R4 was approved on 20 June. These invented conditions demonstrate source reasoning; they are not Saudi employment rules or an actual employer’s policy.

A trip departs on 30 June and returns on 2 July, with two eligible overnight stays. Under the example’s explicit version rule, R3 applies to the trip. Two eligible nights at SAR 220 produce SAR 440. A portal page updated on 1 July displays the new amount. An assistant that takes the latest page and multiplies SAR 240 by three calendar dates would produce SAR 720. The error combines an incorrect version choice with an incorrect measurement unit.

Cleaning the amount column would not repair that reasoning. The amount is valid in R4; the dates are valid; the documents may be searchable. What is missing is the meaning of “eligible overnight stay” and the relationship between departure date, effective date and approval date. A retrieval test should therefore ask for the governing version and the reasoning basis, not merely whether the answer contains a plausible currency amount.

Keep payment separate from entitlement. If a payroll record later shows SAR 440 paid, it supports the statement that the recorded payment was SAR 440. It does not independently prove the trip facts or absence of an authorised exception. The assistant should identify the evidence required for those separate propositions, while an authorised employee retains the final interpretation and payment decision.

Build a source authority register around claims

Begin with the questions that the proposed service will answer. “What is the allowance?” hides several tasks: explaining the general policy, identifying the applicable version, checking a case, describing a payment or requesting an exception. List those tasks separately. For each, name the evidence owner and the person empowered to settle a disputed interpretation. A repository administrator can maintain files without having authority to interpret their business effect.

The register should identify the source, stable identifier, version, approval record, effective interval, covered entities and users, language status, source owner and allowed downstream uses. Add the rule that determines which date selects a version. Record known exclusions and the destination for unresolved questions. A link alone is insufficient if the linked file can be replaced without preserving its previous contents.

Use a narrow statement of authority, such as “establishes the general domestic overnight allowance for employees of Entity A whose trip departure falls within this interval.” That is more useful than “finance source of truth.” It exposes the need for entity, trip type and departure date before the assistant can apply the rule. It also makes a future scope expansion visible rather than allowing it to happen through broader search access.

A data catalogue and lineage record can store or reference this agreement, but buying a catalogue does not settle ownership disputes. Where the business cannot identify an approved rule or an accountable interpreter, record that uncertainty as a readiness condition. Development should not manufacture authority by selecting whichever document is easiest to ingest.

Define a compact business meaning contract

For every decision-critical field or document concept, write a meaning contract that another team can apply without guessing. Include the business event, entity, unit, permissible states, time basis, source and exceptions. “Travel days” needs a definition of partial days and overnight eligibility. “Paid” needs a distinction between a payment instruction, successful settlement and an accounting posting. Similar labels can conceal materially different events.

Specify whether an empty field means unknown, not applicable, not collected or genuinely zero. Those states can produce different answers. A missing return date should not become a zero-night trip. An empty exception field should not become evidence that no exception exists unless the process reliably records all exceptions there and the relevant population is complete.

Identity also belongs in the contract. An employee number might be unique only within one entity. A trip identifier might be regenerated after cancellation. A document reference might identify a policy family rather than one approved version. Determine the keys needed to join records without silently combining people, trips or rules. Inspect examples of amendments, duplicates and reopened requests before accepting a convenient join.

When terminology differs across teams, preserve the distinction until the owners resolve it. Finance might use “travel day” for an accounting allocation while HR uses it for policy eligibility. A glossary that maps both terms to one label can erase the problem. Define the shared concept only after examining the underlying business events; otherwise keep separate concepts and explain their relationship.

Check the representation of dates and money before treating two records as equivalent. A displayed date may use a different calendar, a local business-day convention or a date-only field that has no time-zone meaning. A monetary figure may include tax, exclude deductions or represent an approved maximum rather than an amount payable. State these interpretations explicitly and retain the original value alongside any normalised representation. The conversion itself should be reviewable, with its rule and relevant context preserved.

A particularly useful exercise is to ask two independent process experts to apply the draft definition to the same unfamiliar cases. Compare their reasoning before reconciling their answers. Agreement on easy cases may conceal disagreement about an amended trip, a cancelled booking or a retrospectively recorded exception. Where experts disagree, determine whether the source is ambiguous, an essential fact is absent or their delegated responsibilities differ. The purpose is to reveal a missing business decision before that decision becomes an invisible default in software. It is not to declare one expert wrong because a model preferred the other answer.

Resolve competing sources with an explicit precedence rule

Precedence should come from documented authority and applicability. It should not be inferred from file recency, search rank, document length or language. A local addendum may override a group policy only where the organisation’s authority structure permits that departure. A signed document may govern one entity while a newer unsigned draft anticipates a future change. The assistant needs enough context to distinguish those situations.

Create a conflict record containing the disputed proposition, the source versions, their relevant passages, applicable populations and dates, the possible interpretations and the decision owner. Preserve each source before making changes. Ask the owner to state the resolution and its boundary: which cases it covers, when it begins and whether historical answers require review. A decision that merely says “use the new file” leaves the applicability problem unresolved.

Some differences are not conflicts. A policy can specify eligibility while a transaction system records what happened. A training slide can simplify a rule for beginners. A local procedure can describe an approved implementation without changing the underlying entitlement. Classifying the difference correctly avoids unnecessary escalation and prevents a summary from being given more authority than its purpose allows.

For genuine Arabic–English disagreement, use a controlled bilingual source-conflict process. Neither language should automatically win because of system defaults or the reviewer’s preference. The governing language and translation approval must be established for the particular source and question. Where this remains unresolved, a readiness decision may exclude the affected question rather than offering an unsupported answer.

Check what survives the data pipeline

A source agreement can be correct in the repository and disappear during processing. An export may omit approval status. OCR may detach a footnote from the amount it qualifies. A chunk may retain the allowance figure while losing the table heading that limits it to international travel. An index may include an archived copy without its superseded marker. These are meaning changes, even when most words are preserved.

Select a small set of deliberately difficult examples and follow them from original source to the exact material available to the model. Compare the title, qualifiers, units, effective interval, entity restrictions and source identifier. Inspect both normal and exception rows. This is a targeted transformation test; it establishes how those examples behaved, not a population-wide quality rate. Use representative quality sampling for a broader estimate.

Derived summaries need their own status. Record the source versions and transformation that produced each summary, the reviewer where applicable and the conditions that invalidate it. If an authoritative policy changes, a previously approved summary may still be unsuitable for new trips. Source withdrawal should trigger an impact check across summaries, retrieval indexes, cached answers and evaluation material rather than only deleting the visible original.

Preserving authority metadata does not grant access. The service must also enforce the user’s authorised access to the underlying evidence and any derived content. An employee may be allowed to read a general policy but not another employee’s exception record. Coordinate the source register with permissions and provenance readiness so that correct interpretation does not create inappropriate disclosure.

Use question fixtures to test business interpretation

Build a compact set of source-grounded question fixtures before selecting retrieval or prompting techniques. Each fixture should state the question, relevant case facts, governing source version, expected reasoning, acceptable uncertainty and prohibited inference. Include an answer that must be withheld when an essential fact is absent. The fixtures become a test of the proposed evidence contract rather than a test of whether the model sounds helpful.

1. Ask about the fictional trip that starts before R4 becomes effective; require identification of R3 and the departure-date rule.
2. Remove the departure date; require clarification rather than selection of the newest policy.
3. Provide the payment record alone; permit reporting the payment but not declaring entitlement correct.
4. Provide an unauthorised draft with a higher allowance; require the approved-source boundary to remain effective.
5. Introduce a local addendum whose delegation evidence is missing; require referral to its accountable owner.
6. Change the source version after a summary is created; check that the stale summary is not treated as current authority.

Review the explanation and citations as well as the final amount. Two wrong assumptions can occasionally cancel numerically and produce the correct total. That is not a reliable interpretation. Record which premise was supported, which source passage established it and whether the service appropriately asked for clarification. If the outcome depends on an undocumented business judgement, the fixture should show that dependency instead of hiding it in an expected answer.

Turn unresolved meaning into bounded remediation

A useful issue describes the missing decision, affected questions and the evidence needed to close it. “Clean policies” is too vague. “Confirm whether departure date or overnight date selects the allowance version for cross-period trips” has an identifiable owner and an observable completion condition. Closure requires an approved interpretation and updated examples, not simply moving a ticket to done.

Prioritise meaning defects by their effect on the proposed service. A missing optional description may be tolerable for an internal search pilot. Ambiguous entity scope may block answers entirely. A missing historical version may allow current guidance but prevent historical case explanation. These are different readiness boundaries; do not combine them into a single completeness percentage.

Record dependencies in the data remediation backlog. The authority decision may need to precede glossary updates, corpus selection and evaluation labels. Reversing that order can make engineers implement an assumption that later becomes expensive to undo. The backlog should also preserve unresolved historical cases rather than filling their missing values with today’s rule.

Keep authority useful when the business changes

Keep the authority decision separate from the convenience of a source interface. A searchable portal may expose a superseded copy, while the approved record resides elsewhere. Record how the selected version is verified, not merely where the team found it.

Assign a review trigger to each source family: new policy approval, entity restructuring, changed transaction semantics, revoked source access or a material translation correction. A calendar review alone can miss an urgent change between scheduled checks. Define how the owner notifies downstream users and how the technical team identifies affected derivatives. The register needs an operating process, not only a complete launch-day spreadsheet.

At handover, ask someone outside the assessment team to answer a small set of applicability questions using the register. Can they identify the responsible owner, retrieve the approved version, explain an exception and recognise when they lack enough facts? If they need undocumented help from the original analyst, the meaning contract is not yet sufficiently transferable.

A defensible readiness conclusion names the permitted questions, population, sources, versions and outstanding limitations. It may support a narrow explanatory pilot while withholding individual entitlement decisions. Bring representative approved records, one difficult conflict and the proposed user questions to a readiness assessment discussion about source authority. The first useful outcome is a shared interpretation of what the service may claim, with a practical route for resolving what it cannot yet establish.