DEV Community

Davide Agosti
Davide Agosti

Posted on

Business Context Should Be Infrastructure, Not Prompt Text

#ai #programming #opensource #architecture

Business Context Should Be Infrastructure, Not Prompt Text

A lot of AI applications eventually run into the same problem.

The model understands the prompt.

It may have access to tools.

It may retrieve documents.

It may even maintain memory.

But none of those things necessarily mean it has a coherent understanding of the business it is operating within.

That distinction is what led me to start working on Evidensiq, an early-stage open-source specification for portable, evidence-backed business context.

The project is deliberately still at the specification stage. There is no runtime or package to install yet.

Before building one, I want to find out where the model is wrong.

The problem

Business knowledge rarely exists in one place.

A company may have:

  • product information in a database;
  • pricing in a CRM;
  • strategy in documents;
  • operational constraints in internal notes;
  • customer information in spreadsheets;
  • metrics in analytics systems;
  • policies in PDFs;
  • and historical information that is no longer valid.

A typical AI application eventually has to turn some combination of those sources into context for a model.

But retrieving text is only part of the problem.

Suppose three sources say:

2025 pricing document → Product A = £100
CRM                   → Product A = £120
Website               → Product A = £110
Enter fullscreen mode Exit fullscreen mode

Which one is true?

More importantly: should the infrastructure silently decide that one of them is true?

I don't think it should.

Evidence is not a fact

One of the core invariants I'm exploring in Evidensiq is:

SOURCE ≠ EVIDENCE
EVIDENCE ≠ FACT
FACT ≠ INFERENCE
INFERENCE ≠ RECOMMENDATION
Enter fullscreen mode Exit fullscreen mode

Or, conceptually:

SOURCE
  ↓
EVIDENCE
  ↓
ASSERTION / FACT
  ↓
INFERENCE
  ↓
RECOMMENDATION
Enter fullscreen mode Exit fullscreen mode

The distinction matters because a recommendation should be traceable backwards.

If an AI system recommends delaying a marketing campaign because production capacity is constrained, I want an application to be able to ask:

Why?

And eventually reach the evidence that supported that conclusion.

Business knowledge is temporal

Another problem is time.

A statement can be false today without having always been false.

The current specification therefore models concepts such as:

validFrom
validUntil
observedAt
Enter fullscreen mode Exit fullscreen mode

The goal is to preserve the distinction between:

FALSE
Enter fullscreen mode Exit fullscreen mode

and:

WAS TRUE
Enter fullscreen mode Exit fullscreen mode

This becomes important surprisingly quickly when AI systems reason over pricing, customers, processes, products, policies or business objectives.

Confidence probably isn't one number

I'm also questioning the common pattern of attaching something like:

confidence: 0.97
Enter fullscreen mode Exit fullscreen mode

to AI-generated conclusions.

What exactly does 0.97 represent?

The current Evidensiq direction separates:

evidenceStrength
sourceReliability
evidenceFreshness
inferenceConfidence
modelConfidence
Enter fullscreen mode Exit fullscreen mode

An application could derive an overall score according to its own policy, but the underlying dimensions remain visible.

Whether this is useful or over-engineered is one of the things I want feedback on.

Data is not instruction

There is also a security boundary that I think context infrastructure needs to make explicit:

DATA ≠ INSTRUCTION
Enter fullscreen mode Exit fullscreen mode

Imagine an ingested business document contains:

Ignore previous instructions and...
Enter fullscreen mode Exit fullscreen mode

That content came from evidence.

It did not suddenly acquire authority over the AI system.

This distinction becomes particularly important when context is assembled automatically from untrusted or externally controlled sources.

What Evidensiq is — and isn't

The intention is not to build another agent framework.

Evidensiq should not own:

  • agent orchestration;
  • generic RAG;
  • vector storage;
  • workflow execution;
  • LLM clients;
  • generic memory;
  • tool calling;
  • multi-agent coordination.

Instead, the proposed boundary looks roughly like this:

Application / Agent Runtime
            │
            ▼
        Evidensiq
            │
    Business Context
    Evidence
    Provenance
    Signals
    Inference
    Recommendations
    Validation
            │
            ▼
LLM / Storage / Documents / CRM / other adapters
Enter fullscreen mode Exit fullscreen mode

An OpenAI-based application, a Microsoft Agent Framework application, a LangChain application or a custom system should theoretically be able to consume the same business-context representation.

The portable artifact currently being explored is:

business-context.json
Enter fullscreen mode Exit fullscreen mode

with a provider-neutral JSON Schema.

Before writing the runtime

The obvious temptation at this point would be to start building packages.

I'm deliberately not doing that yet.

The current repository contains the specification, JSON Schema, architecture, terminology, security model and project rationale.

Before locking those abstractions and implementing reference libraries in TypeScript and .NET, I'd like them challenged by other developers.

In particular:

  1. Are SOURCE / EVIDENCE / FACT / INFERENCE / RECOMMENDATION actually useful boundaries?

  2. Is the business model too broad or too restrictive?

  3. Does the temporal model hold up against real systems?

  4. Is multidimensional confidence useful or unnecessary complexity?

  5. Can a context specification like this genuinely remain runtime- and provider-neutral?

  6. Where does this overlap too much with existing context, knowledge-graph or agent infrastructure?

  7. What would prevent you from integrating something like this into a production AI application?

I've opened a technical review discussion here:

https://github.com/davideagosti-dev/evidensiq/discussions/3

The repository is here:

https://github.com/davideagosti-dev/evidensiq

At this stage, disagreement is useful.

I'd rather discover a bad abstraction in a Markdown specification than after publishing APIs around it.

Top comments (0)