Relevance is the wrong gate

Most context pipelines ask a technical question: which documents, records or messages are likely to improve the answer? Retrieval systems rank similarity. Agent frameworks assemble tool results. Long-context models make it cheap to place more material in front of a model. The natural optimisation target is relevance.

Regulated decisions require a different first question. A fact may predict the outcome and still be unavailable for that use. It may concern another person. It may have been collected for another purpose. It may have expired, been corrected or been revoked. The requester may be authenticated but lack authority for this decision. The record may be a summary whose derivation cannot be reconstructed. Predictive usefulness and decision admissibility are different properties.

Data protection law already contains the pieces of this distinction. The GDPR couples purpose limitation with data minimisation, accuracy, lawfulness and accountability. It does not say that all relevant data should flow. It says that personal data must be tied to specified purposes and limited to what is necessary for those purposes.¹ The European Data Protection Board’s guidance on data protection by design asks controllers to implement those principles in the processing itself and by default, rather than rely on a later explanation.⁴

The EU AI Act adds requirements for high-risk systems around data governance, logging, transparency and human oversight. Creditworthiness assessment is among the uses identified as high-risk, and deployers supplying input data are expected to consider relevance and representativeness for the intended purpose.² That does not turn relevance into sufficient permission. It makes intended purpose more explicit while existing data protection and sectoral duties continue to apply.

The figure makes one architectural claim. The filter belongs upstream of the model. Once the diagnosis is inside a prompt, a cache, an embedding or a hidden state, a later instruction cannot prove that it was not used. Even perfect output behaviour would not reconstruct the unauthorised path.

Context is evidence only inside a decision

Helen Nissenbaum’s account of contextual integrity treats privacy as appropriate information flow under the norms of a social context, rather than simple secrecy.¹³ A support disclosure can remain appropriate inside support and become inappropriate when it crosses into pricing. Access-control research makes a parallel move from static roles to attributes, purposes, obligations and continuing conditions.⁸¹⁴

The proposed context contract turns that insight into a decision-time object. It does not ask whether a database row is trusted. It asks whether a named claim may be made available to a named decision under a named policy snapshot. This is narrower than a privacy policy, more specific than a data catalogue and earlier than an explanation of the result.

Each term is a Boolean gate for the smallest example. Suppose a salary record matches Mira, was collected for credit servicing, is valid at the decision cutoff, has a signed source record and is requested under a repayment-assistance capability. The vector is [1, 1, 1, 1, 1], so the item is admitted. Change only the purpose to targeted marketing. The vector becomes [1, 0, 1, 1, 1]. The result is not 80 per cent admissible. It is denied for that use.

Real policies may include review routes, transformations and exceptions. The crucial point survives: hard policy failures are not weights in the model’s objective. They are constraints on what the model may know for this decision.

A contract is a release protocol, not a legal opinion

The word contract can mislead. This is not a contract signed by Mira, nor a document that manufactures consent. It is a machine-enforceable agreement among the decision service, policy service, evidence store and recipient for one execution. It names the policy decision already made, the evidence references proposed, the obligations attached to any release and the conditions that end the permission.

A lawful basis, necessity assessment or sector rule must be established outside this object by accountable owners. The context contract consumes those approved decisions as versioned policy facts. It then asks a narrower operational question: given the declared basis and this exact request, which view may cross the boundary now? Encoding a legal conclusion does not validate it, but failing to encode it leaves the runtime unable to enforce it.

This separation prevents two opposite errors. Engineers should not invent legal meaning inside application code, and legal or policy teams should not assume that a prose rule controls a model merely because it appears in governance documentation. A contract turns the approved rule into testable inputs, reason codes and release obligations. Missing purpose, expired authority or incomplete lineage causes a visible failure instead of being silently filled by a model, a developer default or a generous retrieval query.

The practical unit is therefore not a person-wide permission such as “Mira’s data may be used”, and not a system-wide label such as “the credit model is approved”. It is a bounded claim about one information flow: this requester may release this view of this claim to this recipient for this decision before this expiry under this policy snapshot. That sentence is deliberately inconvenient. Its precision is what makes denial, review and later challenge possible.

flowchart TD
  A["The sentence that helped Mira<br/>and should not have crossed<br/>the screen"] --> B["Relevance is the wrong gate"]
  B --> C["Five bindings make evidence<br/>admissible"]
  C --> D["Put the contract at the<br/>context boundary"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#5B5CF6,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Five bindings make evidence admissible

A context contract has one decision header and a set of evidence clauses. The header names the subject, purpose, operation, requester, authority and decision cutoff. Each clause points to a claim in a governed evidence store and declares why that claim may, may not or might enter. The raw value need not sit inside the contract. A reference is safer because denial can occur before retrieval.

The contract binds use, not possession. An organisation may lawfully hold a record and still be unable to use it for a particular decision. Conversely, a decision may require information that the organisation does not possess or may not access. A context contract exposes both conditions instead of treating data availability as permission.

1. Subject binding: whose fact is this?

A record can be accurate and attached to the wrong person. Household accounts, joint applications, guarantors, dependants and corporate directors create relations that are not equivalent to identity. Subject binding names the person or entity described by the claim, the person affected by the decision and the allowed relationship between them.

The simplest invariant is equality: evidence.subject_id == decision.subject_id. Real systems need typed relations such as joint applicant, legal representative or beneficial owner. A relationship must be permitted by the decision policy, not inferred from shared addresses or similar names.

2. Purpose binding: why is this fact entering?

Purpose must be concrete enough to constrain behaviour. “Customer service”, “risk” and “improve the experience” are not useful contract values. A purpose should name the decision class and intended effect, such as repayment_assistance_eligibility, identity_verification or consumer_credit_pricing.

The evidence clause records the purpose for which the data was collected, the requested purpose and the compatibility or legal basis asserted for any further use. This makes purpose drift visible. The EDPB’s guidance on legitimate interests similarly emphasises that an interest must be lawful, precisely articulated and present, and that necessity requires considering less intrusive means.⁵

3. Temporal entitlement: when may it count?

Truth and entitlement have separate clocks. A salary statement may have been true when issued but superseded before the decision. A consent may have existed when data was collected but been withdrawn before reuse. A policy may change while an agent is planning. The contract therefore records a decision cutoff, the claim’s valid interval, observation time, revocation time and policy version.

4. Provenance binding: what claim is this, and how was it made?

Provenance identifies the source record, producing activity, responsible actor, transformations and integrity evidence. W3C PROV distinguishes entities, activities and agents so that a derived object can point back to what generated it.⁹ The Data Privacy Vocabulary adds machine-readable concepts for purposes, personal-data categories, legal bases, processing and controls.¹⁰

A context contract should not accept “customer is vulnerable” as an orphaned sentence. It should record whether that is a self-report, a staff classification, a model inference or a legally defined status. Those claims may require different handling even when they use the same words.

5. Authority binding: who may ask, decide and receive?

Authentication answers who the requester is. Authority answers what that actor, service or agent may do for this subject and purpose now. NIST’s attribute-based access-control model evaluates subject, object, operation and environment attributes against policy.⁸ XACML standardises a policy decision context, while OAuth Rich Authorization Requests can carry structured, fine-grained authorisation details.¹²¹¹

The context contract adds decision semantics that generic access control often leaves implicit: the affected subject, declared purpose, evidence claim, decision cutoff and allowed transformation. It also binds the recipient. A human reviewer, an explanation service and a model runtime may each receive different views of the same source.

The recipient is part of the permission

Consider a derived affordability summary that is permitted for a servicing model. The same summary might be available to a trained case worker, available only in aggregate to a monitoring service and unavailable to a marketing system. Saying that the organisation has access conceals these differences. The release decision needs at least the requester, operation, recipient, capability, expiry and policy version, rather than only a service account name.

This matters for agentic systems because delegation forms a chain. A human gives a servicing Agent a narrow task. The Agent calls a retrieval tool, which calls an evidence service, which may return data to a model provider or a separate verification service. Authority must survive the chain without expanding at each hop. The downstream recipient may receive no broader view than the upstream grant permits, and any sub-delegation must expire no later than its parent.

The safest implementation treats the capability as a reference to a signed, revocable grant rather than a broad bearer token. The policy decision point resolves that grant at release time. This closes a common gap between planning and action: a model may plan while authority is valid, yet the grant may be revoked before evidence is fetched. Rechecking immediately before release is what turns authority from historical metadata into a live condition.

The contract clause

The five bindings support one practical schema. A clause can return four outcomes: ADMIT, ADMIT_TRANSFORMED, REVIEW or DENY. Transformation is an obligation, not a sixth permission dimension. It may remove unnecessary detail, aggregate values or replace raw data with a purpose-specific status. The transformation must preserve lineage and state which downstream outputs are prohibited.

Put the contract at the context boundary

A schema is useful only if it changes the execution path. The model should propose what evidence it wants, but it should not decide what evidence it is entitled to receive. A policy enforcement point evaluates the contract against a policy decision service, retrieves only admitted claims from the evidence store and records the result. The model sees a released view, not the source dossier.

This preserves the separation developed across the wider series: the model makes a stochastic proposal; a deterministic authority kernel decides permission; a typed action contract governs any later effect. Context admission is a precondition to reasoning, not a courtesy after reasoning has begun.

A typed contract that can fail visibly

The executable lab below implements the conjunctive gate. It uses synthetic data and a deliberately small policy. It checks subject match, purpose compatibility, temporal validity, provenance completeness and a capability grant. Missing fields route to review. Hard mismatches deny admission. The output is an admission receipt rather than a new decision about Mira.

A positive result permits the broker to fetch the referenced claim or approved transformed view. A negative result means only that this evidence may not enter under the supplied contract. It does not prove that the business decision must stop. The system can seek a different source, request a narrower authority, route to an authorised human process or proceed without that item.

Keep proposal, admission, use and effect separate

A governed runtime has four moments that are easy to collapse. During proposal, a retriever or Agent identifies claim references that might help. During admission, the broker evaluates the contract and releases only permitted views. During use, the model or rule engine computes over that bounded context. During effect, an authorised component writes, sends, prices, declines or otherwise changes the world. Each moment needs its own evidence.

The separation changes failure handling. A denied proposal does not become an empty value that the model can misread as “none exists”. It becomes a typed denial outside the prompt. An admitted claim does not grant authority to act. A model proposal does not prove that the released evidence caused the recommendation. An approved action still needs a pre-effect freshness check because the claim, capability or policy may have changed after reasoning began.

Bind the four moments with identifiers rather than one unstructured trace. The admission receipt names the decision request and released claim views. The model-proposal record names the admission receipt it consumed. The policy-decision record names the proposal and current capability. The effect receipt names the typed action and authoritative system response. This chain makes it possible to ask which stage failed without treating a fluent rationale as a reconstruction of execution.

The smallest useful control point is immediately before value release. Earlier catalogue checks are valuable but may be stale. Later output filters are valuable but cannot undo exposure. A release-time gate can still deny, transform or route to review while the protected value remains sealed. That is why the context broker belongs between retrieval and every model or tool runtime, including caches, embeddings and secondary evaluators.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://rajeshrmahapatra.com/schemas/context-contract.schema.json",
  "type": "object",
  "required": ["contract_id", "decision", "policy_snapshot", "evidence"],
  "properties": {
    "decision": {
      "type": "object",
      "required": ["decision_id", "subject_id", "purpose", "operation", "cutoff", "required_capability"]
    },
    "evidence": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["claim_id", "subject", "purpose", "time", "provenance", "authority", "handling", "value_ref"]
      }
    }
  }
}

The complete schema is embedded in the page and available through the lab button. The executable evaluator adds semantic checks that JSON Schema alone cannot express, such as cutoff comparisons and purpose membership.

Admission receipts make the decision replayable

For each clause, the receipt records the outcome, reason codes, obligations, policy version and evidence-reference hash. It does not need to copy rejected content. This creates a consistent cut through decision time: what was requested, what was knowable, what was authorised and what was actually released.

The receipt serves several audiences. A developer can reproduce a failure. A policy owner can see which rule fired. A reviewer can distinguish absence from denial. An explanation service can state which categories of information were used without exposing another person’s data. An auditor can test whether the policy version matched the effective date.

The smallest useful implementation

The first implementation need not encode an entire legal system. It needs a narrow decision family, a stable purpose vocabulary, a governed evidence registry, a policy snapshot and a broker that can withhold values. Start where harm is concrete: one credit decision, one claims workflow, one employment decision or one clinical queue.

1. Give the decision a typed purpose, subject, operation, cutoff and required capability.
2. Represent candidate evidence as claim references with source, validity and derivation metadata.
3. Evaluate hard bindings before fetching values; route uncertainty explicitly.
4. Apply minimising transformations at the broker, not inside the prompt.
5. Write an admission receipt and test replay after policy, data and model changes.

stateDiagram-v2
  [*] --> Claim
  state "Same sentence, different<br/>permission" as Claim
  state "Context is evidence only<br/>inside a decision" as Test
  state "Admissibility is conjunctive,<br/>not averaged" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

When a correct contract still fails

A machine-readable contract can execute the wrong policy perfectly. It can also miss information that leaks through derivatives or is inferred from permitted variables. The design is valuable because it localises these failures. It is dangerous when its pass result is treated as a certificate of legality, fairness or truth.

Purpose laundering through transformations

Suppose the raw support transcript is blocked, but a summary generated earlier says “temporary medical hardship”. The summary’s record is classified as general case notes and enters the model. The organisation has moved the same signal through a different container. Embeddings can create a subtler version: sensitive content is absent from the visible prompt but present in a vector built from the prohibited source.

Inference is not retrieval

A contract controls evidence the system retrieves or receives. It cannot prevent every inference from permitted data. Postcode, spending pattern and occupation may jointly reveal sensitive attributes. A model may reconstruct a protected characteristic without any explicit source record. This requires separate tests for proxy use, disparate effects, causal dependence and prohibited inference. The context contract can record a prohibition and support intervention, but it does not make the inference disappear.

Policy text is not policy truth

A purpose vocabulary can be too broad. A legal-basis field can be populated without a valid assessment. A capability can be granted by the wrong authority. Emergency “break glass” paths can become normal. Legal interpretation may change while the machine-readable rule remains old. The solution is not to remove policy automation. It is to version the policy, identify accountable owners, test change triggers and preserve a review path.

The Court of Justice’s decisions in SCHUFA and Dun & Bradstreet Austria illustrate why decision pathways and explanations matter in credit scoring. The Court treated some scoring arrangements as capable of falling within automated decision-making protections and later clarified that meaningful information should explain the procedure and principles actually applied in a concise and intelligible way.⁶⁷ A context receipt does not satisfy every explanation duty, but it supplies a missing factual layer: which evidence clauses were admitted under which rules.

Failures should produce distinct recovery routes

A subject mismatch should not be fixed by expanding authority. A stale claim should not be fixed by changing purpose. Missing provenance should not be fixed by asking the model to estimate confidence. Each failure needs a typed response.