Core Concepts

Understanding these concepts is essential for working with Pramiti effectively.

The Two-Plane Model

Pramiti operates across two independent planes that share a semantic substrate:

Read Plane (Epistom)

The read plane answers: "What does this data mean?"

When an AI agent asks "What is our monthly revenue?", the read plane:

1. Looks up "revenue" in the knowledge model and finds its verified definition (e.g., net_amount on paid invoices, excluding credits)
2. Routes the question to the appropriate handler (definition lookup, verified query match, or analytical SQL generation)
3. Validates the generated SQL against the schema before execution
4. Returns the answer with a confidence score and the semantic context used

The read plane requires Oxigraph (SPARQL triplestore) and an LLM.

Write Plane (Aegis)

The write plane answers: "Is this action valid?"

Before an agent can execute any action (update a record, send a message, call an API), the write plane:

1. Classifies the action against the semantic target model
2. Evaluates business rule constraints (JSON predicates for auto-tier, SHACL for formal-tier)
3. Calculates blast radius (what downstream systems are affected)
4. Returns a deterministic verdict: ALLOW, DENY, REWRITE, or ESCALATE
5. Records an immutable, Ed25519-signed attestation

The write plane requires only PostgreSQL. No Oxigraph, no LLM.

The Knowledge Model

Pramiti uses an internal knowledge model built on OWL 2 QL (Web Ontology Language) and SHACL (Shapes Constraint Language). Users never see these technologies directly. Instead, they work with user-facing concepts:

Auto-Discovery

The default onboarding path is automatic:

1. Connect a database
2. The platform auto-discovers the schema and samples data
3. It proposes Object Types and Link Types
4. A business user approves or refines in a visual editor (cards, not code)
5. One click to publish an MCP endpoint

Attestation

Every action validated by Aegis produces an attestation record — a cryptographically signed, append-only record of:

• What action was proposed
• Which constraints were evaluated
• What verdict was returned (and why)
• Who (or what agent) proposed the action
• When the decision was made

Attestation records are stored in an append-only PostgreSQL table protected by a database trigger that prevents updates and deletes. Each record is signed with Ed25519. This provides a tamper-evident audit trail suitable for regulatory requirements including EU AI Act compliance.

Fail-Closed Design

Pramiti follows a fail-closed security model:

• If the policy engine cannot evaluate a constraint, the default verdict is DENY
• If the LLM is unavailable, queries return "I cannot answer" rather than guessing
• If drift detection finds schema changes, confidence scores degrade and agents see warnings
• If attestation signing fails, the action is not permitted to proceed

This principle — assume breach — means the system is designed for the case where the LLM has been compromised via prompt injection. Enforcement is external to the model, deterministic, and operates at the action layer.

Semantic Safety Invariant (SI-1)

A critical safety invariant governs the boundary between reads and writes:

Auto-resolved entities are read-only. Writes require steward-confirmed resolution.

When the platform auto-discovers and maps database entities (tables, columns) to Object Types, those mappings are considered "auto-resolved." An agent can query them (read plane) but cannot use them for write operations until a human data steward has explicitly confirmed the mapping. This prevents agents from acting on potentially incorrect semantic mappings.

Confidence Scoring

Every query response includes a confidence score that reflects:

• Whether the concepts used have verified definitions
• Whether the query matches a verified query pattern
• Whether any schema drift has been detected since the knowledge model was last updated
• Whether any ambiguity was resolved (e.g., "revenue" could mean gross or net)

When confidence is low, the response includes the reason and suggests actions (e.g., "The 'revenue' definition may be stale — last schema scan detected a new column gross_revenue").