Skip to content

Core Concepts

SMEPro IOS edited this page Oct 15, 2026 · 2 revisions

Core Concepts

Everything in IGL comes back to a short list of ideas. This page defines each one in plain language first, then says exactly how the runtime and the platform enforce it. If you only read one page beyond the Home page, read this one.

The four guarantees

Identity

Plain version: you always know which person, organization or system is acting.

How it is enforced: in the language, a statement begins with ID[Actor:Role | boundary] and will not parse without it. On the platform, every API key and every token is bound to an identity record and a tenant; a key with no identity is never issued, and the actor on every receipt and audit event is that identity, not a free-text name. The first operation most callers use, GET /identities/me, answers "who am I, under this purpose", which is also what the whoami MCP tool returns to an assistant.

Boundary

Plain version: what an actor is allowed to do is declared up front and checked while the work runs. Outside the boundary, nothing happens.

How it is enforced: in the runtime, the boundary is a lattice of grants attached to the actor's graph. The static checker rejects a program that reaches outside it, and the interpreter checks again at run time. There is no warning mode. The decode bridge goes a step further for model output: it compiles the granted boundary into a per-token mask, so a model cannot even emit a value the boundary does not cover. On the platform, the boundary is the combination of scopes on the credential, the purpose profile on the request, and the policies the tenant has defined; policy evaluation fails closed, and deny beats everything else.

Intent

Plain version: the reason for an action travels with it and is on the record.

How it is enforced: Intent[...] is a required clause of every statement. The platform's equivalent is the purpose profile on a projection and the reason and outcome fields on recorded interactions. An assistant that used a projection records what it did with it (completed, refused, proceeded_on_truncated, proceeded_on_empty or escalated) through POST /audit/interactions, and that record joins the same audit chain as everything else.

Trace

Plain version: every step is written down as it happens, and the record cannot be changed afterwards without being noticed.

How it is enforced: the runtime journal is a hash chain; each entry's hash includes the previous entry's hash, so changing one changes all that follow, and a replay refuses to load an altered chain. Receipts are signed with Ed25519 and carry the digest of the runtime build that produced them. On the platform, each tenant has its own append-only audit chain in the database, with triggers that reject updates and deletes, and GET /audit/events returns entries with their chain hashes so a client can re-verify the sequence.

Authority

Plain version: being seen doing something is not the same as being allowed to do it.

Where authority comes from

How it is enforced: knowledge enters a graph on one of three layers. A granted entry is signed by a registered grantor and is authority. An observed: governing entry came from a deterministic tool and can be promoted by a human. An observed: proposed entry came from a model and can never become authority on its own. When a trace mixes layers, the weakest link governs the whole trace. The platform mirrors this with seed, proposed and certified on facts, evidence and relationships, and attested or proposed on obligations; only certified edges appear in projections, and only attested obligations are confirmed dates.

Purpose and projection

Plain version: an application never gets "the identity". It gets the slice of the identity that its stated purpose justifies, after consent and jurisdiction are checked, with a receipt.

How it is enforced: a purpose profile lists the node types it permits and a sensitivity ceiling. Every node passes four gates in a fixed order: purpose, sensitivity, consent, jurisdiction. The response reports what was admitted, what was withheld by type, and whether the result was truncated by budget. Purposes and Projections has the full table.

Receipt

Plain version: a signed note from the system saying who asked, what was decided, which policies were consulted, and a fingerprint of exactly what was returned.

How it is enforced: receipts are signed with the service's Ed25519 key, whose public half is published at auth.id-me.ai/.well-known/jwks.json. Anyone can verify one without calling the service. Governance Receipts and Audit shows the format and the verification code.

Attestation

Plain version: some things need a human. The system can prepare a filing; a person files it.

How it is enforced: a statement that produces a filing must carry IOS.Attest(Signer=..., Role=...), and the attestation has to arrive as an input signed by a registered person's key. A program cannot claim a human approval by naming a signer. Attestations in a trace are classed as ai (nobody signed), service (the running service's key) or human (a registered person signed this exact statement). On the platform, agent and workflow runs carry approval states, and a policy decision of escalate parks a run as awaiting_approval until a person acts.

Convergence

Plain version: an AI system that feeds its own guesses back in as facts gets more confident and less correct. IGL stops that.

How it is enforced: unanchored inference loses force each time it is reused (confidence decay), there is a cap on how many derivations deep an inference may travel, and an inference without a pinned model is rejected by the static checker. These three rules are what make the recursive loop convergent instead of self-amplifying; they are invariant I7 in the specification.

Where each concept lives in the code

Concept Runtime Platform
Identity src/graph.js, ID[...] clause identities, api_keys tables; GET /identities/me
Boundary grant lattice, src/check.js, src/bridge.js scopes, purpose profiles, POST /policies/evaluate
Intent Intent[...] clause purpose on projections, POST /audit/interactions
Trace src/store.js hash chain, Merkle proofs per-tenant audit_events chain, GET /audit/events
Authority granted / observed layers, src/sign.js seed / proposed / certified, POST /authority/evaluate
Projection footprint fold in src/graph.js platform/api/src/lib/projection.js, the four gates
Receipt signed trace and head receipts, src/sign.js platform/api/src/lib/audit.js, GET /audit/receipts/{id}
Subject controls journal tombstones and reuse decay platform/api/src/lib/subject.js: pause, forget, reset, export (contract 0.3)

The mapping between runtime terms and platform terms is written down once, in docs/PLATFORM.md.

Clone this wiki locally