Use Cases

Use Cases

These are scenarios, written to show how the pieces fit. They are drawn from the reference programs and examples in the repository, not from named customers. Each one names the IGL feature doing the work so you can go straight to it.

A compliance team lets an assistant prepare regulatory filings

A Texas oil and gas operator has quarterly filings with a state regulator. A compliance lead wants an assistant to assemble the packet from internal records and the regulator's forms, and to tell her what is missing. She does not want it to file anything, and she wants to be able to show the regulator exactly where every number came from.

How it runs: her key is bound to her identity, with consent for regulatory-filing. The assistant calls whoami, then list_obligations and sees two attested deadlines and one proposed one, clearly marked. It asks POST /research for the missing fields; the answer cites the facts and evidence it used and nothing else, because the service dropped anything it could not cite. The workflow's last step is human_approval, and the run parks there until she has reviewed it. Today that approval is recorded by the tenant's administrator; an operation for approving and resuming a parked run from the API is on the roadmap. The receipt for every step is in the audit chain, and the regulator can be handed the explain output for any of them.

Features: purposes and obligations, governed intelligence with citations, human_approval steps, receipts. The runtime version of this story is the worked example in docs/SPEC.md.

An incident responder is stopped from doing the one thing nobody authorized

A DFIR coordinator's identity graph has grants for drafting reports, reading briefings, submitting requests and logging activity. It has also observed, five times, the action "restore production systems", because it happened in past incidents under someone else's authority. An assistant acting for him drafts the incident report without trouble. When the next statement tries to restore production systems, the runtime refuses it during authorization with IGL_FOOTPRINT_DENIED, before any model is called.

Features: the granted versus observed layers, footprint graphs, refusal before execution. This is programs/jordan-avery-dfir-footprint.igl, and you can run it in two minutes from Quickstart: the Runtime.

A partner gets a key that cannot see what it should not see

A company shares identity data with a scheduling partner. The partner needs names, roles and organizations, nothing else. The company issues the partner a key scoped to igl.read, and the identities it shares carry consent only for directory-lookup, so a projection under any other purpose fails the consent gate. Every projection the partner requests passes through the four gates; credentials, obligations and facilities are withheld and counted. If the partner's application ever asks for more, the explain output shows the refusal and the reason, and the request is in the audit chain with the partner's identity on it.

Features: purpose profiles, scoped keys, explain, audit. See Purposes and Projections.

A bank's assistant answers only from records it is allowed to cite

A wealth management assistant is asked about a client's holdings and obligations. Through IGL it can only see the slice of the client its purpose permits, and it can only answer from records in that slice. Its answer carries citation tags for each claim and a receipt whose evidenceIds list what it relied on. When it is asked something the records cannot support, the service answers 422 and the assistant says so instead of improvising. Every answer and every refusal is an audit event.

Features: governed intelligence, uncited_answer and empty_context refusals, receipts with evidence. The pattern generalizes to any regulated advice: the model is never the source of truth, the records are.

A product team ships an agent and can prove what it did

A team registers an agent with a declared purpose and scopes, and a policy that escalates any action touching obligations to a manager. The agent runs hundreds of times a day. Most runs are allow and complete; a few hit escalate, park as awaiting_approval, and fire an approvalRequired webhook to the team's queue. When a customer asks what the agent did on their account last Tuesday, support pulls the runs, the decisions and the receipts in one query against the audit chain.

Features: agents, policies, runs, webhooks, audit search. See Policies, Agents and Workflows.

A founder launches and watches it land

The site is live, the API is live, the console is live. On launch morning the console shows the hosts up, the referrers from the post, the sandbox signups arriving, the Contact Sales inquiries with company size and timeline, and the threads where people are talking about it. The first qualified inquiry is contacted before lunch, from the console, with notes. The second week's question, which features are people actually calling, is answered from projections served and runs per tenant.

Features: the Operator Console. This one is not hypothetical; it is how this project is run.

Your scenario

If you are weighing IGL for a situation not listed here, the fastest way to find out is the sandbox: Quickstart: the API gets you a tenant in one call, and the explain endpoint will tell you, for your own data and purposes, exactly what an application or an assistant would receive. For a conversation about a production deployment, the Contact Sales form on id-me.ai lands in the console the same day.