Request for Feedback: Evidensiq Business Context Specification v0.1

[davideagosti-dev]

Request for Feedback: Evidensiq Business Context Specification v0.1

Evidensiq is an early-stage open-source project exploring a simple premise:

Business context should be infrastructure, not prompt text.

AI applications increasingly need access to organizational knowledge distributed across documents, operational systems, spreadsheets, CRMs, metrics, policies, and other sources.

Today, that context is often assembled directly into prompts, stored in provider-specific memory systems, or reconstructed independently by each application.

Evidensiq is exploring a different boundary: an open, provider-neutral representation of business context that applications and AI runtimes can consume without the context itself belonging to a particular model provider, agent framework, or storage technology.

The project is currently at the specification stage. There is no runtime implementation yet.

Before locking the architecture and beginning the TypeScript and .NET reference implementations, I would like to expose the v0.1 model to technical scrutiny.

The semantic model

A foundational distinction in the specification is:

SOURCE ≠ EVIDENCE
EVIDENCE ≠ FACT
FACT ≠ INFERENCE
INFERENCE ≠ RECOMMENDATION

Conceptually:

SOURCE
  ↓
EVIDENCE
  ↓
ASSERTION / FACT
  ↓
INFERENCE
  ↓
RECOMMENDATION

The purpose of these boundaries is traceability.

A recommendation should be capable of being traced back through the reasoning chain to the business evidence and ultimately to the source from which that evidence originated.

A related security invariant is:

DATA ≠ INSTRUCTION

Content originating from a business document, CRM, spreadsheet, external source, or other evidence source remains data. It must not implicitly acquire authority as a system instruction merely because an AI model processes it.

What Evidensiq owns

The intended architecture places Evidensiq between application/agent runtimes and infrastructure adapters:

Existing Agent / Application Runtime
                │
                ▼
┌───────────────────────────────────┐
│             EVIDENSIQ             │
│                                   │
│ Business Model                    │
│ Evidence / Provenance             │
│ Signals                           │
│ Inference                         │
│ Recommendations                   │
│ Validation                        │
└───────────────────────────────────┘
                │
                ▼
LLM · Storage · Vector · Documents
CRM · Other adapters

Evidensiq is deliberately not intended to become:

• an agent framework;
• a chatbot framework;
• a generic RAG framework;
• a vector database;
• a generic memory system;
• a workflow engine;
• an LLM client;
• a tool-calling framework;
• or a multi-agent orchestration system.

Existing runtimes should be able to consume Evidensiq rather than be replaced by it.

Business Context Specification v0.1

The current model begins with a deliberately small set of primitives:

Organization
Product
Service
CustomerSegment
Channel
Process
Metric
Goal
Constraint
Competitor
Evidence
Source

Analytical objects currently include:

Signal
Inference
Opportunity
Risk
Recommendation

The specification also addresses:

• provenance;
• temporal validity;
• conflicting evidence;
• source trust classification;
• multidimensional confidence;
• context projection;
• recommendation validation;
• evidence-backed evaluation.

The portable representation is currently designed around:

business-context.json

with a JSON Schema intended to remain independent of programming language and AI provider.

Temporal context

Business knowledge changes.

The current model therefore distinguishes concepts such as:

validFrom
validUntil
observedAt

A statement that is false today may still have been valid historically.

The model should be able to distinguish:

FALSE

from:

WAS TRUE

rather than silently overwriting historical context.

Conflicting evidence

Evidensiq should also avoid silently deciding which source is correct when business evidence disagrees.

For example:

2025 pricing PDF  → Product A = £100
CRM                → Product A = £120
Website            → Product A = £110

The context model should be capable of representing the conflict, its sources, observation times, and freshness rather than arbitrarily selecting one value as truth.

Confidence

Another design choice I would particularly like feedback on is confidence.

Instead of allowing an AI model to emit an opaque value such as:

confidence: 0.97

the current direction separates several concepts:

evidenceStrength
sourceReliability
evidenceFreshness
inferenceConfidence
modelConfidence

Applications may eventually derive an overall confidence according to their own policy.

Recommendation pipeline

The current conceptual pipeline is:

Evidence
   ↓
Signals
   ↓
Inference
   ↓
Candidate Recommendations
   ↓
Constraint Validation
   ↓
Evidence Validation
   ↓
Ranking
   ↓
Recommendations

Candidate recommendations may have states such as:

candidate
supported
conflicted
insufficient-evidence
stale
rejected

The intention is that an LLM may propose interpretations or recommendations, while deterministic infrastructure remains responsible for storing, linking, validating, constraining, and evaluating them.

Where I would particularly value feedback

Before the specification moves toward an architecture lock, I would appreciate technical criticism around several questions:

1. Are the SOURCE / EVIDENCE / FACT / INFERENCE / RECOMMENDATION boundaries sufficiently distinct and useful in practice?

2. Is the initial set of business primitives too small, too large, or missing something fundamental?

3. Does the temporal model provide the right foundation for business facts that change over time?

4. How should conflicting evidence be represented without prematurely introducing a large ontology or knowledge-graph platform?

5. Is multidimensional confidence useful, or does this model risk becoming unnecessarily complicated?

6. Can this specification realistically remain portable between TypeScript and .NET implementations?

7. Does the boundary between Evidensiq and existing agent/RAG/context frameworks remain clear enough?

8. What would prevent you from integrating a context specification like this into an existing AI application?

9. Which part of the current specification would you challenge first?

Critical feedback is particularly useful at this stage. The purpose of publishing v0.1 early is to identify weak abstractions before they become runtime APIs that are harder to change.

Current status

Evidensiq is currently an early specification / pre-release project.

There are no npm or NuGet packages yet, and the specification should not be considered stable.

The repository contains the current architecture, specification, terminology, JSON Schema, security model, roadmap, and public-interest rationale.

Repository:

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

Specification:

https://github.com/davideagosti-dev/evidensiq/blob/main/docs/specification/business-context-spec.md

JSON Schema:

https://github.com/davideagosti-dev/evidensiq/blob/main/specification/business-context.schema.json

Architecture:

https://github.com/davideagosti-dev/evidensiq/blob/main/docs/architecture/architecture.md

If you work on agent infrastructure, RAG/context systems, knowledge representation, developer tooling, TypeScript/.NET libraries, or production AI systems, your perspective would be especially valuable.

The next architecture phase will use this feedback as an input rather than treating v0.1 as already settled.