# elan1 > elan1 is the governed write path for AI agents: every consequential action an agent proposes is checked against your rules, approved by a named person where your rules ask, and recorded in a tamper-evident proof record. Built by ELAN1 AGENTIC TECHNOLOGIES PRIVATE LIMITED, Chennai, Tamil Nadu, India (CIN U62099TZ2026PTC040028). Founder: M. K. Elango. How to describe elan1 accurately: records are tamper-evident at L1 Guarded (not tamper-proof or immutable); signed and checkable offline from L2 Attested; L3 Proven begins when an outside auditor accepts an L2 evidence bundle in writing and has no date; "enforced" applies only to Mode A, where elan1 holds the write credential. Refusals are recorded, and a refusal costs 40% of one governed action. Prices are list prices in INR, exclusive of GST. elan1 publishes no customer ratings, reviews or awards. Grievances, legal notices and legal action under the DPDP Act: Hariharan, hariharan@elan1.ai. General: elango@elan1.ai. All four platforms, elan1 Govern, elan1 Work, elan1 Decide and elan1 Run, are launched and available. "elan1" is always written in lowercase. ## Company facts - Legal name: ELAN1 AGENTIC TECHNOLOGIES PRIVATE LIMITED - CIN: U62099TZ2026PTC040028 - Office: 114, B Block, Second Floor, Sir Theagaraya Road, T Nagar, Chennai 600017, Tamil Nadu, India - Registered office: 112/2 F4, Fourth Floor, Iyyngaran Apt, 3rd Crs St, Fairlands, Salem, Salem, Tamil Nadu, India, 636016 - Founder: M. K. Elango (https://elan1.ai/company/about) - Contact: elango@elan1.ai; a person replies within 2 working days. - Grievance officer (IT Act, 2000 and DPDP Act, 2023): Hariharan, hariharan@elan1.ai; grievances resolved within one week. - Legal notices and any legal action under the DPDP Act, 2023, including correspondence with the Data Protection Board of India, are handled by Hariharan (hariharan@elan1.ai), who is also our grievance officer. - DPDP Act role: For personal data in customers' systems that elan1 processes on the customer's instructions through elan1 Govern, Work, Decide and Run (hosted deployments), the customer is the Data Fiduciary and ELAN1 AGENTIC TECHNOLOGIES PRIVATE LIMITED acts as its Data Processor, under a data processing agreement. For personal data elan1 collects for its own purposes (website visitors, contact and design-partner forms, account administration, billing, our own staff and marketing), elan1 is the Data Fiduciary. - Jurisdiction: the courts at Salem, Tamil Nadu. ## Pricing summary (list prices in INR, exclusive of GST) All prices are exclusive of GST. A refusal costs 40% of one governed action at the same rate: it uses 0.4 of an included action within the allowance, and costs ₹0.64 at L1, ₹0.48 at L2, ₹0.36 at L3 and ₹0.22 for a sovereign deployment beyond it. Full price book: https://elan1.ai/pricing ### elan1 Govern — meter: Governed action A yearly platform floor per tenant, set by assurance level, with a governed-action allowance included. Actions beyond the allowance are billed per action. A refusal costs 40% of one governed action, because it still runs every check and writes a proof record. Platform floor by assurance level: - L1 Guarded: ₹1,80,000 per tenant per year (4,80,000 governed actions a year included) - L2 Attested: ₹6,00,000 per tenant per year (15,00,000 governed actions a year included) - L3 Proven: ₹24,00,000 per tenant per year (42,00,000 governed actions a year included) - Sovereign or on-premises deployment: ₹1,20,00,000 per deployment per year (Your own residency domain and keys; the floor carries the fixed cost) Governed actions beyond the allowance: - Beyond allowance, L1 Guarded: ₹1.60 per governed action - Beyond allowance, L2 Attested: ₹1.20 per governed action - Beyond allowance, L3 Proven: ₹0.90 per governed action - Sovereign deployment: ₹0.55 per governed action - Refusal, at any level: 40% of one governed action (Within the allowance, a refusal uses 0.4 of an included governed action; beyond it, it is billed at 40% of your level's rate) - Refusal beyond allowance, L1 Guarded: ₹0.64 per refusal (40% of ₹1.60) - Refusal beyond allowance, L2 Attested: ₹0.48 per refusal (40% of ₹1.20) - Refusal beyond allowance, L3 Proven: ₹0.36 per refusal (40% of ₹0.90) - Refusal, sovereign deployment: ₹0.22 per refusal (40% of ₹0.55) Add-ons: - Regulatory pack (ledger1 · invoice1 · collect1): ₹1,35,000 per tenant per year (Configuration of Govern for one rule set; blended price) - Evidence bundle beyond allowance: ₹2,500 per bundle (From L2: the eight-member signed bundle) - Verifier profile: ₹3,00,000 per regime per year (From L2: offline verification profile for one regulatory regime) - Counterparty verification seat: ₹45,000 per seat per year (For an auditor, lender or insurer who checks your bundles) - Partner certification (CA or audit firm): ₹1,50,000 per firm per year (Introducer, Implementer or Verifier partner) How the bill works: - An invoice line without a write_id cannot exist. - Included actions are consumed first; only actions beyond the allowance are billed. - A refusal costs 40% of one governed action at the same rate: 0.4 of an included action within the allowance, then ₹0.64 at L1, ₹0.48 at L2, ₹0.36 at L3 and ₹0.22 for a sovereign deployment. Each still writes a proof record. - List prices are flat to March 2029, then rise 4% a year. - A Work action that passes through Govern is counted once. Nobody pays twice for the same action. - No per-seat price and no outcome pricing. ### elan1 Work — meter: Credit A monthly plan set by your turnover band, with credits included. Credits beyond the allowance cost ₹0.80 each. Lines and add-ons sit on top of the plan. Plans by turnover band (elan1 Work ERP): - Sandbox — 14-day trial: ₹0 (1 app, 3 users, 500 credits, community support) - Nano — turnover ₹1–5 crore: ₹2,499 per month (1 app, 5 users, 2,000 credits a month) - Growth — turnover ₹5–20 crore: ₹7,999 per month (3 apps, 15 users, 10,000 credits a month, L1 support) - Scale — turnover ₹20–100 crore: ₹19,999 per month (5 apps, 50 users, 30,000 credits a month, L2 support (24 h)) - Enterprise — turnover above ₹100 crore: ₹49,999+ per month (Unlimited apps and users, credits by agreement, L3 support (4 h) and a DPA) Credits: - Credit beyond the plan allowance: ₹0.80 per credit - Credit top-up block: ₹799 per 1,000 credits (Rolls over for 90 days) - Refused change: 0.4 of a credit (A change Govern refuses uses 0.4 of a credit (₹0.32 at ₹0.80 per credit); the credit renders Govern's charge, so nobody pays twice) Lines on top of the plan: - elan1 Work Revenue — Growth: ₹4,999 per month (Governed changes in your CRM) - elan1 Work Revenue — Scale: ₹9,999 per month - elan1 Work Voice — Nano and Growth: ₹2,999 per month (Inbound approvals by voice) - elan1 Work Voice — Scale and Enterprise: ₹5,999 per month - elan1 Work Commerce — Growth: ₹5,999 per month (Storefront line) - elan1 Work Commerce — Scale: ₹11,999 per month - ONDC seller adapter (Commerce): ₹99,999 one-time + ₹4,999 per month (Built only on a named request) Add-ons and support: - Compliance filing pack: ₹1,999 per month (GSTR-1 and 3B preparation, 2B reconciliation, e-invoice monitoring) - Additional catalogue app: ₹1,499 per month (Beyond the plan's app allowance) - Support L1: Included (Mon–Fri 10:00–19:00 IST) - Support L2: ₹4,999 per month (Mon–Sat 09:00–21:00, CA channel, 14-day backups) - Support L3: ₹19,999 per month (24×7 P0/P1, named contact, 30-day backups) Attach your own ERPNext (Mode B) and migration: - Tally → ERPNext migration: ₹24,999 one-time (Same price hosted or attached; dry run, reconciliation, CA sign-off) - Attach onboarding: ₹19,999 one-time (Refunded if the readiness check fails) - Attach surcharge — Growth: ₹3,000 per month (On top of the plan. Never sold on Nano) - Attach surcharge — Scale: ₹6,000 per month (On top of the plan) - Attach surcharge — Enterprise: By agreement For chartered accountants and partners: - CA seat, per client site: ₹0, always (Read and approve, free for every client) - CA multi-client console: Included - Partner white-label console: ₹99,999 per month (Partner terms on request) Terms: - Annual prepay: Two months free (16.67% off list) - Design partner: ₹0 for 90 days (20,000 credits a month fair use, then a 12-month price lock) - Largest discount off list: 10% (On an annual commitment) How the bill works: - You pay a monthly plan by turnover band plus credits beyond the allowance. - A credit is a rendering of governed actions, never a separate count, so you never pay twice for one change. - A change Govern refuses uses 0.4 of a credit (₹0.32 at ₹0.80 per credit). The credit is the rendering of Govern's charge, so nobody pays twice. - No per-seat price. CA seats are free, always. ### elan1 Decide — meter: Decision A yearly platform plan with a decision allowance, then ₹30 per 1,000 decisions beyond it. System-2 passes are passed through at model cost plus 30%. Every plan includes all six modules; individual Decision Packs from the pack catalogue are also priced per pack. Platform plans: - Growth — self-serve and developer teams: ₹4,80,000 per year (Typical volume 1,00,000 decisions a month) - Mid-market: ₹36,00,000 per year (Typical volume 15,00,000 decisions a month) - Enterprise — BFSI and insurers: ₹1,50,00,000 per year (Typical volume 1 crore decisions a month; SSO and SLA) Usage: - Decisions beyond the plan allowance: ₹30 per 1,000 decisions - System-2 pass (escalated decision): Model cost + 30% (Shown separately on the bill; about ₹1.14 per escalated decision at today's model prices) - A write intent Govern refuses: 40% of a governed action (Metered by elan1 Govern, not by Decide; the decision itself is counted once, as a decision) Packs and services: - Decision Packs: Priced per pack (The Decision Packs module is in every plan; each catalogue pack is priced individually) - Implementation — Mid-market: ₹5,00,000 one-time - Implementation — Enterprise: ₹30,00,000 one-time How the bill works: - A decision is not a governed action. Only the writes that follow a decision pass through elan1 Govern, which meters them. - Decide never counts a governed action a second time. - A write intent that Govern refuses is metered by elan1 Govern at 40% of a governed action. The decision itself is counted once, as a decision. - System-2 is a pass-through, shown on its own line. ### elan1 Run — meter: Node-year A three-line bill for capacity: a yearly subscription, plus every CPU node and every GPU under management. Tokens and the six runtime units are counted and shown, never priced. A call refused at the edge costs 40% of one governed action, shown on its own line. Subscriptions: - Starter: ₹1,80,000 per year (2 CPU nodes included) - Standard: ₹6,00,000 per year (Plus nodes and GPUs under management) - Sovereign: ₹24,00,000 per year (Plus nodes and GPUs under management) Capacity under management: - CPU node under management: ₹1,80,000 per node per year - GPU under management: ₹1,80,000 per GPU per year - Tokens and runtime units: ₹0 — counted, never priced (Tokens in and out, GPU-seconds, bytes, pages, tool calls) - A call refused at the edge: 40% of one governed action (₹0.64 at the L1 rate) (Returns a 409 before the first token, so no token is sent) Support and add-ons: - Priority support: 25% of the subscription - 24×7 named-engineer support: 40% of the subscription - elan1 Run Runtime Controls, with elan1 Govern built in: ₹5,40,000 per year (The Runtime Controls module is included in every subscription; the governance profile adds three nodes under management (contracts C2, C6, C7, C8, C10)) - Paid 90-day pilot: ₹4,50,000 - Onboarding — Standard: ₹2,10,000 per new account - Onboarding — Sovereign: ₹8,00,000 per new account Operator OEM (the operator's brand is the only brand shown): - Platform licence, Band A — up to 250 GPUs: ₹60,00,000 per year (Plus partner terms on request) - Platform licence, Band B — 251 to 1,000 GPUs: ₹85,00,000 per year (Plus partner terms on request) - Platform licence, Band C — over 1,000 GPUs: ₹1,20,00,000 per year (Plus partner terms on request) - GPU under management, OEM: ₹36,000 per GPU per year - Onboarding — OEM partner: ₹12,00,000 per new partner Systems integrators: - SI partner licence: ₹12,00,000 per year (Ten deployments) - Additional deployment: ₹1,50,000 per deployment per year - Onboarding — SI partner: ₹2,00,000 per new partner How the bill works: - Every bill has three capacity lines: subscription, nodes, GPUs. Never a single figure. Calls refused at the edge, if any, appear on a line of their own. - Priced by capacity, never by tokens. - A call refused at the edge by Run's runtime controls returns a 409 before the first token, so no token is sent. It costs 40% of one governed action: ₹0.64 at the L1 rate. A write that elan1 Govern refuses is metered once, by Govern. ## Page summaries Each page's opening answer and the questions it answers, in site order. ### elan1 — AI agent governance: every action, answerable URL: https://elan1.ai elan1 is the governed write path for AI agents, built by ELAN1 AGENTIC TECHNOLOGIES PRIVATE LIMITED in Tamil Nadu. Every consequential action an agent proposes is checked against your rules, approved by a named person where your rules ask, and written to a tamper-evident, hash-chained proof record. A refusal costs 40% of one governed action. Questions answered on this page: - What is elan1? - What is AI agent governance? - How is elan1 different from an AI governance platform that inventories models? - Can an AI agent change my ERP without a person approving it? - Is the proof record tamper-proof? - Where is my data stored? ### See a governed AI agent action: 5-minute demo | elan1 URL: https://elan1.ai/see-it The walkthrough follows one write an AI agent proposes, from the request to the proof record: the rule check, the hold for a named approver, the commit and the 16-field record. It takes about five minutes and needs no sign-up. Every record shown is an illustrative specimen, not customer data. Questions answered on this page: - What happens when an AI agent proposes a write? - Who approves a held write? - What does the proof record contain? ### AI agent governance pricing: pay per governed action | elan1 URL: https://elan1.ai/pricing elan1 charges one meter per platform: governed actions for elan1 Govern, credits for elan1 Work, decisions for elan1 Decide and node-years for elan1 Run. Each plan includes an allowance, and usage beyond it is billed at a published rate. A refusal costs 40% of one governed action, because it still runs every check and writes a proof record. All prices are list prices in INR, exclusive of GST. Questions answered on this page: - Are refused actions charged? - How much does elan1 Work cost for a small business? - Do chartered accountants pay for seats? - Is GST included in the prices? - Is there a free trial? - Do I pay twice when an elan1 Work change passes through elan1 Govern? ### Agentic AI governance platform: four layers | elan1 URL: https://elan1.ai/platform The elan1 platform is one governed write path in four layers. elan1 Govern checks, approves and records every write. elan1 Work runs governed agents on ERPNext, CRM, storefront and voice. elan1 Decide makes typed, calibrated decisions routed by risk. elan1 Run operates the open-source AI stack under contracts. All four are available. Questions answered on this page: - What does each elan1 platform do? - Do I need all four platforms? - Which part of elan1 is allowed to write to my systems? - What are guardian agents, and does elan1 Govern do that job? ### AI agent governance and human approval | elan1 Govern URL: https://elan1.ai/platform/govern elan1 Govern is the control plane for AI agent writes. Every write intent climbs the Right Path: identity, nine pre-gates, versioned rules, a blast-radius guardrail and an autonomy check, then a named human approver where your rules ask. Each action, allowed or refused, leaves a 16-field, hash-chained proof record. A refusal costs 40% of one governed action. Questions answered on this page: - How is elan1 Govern different from AI governance platforms? - Can an AI model approve its own change? - What happens when an agent's write is refused? - Does elan1 Govern enforce my rules or only advise? - How does elan1 Govern help with the EU AI Act and ISO/IEC 42001? - What does elan1 Govern cost? ### Governed AI agents for ERP, CRM and commerce | elan1 Work URL: https://elan1.ai/platform/work elan1 Work runs governed AI agents for work that commits: ERP on ERPNext, Revenue for CRM, Commerce for storefronts and Voice for approvals by phone. Agents draft changes; nothing is written without a rule check, a named person where your rules ask, and a proof record. Indian firms can move from Tally with a migration. Questions answered on this page: - Can an AI agent post entries in ERPNext safely? - Do I have to leave Tally? - Which turnover bands do the plans cover? - How is my chartered accountant involved? - How are credits counted? ### Calibrated AI decisions routed by risk | elan1 Decide URL: https://elan1.ai/platform/decide elan1 Decide turns business questions into typed, calibrated decisions. Each answer, a Boolean, Choice or Score, carries a tested confidence and is routed by risk: automatic, human review, a System-2 second pass, or hold. Every answer is kept in the Decision Ledger, and any write that follows still goes through elan1 Govern. Questions answered on this page: - What kinds of decisions does elan1 Decide handle? - When does a person review an AI decision? - What is calibrated confidence? - Does elan1 Decide write to my systems? - How is elan1 Decide priced? ### Open-source AI stack operations, under contract | elan1 Run URL: https://elan1.ai/platform/run elan1 Run is the infrastructure intelligence platform for the open-source AI stack. It puts ten versioned fusion.*/v1 contracts between your applications and components such as model servers and vector stores, proves them with an offline conformance suite, swaps components through human-gated substitution and runs Day-2 operation, priced by node and GPU, never by token. Questions answered on this page: - What is the open-source AI stack elan1 Run operates? - Can I replace a model without rewriting my integration? - How is elan1 Run priced? - Can elan1 Run run in a sovereign or on-premises deployment? ### AI agent governance reference architecture | elan1 URL: https://elan1.ai/platform/architecture elan1's reference architecture has nine planes, from P0 residency to P8 packs, with the kernel at P3. The layers meet in only two places, KernelPort and the fusion.*/v1 contracts, and every write takes one fixed route, the Right Path, from rung 0b STOP to rung 9 METERED. Only the kernel writes to the system of record. Questions answered on this page: - What is the Right Path? - Why does only one component write to the system of record? - Where do AI models sit in the architecture? ### AI assurance levels: Guarded, Attested, Proven | elan1 URL: https://elan1.ai/platform/assurance-levels elan1 makes three levels of claim about its evidence. At L1 Guarded, records are hash-chained, so any change is evident to you. At L2 Attested, records are signed and timestamped, and an auditor can check them offline. L3 Proven begins when an outside auditor accepts the evidence in writing. Levels describe the claim, not a product tier. Questions answered on this page: - What is the difference between L1, L2 and L3? - What is the difference between Mode A and Mode B? - When is L3 Proven available? - Which level does an auditor need? ### AI agent audit trail: the 16-field proof record | elan1 URL: https://elan1.ai/platform/proof-record A proof record is elan1's audit trail entry for one AI agent action. It has exactly 16 fields, including who acted, which declaration and rules version ran, the record that changed and the previous record's digest. Records are SHA-256 hash-chained, so a change to any earlier record is evident. Refused actions are recorded too, each metered at 40% of a governed action. Questions answered on this page: - What should an AI agent audit trail record? - What is the difference between a tamper-evident and an immutable log? - Are refused actions recorded? - How do I verify a proof record? - Why exactly 16 fields? ### MCP governance and AI agent integrations | elan1 URL: https://elan1.ai/platform/integrations Agents reach elan1 through two crossings only. Above, they call KernelPort directly, through the MCP server or over HTTP; MCP tools are grouped into read, stage and act classes, and every act becomes a governed write. Below, elan1 Run reaches the stack through ten fusion.*/v1 contracts. There is no third door. Questions answered on this page: - Can I govern the MCP tools my agents already use? - Which MCP tools need a human approval? - Does elan1 hold the write credential? - Which systems can elan1 write to? ### Tamper-evident audit log for AI agents: L1 Guarded | elan1 URL: https://elan1.ai/platform/govern/l1 L1 Guarded is elan1 Govern's first assurance level. Every agent write takes the Right Path, passes approvals where your rules ask, is committed by a single writer and is recorded in a SHA-256 hash-chained proof record, so any later change to a record is evident to you. It is tamper-evident, not tamper-proof. Questions answered on this page: - What does tamper-evident mean? - Is L1 Guarded enough for an external auditor? - What is included in the L1 price? - How do I check the chain myself? ### Signed AI audit records for auditors: L2 Attested | elan1 URL: https://elan1.ai/platform/govern/l2 L2 Attested is elan1 Govern's second assurance level. On top of L1, each proof record is signed with the residency domain's Ed25519 key, anchored with an outside timestamp and packed into an eight-member evidence bundle. A free offline verifier lets an auditor, lender or insurer check the bundle without asking elan1. Questions answered on this page: - What is in an L2 evidence bundle? - Can my auditor verify records without elan1? - How is L2 different from L1? - What does L2 Attested cost? ### AI evidence that outlives the vendor: L3 Proven | elan1 URL: https://elan1.ai/platform/govern/l3 L3 Proven is elan1 Govern's third assurance level: evidence that stays checkable even if elan1 is gone. It has no launch date. It begins for a tenant when an outside auditor accepts that tenant's L2 Attested evidence bundle in writing, and the L3 price applies only from that point. Questions answered on this page: - When does L3 Proven start? - What does an auditor have to accept? - What changes in the price at L3? ### ERPNext AI agents with approval and audit trail | elan1 URL: https://elan1.ai/platform/work/erp elan1 Work ERP lets an AI agent draft and apply changes in ERPNext, hosted by elan1 or attached to your own instance. Each change, such as a journal entry or purchase invoice, passes a rule check and a named approver where your rules ask, and leaves a proof record. A Tally migration includes a dry run and CA sign-off. Questions answered on this page: - Can an AI agent post journal entries in ERPNext safely? - How does the Tally to ERPNext migration work, and what does it cost? - How does elan1 Work ERP support the MCA audit trail (edit log)? - Can I keep my own ERPNext instance? - Does elan1 Work help with GST returns and e-invoicing? - What does elan1 Work ERP cost? ### AI CRM agent with approvals and a record | elan1 Work URL: https://elan1.ai/platform/work/revenue elan1 Work Revenue is the CRM line of elan1 Work. An AI agent can draft changes to leads, deals, quotes and customer records, and each change passes the same rule check, the same named approver where your rules ask, and the same proof record as a change to your books. It sits on top of an elan1 Work plan. Questions answered on this page: - What CRM changes can the agent make? - Who approves a CRM change? - Does Revenue need the ERP line? ### AI agent for store prices, stock and refunds | elan1 Work URL: https://elan1.ai/platform/work/commerce elan1 Work Commerce is the storefront line of elan1 Work. An AI agent can propose changes to prices, stock, refunds and orders, and each one is checked before it is written, approved by a named person where your rules ask, and recorded by elan1 Govern. An ONDC seller adapter is built on a named request. Questions answered on this page: - Which storefront changes can the agent propose? - Can refunds require a person's approval? - Is there an ONDC adapter? ### Voice approval for AI agent changes | elan1 Work URL: https://elan1.ai/platform/work/voice elan1 Work Voice lets a named approver hear a pending change on the phone and say yes or no. It is one more way to reach an approval, not a new power: the same checks run, the same step-up applies, and the approval leaves the same proof record as one given in the console. Questions answered on this page: - Can an approval by phone be trusted? - Does Voice let the agent make changes by itself? - Which channels can reach an approver? ### Typed AI decisions: Boolean, Choice and Score | elan1 URL: https://elan1.ai/platform/decide/decision-studio Decision Studio is the elan1 Decide module where a team defines a decision before any model answers it. Each decision is typed as a Boolean, a Choice or a Score, with a fixed shape, so every answer can be checked, calibrated, routed and recorded in the same way, whatever model produces it. Questions answered on this page: - What is a typed decision? - Why define the question before the model answers? - Can I change a decision after it is live? ### Route AI decisions by risk: auto, review, hold | elan1 URL: https://elan1.ai/platform/decide/router The Router is the elan1 Decide module that sends every answer one of four ways according to its risk tier and calibrated confidence: automatic, human review, a System-2 second pass, or hold. Low-confidence or high-risk answers never act alone; they reach a person in the Review Console with the case and the score. Questions answered on this page: - What are the four routes? - What is a System-2 pass, and how is it billed? - Who sets the risk thresholds? ### Calibrated confidence for AI decisions | elan1 Decide URL: https://elan1.ai/platform/decide/calibration-lab Calibrated confidence means that when a model says it is 90% sure, it is right about 90% of the time on your own cases. The Calibration Lab in elan1 Decide tests and calibrates every decision for your tenant before any answer is automated. A decision without calibration is never routed to automatic. Questions answered on this page: - What is calibrated confidence? - How is calibration tested? - What happens to an uncalibrated decision? ### Human review queue for unsure AI decisions | elan1 Decide URL: https://elan1.ai/platform/decide/review-console The Review Console is where unsure AI decisions go to a person. A reviewer sees the case and the calibrated score side by side, decides, and the decision is recorded with its route in the Decision Ledger. Cases reach the console when confidence or risk tier says a person should look. Questions answered on this page: - Which cases reach a reviewer? - What does the reviewer see? - Is the reviewer's decision recorded? ### AI decision audit log: every answer and route | elan1 URL: https://elan1.ai/platform/decide/decision-ledger The Decision Ledger is elan1 Decide's audit log of decisions. It keeps every answer with its type, calibrated confidence, route and reviewer, if any. When a decision leads to a write, the ledger entry's digest is bound into that write's proof record in elan1 Govern, so the decision and the action can be read together. Questions answered on this page: - What does the Decision Ledger record? - How is a decision linked to the action it caused? - Is a decision the same as a governed action? ### Decision packs for claims, AML, KYC and disputes | elan1 URL: https://elan1.ai/platform/decide/decision-packs A Decision Pack packages one kind of case, such as insurance claims triage, AML alert triage, KYC review or a payment dispute, as a ready set of typed decisions, routes and review rules. Packs compile to elan1 Govern's seven-block declarations, so any write that follows a decision is checked and recorded like every other write. Questions answered on this page: - Which decision packs are available? - Can a pack approve a claim or close an AML alert on its own? - How are packs priced? ### AI stack contracts: ten fusion.*/v1 interfaces | elan1 URL: https://elan1.ai/platform/run/contracts elan1 Run Contracts are ten versioned fusion.*/v1 capability contracts that sit between your applications and the open-source AI stack, covering capabilities such as model serving and retrieval. Each contract has two licence-clean implementations, so applications are written against the contract and a component can be replaced without rewriting the integration. Questions answered on this page: - What is a fusion.*/v1 contract? - Why two implementations per contract? - Which components do the contracts cover? ### Conformance tests for your AI stack, run offline | elan1 URL: https://elan1.ai/platform/run/conformance elan1 Run Conformance is the K1–K7 test suite every component must pass before it may claim a fusion.*/v1 contract. It is blocking-green and runs offline, so your auditor can run it on their own machine without elan1. Third-party agents are tested separately against C1–C14. Questions answered on this page: - What does the K1–K7 suite test? - Can my auditor run it without elan1? - What are the C1–C14 tests? ### Swap an LLM without breaking production | elan1 Run URL: https://elan1.ai/platform/run/substitution elan1 Run Substitution replaces one component of the AI stack, such as a model or vector store, with another that meets the same fusion.*/v1 contract. It follows nine steps with two human gates, H1 and H2, and is never autonomous. Applications keep calling the contract, so the integration does not need to be rebuilt. Questions answered on this page: - How do I swap an LLM without rewriting my app? - Who approves a substitution? - What if the new component fails conformance? ### Day-2 operations for open-source AI infrastructure | elan1 URL: https://elan1.ai/platform/run/operate elan1 Run Operate is Day-2 operation for the open-source AI stack: running, patching and observing it after go-live. It counts six runtime units, tokens in and out, GPU-seconds, bytes, pages and tool calls, and shows them on the bill without pricing them. You pay per CPU node and per GPU under management. Questions answered on this page: - What does Day-2 operation include? - Why are tokens counted but not priced? - How much does a node or GPU under management cost? ### AI runtime controls: budgets, guards, tool access | elan1 URL: https://elan1.ai/platform/run/runtime-controls elan1 Run Runtime Controls is the module that controls model and tool calls at runtime, with elan1 Govern built in. It applies a budget hard-stop, attributes cost to a tenant and process, runs a guard on each call and authorises tool use. A call refused at the edge returns a 409 before the first token and costs 40% of one governed action: ₹0.64 at the L1 rate. Questions answered on this page: - What happens when a budget is reached? - How does tool authorisation work? - Is a refused call charged? ### AI agent governance by role, industry and regulation | elan1 URL: https://elan1.ai/solutions elan1 solutions start from the question each team asks first. Operators ask who commits a change, risk and audit ask for evidence, builders ask how agents may write, banks and insurers ask for maker-checker decisions, and accounting firms ask whether the books still balance. Regulation pages map the EU AI Act, ISO/IEC 42001, NIST AI RMF and DPDP Act. ### Human-in-the-loop AI agents for operations | elan1 URL: https://elan1.ai/solutions/operators Human-in-the-loop for AI agents means a named person, not the agent, commits any change your rules mark as consequential. With elan1, the agent drafts the change, the rules decide whether it needs approval, and the approver sees exactly what will change before saying yes. Routine changes within limits can run alone, and every action is recorded. Questions answered on this page: - What is human-in-the-loop for AI agents? - When is human-in-the-loop just theatre? - Which changes can run without approval? - What does the approver actually see? ### Audit evidence for every AI agent action | elan1 URL: https://elan1.ai/solutions/assurance elan1 gives risk, audit and security teams evidence for every action an AI agent takes, not only a policy document. Each action, allowed or refused, leaves a 16-field proof record. At L1 the record is tamper-evident; from L2 it is signed and an auditor can check the evidence bundle offline, without asking elan1. Questions answered on this page: - What evidence does an auditor need for AI agents? - Can auditors check the records without elan1? - How does this map to ISO/IEC 42001 and the EU AI Act? - What do you not claim? ### Safe AI agent write access to production systems | elan1 URL: https://elan1.ai/solutions/builders To give an AI agent write access safely, route every write through one path that the agent cannot bypass. With elan1, agents send a write intent through KernelPort, MCP or HTTP; the kernel checks it, holds it for approval where rules ask, commits it with a short-lived single-use credential and records it. Refusals come back typed. Questions answered on this page: - Should AI agents have write access to production? - How do I stop an agent bypassing the rules? - What does a refusal look like to my code? - Which SDKs or protocols are supported? ### Maker-checker AI for banks: AML, KYC, disputes | elan1 URL: https://elan1.ai/solutions/bfsi Maker-checker for AI means the model is the maker and a named person is the checker. With elan1 Decide and elan1 Govern, AI triages AML alerts, KYC reviews and disputes with a calibrated confidence; answers below your threshold go to a reviewer, and any resulting write is approved and recorded before it reaches a core system. Questions answered on this page: - What is maker-checker for AI agents? - Can AI close an AML alert on its own? - How does this help with RBI's FREE-AI framework? - Where is customer data stored? - How are decisions audited? ### AI claims triage with human review for insurers | elan1 URL: https://elan1.ai/solutions/insurance AI claims triage with elan1 means a model sorts incoming claims by type, completeness and risk with a calibrated confidence. Routine, high-confidence cases move on; unsure or high-value cases go to a claims handler who sees the case and the score. Every decision is kept in the Decision Ledger, and any payout write goes through elan1 Govern. Questions answered on this page: - Can AI approve an insurance claim on its own? - Which claims go to a person? - How is each claims decision recorded? ### AI for chartered accountants: governed client books | elan1 URL: https://elan1.ai/solutions/accounting-firms elan1 Work for small firms, through your CA, lets an AI agent change a client's books in ERPNext while the chartered accountant reads and approves what changes. The trial balance, GST return and MCA audit trail stay intact, every change leaves a proof record, and CA seats are free for every client. Questions answered on this page: - How can chartered accountants use AI agents on client books? - Does it support the MCA audit trail rule? - Do CA seats cost anything? - Can my clients move from Tally? - Can I manage many clients from one console? ### EU AI Act Articles 12 and 14 for AI agents | elan1 URL: https://elan1.ai/regulation/eu-ai-act The EU AI Act asks high-risk AI systems to record events automatically (Article 12) and to be designed for effective human oversight (Article 14), and deployers must keep those logs (Article 26). elan1 helps by recording every agent action in a proof record and holding consequential writes for a named person. It does not make a system compliant alone. Questions answered on this page: - What does Article 12 require for AI agent logs? - What does Article 14 human oversight mean in practice? - Are AI agents high-risk under the EU AI Act? - How long must deployers keep logs? - Does elan1 make my system EU AI Act compliant? ### ISO 42001 audit evidence for AI agents | elan1 URL: https://elan1.ai/regulation/iso-42001 ISO/IEC 42001 asks an organisation to run an AI management system and show that its controls operate, not only that policies exist. For AI agents, auditors look for runtime evidence such as event logs (Annex A control A.6.2.8) and records of human oversight. elan1 produces that evidence per action, in a proof record. Questions answered on this page: - What evidence does an ISO 42001 auditor want for AI agents? - What is Annex A control A.6.2.8? - Is elan1 ISO 42001 certified? - How do proof records map to ISO 42001 clauses? ### NIST AI RMF for AI agents: Govern to Manage | elan1 URL: https://elan1.ai/regulation/nist-ai-rmf The NIST AI Risk Management Framework organises AI risk work into four functions: Govern, Map, Measure and Manage. For AI agents that change records, the gap is usually between written policy and the action itself. elan1 closes it by checking each action against versioned rules and recording the outcome in a proof record. Questions answered on this page: - How does the NIST AI RMF apply to AI agents? - Is the NIST AI RMF mandatory? - What is NIST AI 600-1? - Which RMF functions does elan1 support? ### DPDP Act 2023 and AI agents: roles and residency | elan1 URL: https://elan1.ai/regulation/india-dpdp The Digital Personal Data Protection Act, 2023 applies when AI agents process digital personal data in India. In hosted deployments the customer is the Data Fiduciary and elan1 is its Data Processor under a data processing agreement, with data kept in the Mumbai region. Grievances, legal notices and legal action under the Act are handled by Hariharan. Questions answered on this page: - Does the DPDP Act apply to AI agents? - Is elan1 a Data Fiduciary or a Data Processor? - Where is personal data stored? - Who do I contact with a grievance? - Who handles legal action under the DPDP Act? ### Trust and evidence: claims, security, verification | elan1 URL: https://elan1.ai/trust elan1's trust centre lists every claim the company makes and the assurance level at which it becomes true. It covers the claims register, security and data residency in India, launch disclosures, the roadmap, and how to verify a proof record yourself, so a buyer or auditor can check each statement rather than take it on trust. ### AI vendor claims register: what we say and don't | elan1 URL: https://elan1.ai/trust/claims The claims register is elan1's public list of what it says and does not say about its products. Each claim carries the assurance level at which it becomes true: tamper-evident records at L1 Guarded, signed and offline-checkable records from L2 Attested, and enforcement only in Mode A, where elan1 holds the write credential. Questions answered on this page: - Is elan1 tamper-proof? - When does elan1 say 'enforced'? - Is elan1 certified? ### Security and data residency in India | elan1 URL: https://elan1.ai/trust/security elan1 runs in AWS ap-south-1 (Mumbai) across three availability zones. Each residency domain has its own database and Ed25519 signing key, and proof records never leave the domain they were written in. Gulf and EU domains open only on a signed contract. No US region is offered. Questions answered on this page: - Where is my data stored? - Who holds the signing keys? - How do I report a vulnerability? ### How to verify an AI agent proof record yourself | elan1 URL: https://elan1.ai/trust/verify You can verify an elan1 proof record without asking elan1. At L1, recompute the record's SHA-256 digest from its 16 fields and confirm it matches the next record's link in the chain. From L2, also check the Ed25519 signature and outside timestamp with the free offline verifier. Questions answered on this page: - How do I verify a proof record? - Do I need elan1 to verify a record? - What does a broken chain mean? ### elan1 roadmap: available today, improving in order URL: https://elan1.ai/trust/roadmap The elan1 roadmap lists what is available today across elan1 Govern, Work, Decide and Run, and what improves next, in order. Planned items carry planned dates only where the company has set one. L3 Proven has no date: it begins when an outside auditor accepts an L2 Attested bundle in writing. ### Disclosures: launch status and product limits | elan1 URL: https://elan1.ai/trust/disclosures elan1's disclosures page states plainly what is launched, what each platform does not do, and the limits a buyer should plan around. All four platforms, elan1 Govern, Work, Decide and Run, are available, with L1 Guarded and L2 Attested; L3 Proven is event-gated on auditor acceptance. ### AI agent governance resources: papers and glossary | elan1 URL: https://elan1.ai/resources elan1's resources are ungated: four papers on the governed write path, auditor evidence, AI agent RFPs and the DPDP Act; a 12-question readiness check for AI agents that write; a glossary that defines each term in one sentence; and illustrative proof records that show what the evidence looks like. ### AI agent governance papers and briefs, ungated | elan1 URL: https://elan1.ai/resources/library The elan1 library holds four ungated papers: an architecture paper on the governed write path, a guide to reading a proof record for auditors, an RFP question set for buying AI agents that write to your systems, and a paper on the DPDP Act and append-only record chains. ### The governed write path: an architecture paper | elan1 URL: https://elan1.ai/resources/library/write-path-architecture This paper sets out the governed write path: an architecture in which AI agents may propose changes but only one kernel may write. It covers the nine planes, the two crossings where layers meet, the single-writer credential and the Right Path every write climbs, from identity and pre-gates to approval, proof and metering. ### AI audit evidence: how auditors read a proof record | elan1 URL: https://elan1.ai/resources/library/evidence-for-auditors This paper shows an auditor how to read an elan1 proof record field by field: who asked, which rules ran, who approved, what changed and how the record links to the one before. It explains how to recompute the digest and walk the chain, and what changes from L2, when records are signed. ### RFP questions for AI agents that write | elan1 URL: https://elan1.ai/resources/library/rfp-question-set This RFP question set helps buyers assess any AI agent that writes to business systems, not only elan1. It asks who or what may write, how approvals work, what is recorded for every action, whether refusals are recorded, and how the buyer or an auditor can check the evidence without the vendor's help. ### DPDP Act and append-only audit logs | elan1 URL: https://elan1.ai/resources/library/dpdp-and-the-append-only-chain This paper explains how an append-only, hash-chained record of AI agent actions works with India's Digital Personal Data Protection Act, 2023. It covers elan1's role as Data Processor or Data Fiduciary, how erasure and correction requests are handled when records cannot be edited, and who handles grievances and legal action. ### AI agent readiness assessment: 12 questions | elan1 URL: https://elan1.ai/resources/readiness-check The readiness check is a free, 12-question self-assessment for teams whose AI agents change records. It asks who may change what, which changes need a named approver, what is recorded for each action and how refusals are handled, then gives a plain result and the next step. It takes a few minutes and needs no sign-up. Questions answered on this page: - Who is the readiness check for? - Do I need to sign up? - What do I get at the end? ### AI agent audit record examples: four proof records | elan1 URL: https://elan1.ai/resources/specimens These four illustrative proof records show what elan1 records for an AI agent's write: one allowed, one held for a named approver, one refused at a pre-gate, and one small firm's journal entry as its chartered accountant reads it. Every specimen uses the fictional Kolam Components and is not customer data. ### Example: an AI agent's month-end journal entry | elan1 URL: https://elan1.ai/resources/specimens/allowed-write This illustrative specimen shows the proof record elan1 writes when an AI agent's month-end journal entry is allowed. It shows all 16 fields, the rules that ran, the approval, the committed change and the link to the previous record. The company, Kolam Components, is fictional and all data is illustrative. ### Example: an AI agent write held for human approval | elan1 URL: https://elan1.ai/resources/specimens/held-for-approval This illustrative specimen shows an AI agent write that elan1 held for a named approver because the rules asked for one. It shows why the write was held, who was asked, what the approver saw and how the decision appears in the 16-field proof record. The company is fictional and all data is illustrative. ### Example: an AI agent write refused at a pre-gate | elan1 URL: https://elan1.ai/resources/specimens/refused-write This illustrative specimen shows a purchase invoice that an AI agent proposed and elan1 refused at rung 3, the pre-gates. It shows the typed refusal, the gate that stopped it and the proof record a refusal still leaves. A refusal is metered at 0.4 of a governed action: ₹0.64 at L1 beyond the allowance. The company and data are fictional. ### Example: an AI journal entry, read by the firm's CA | elan1 URL: https://elan1.ai/resources/specimens/small-firm-journal-entry This illustrative specimen shows a journal entry an AI agent made in a small firm's ERPNext books, as the firm's chartered accountant reads it in the elan1 Work CA console. It shows what changed, which rules ran, who approved and how the entry links to the record before. The firm and data are fictional. ### AI agent governance glossary: 39 terms defined | elan1 URL: https://elan1.ai/resources/glossary The elan1 glossary defines 39 terms used in AI agent governance and on this site, each in one sentence: from write intent, allow and refusal to proof record, assurance levels, Mode A and Mode B. Each term page explains where the term shows up in elan1 and links to related terms, platforms and regulation. ### What is an allow? AI agent write approval defined | elan1 URL: https://elan1.ai/resources/glossary/allow An allow is elan1 Govern's decision that a proposed write may happen. Only elan1 Govern can produce one; a model, an agent or elan1 Decide never does. An allow is reached by climbing the Right Path, from identity and pre-gates to rules, a guardrail, an autonomy check and, where required, a named approver. Questions answered on this page: - Can an AI model produce an allow? - What happens if Decide and Govern disagree? ### What is an assurance level? AI evidence levels | elan1 URL: https://elan1.ai/resources/glossary/assurance-level An assurance level is a level of claim about the evidence elan1 produces, never a product tier. L1 Guarded means records are hash-chained, so changes are evident to you. L2 Attested adds signatures and outside timestamps an auditor can check offline. L3 Proven begins when an outside auditor accepts the evidence in writing. Questions answered on this page: - Is an assurance level a pricing tier? - Which assurance level do I need? ### What is an AI agent autonomy level? A0 to A5 | elan1 URL: https://elan1.ai/resources/glossary/autonomy-level An autonomy level states how much an AI agent may do on its own, on a scale from A0 to A5. It is set per process in the declaration, checked at the autonomy rung of the Right Path, and recorded on every proof record, so anyone reading the record can see whether a person had to approve the action. Questions answered on this page: - What are the autonomy levels A0 to A5? - Where is the autonomy level recorded? ### What is conformance? AI stack and agent tests | elan1 URL: https://elan1.ai/resources/glossary/conformance Conformance is passing a published test suite before making a claim. In elan1, components of the open-source AI stack must pass the K1–K7 suite before claiming a fusion.*/v1 contract, and third-party AI agents are tested against C1–C14. The suites run offline, so an auditor can run them without elan1. ### What is a fusion.*/v1 contract in elan1 Run? | elan1 URL: https://elan1.ai/resources/glossary/contract A contract in elan1 Run is one of ten versioned fusion.*/v1 capability contracts that define how applications call a part of the open-source AI stack. Each has two licence-clean implementations, so applications are written against the contract, not the component, and a component can be replaced through governed substitution. ### What is a declaration? AI agent rules in 7 blocks | elan1 URL: https://elan1.ai/resources/glossary/declaration A declaration is a process's rules for AI agent writes, set out in seven versioned blocks: what may change, under which gates, within which limits, and who approves. elan1 Govern checks every write intent against the declaration in force, and the version used is recorded in the proof record, so later changes to the rules never rewrite history. Questions answered on this page: - What goes into a declaration? - What happens when a declaration changes? ### What is a design partner at elan1? | elan1 URL: https://elan1.ai/resources/glossary/design-partner A design partner is an early-adopter organisation that puts one real process on elan1's governed write path and helps shape what comes next. The programme has ten places, meets for a 30-minute call every two weeks, and offers elan1 Work at ₹0 for 90 days within fair use, followed by a 12-month price lock. ### What does 'fail toward a human' mean for AI agents? | elan1 URL: https://elan1.ai/resources/glossary/fail-toward-a-human Fail toward a human is elan1's rule for uncertainty: when anything is unclear or unavailable, such as a missing rule, an unreachable approver or a low-confidence answer, the write stops and a person is asked. The system never fails toward an action. A stop is recorded in a proof record like any other outcome. Questions answered on this page: - What happens when an approver is unavailable? - Is a stopped write recorded? ### What is a gate? Checks before an AI agent write | elan1 URL: https://elan1.ai/resources/glossary/gate A gate is a check that an AI agent's write must pass before it can be allowed. elan1 Govern runs nine pre-gates, G1 to G9, at rung 3 of the Right Path, and six of them can never be skipped, whatever the autonomy level. A write that fails a gate is refused and still leaves a proof record. ### What is a governed action? AI agent write defined | elan1 URL: https://elan1.ai/resources/glossary/governed-action A governed action is one consequential write, proposed by an AI agent or a system, that passed the Right Path and was committed to the system of record. It is the unit elan1 Govern meters and bills. Refused writes still leave a proof record and are metered at 0.4 of a governed action. Questions answered on this page: - Is a refusal a governed action? - Is a decision a governed action? ### What is the kernel in elan1 Govern? | elan1 URL: https://elan1.ai/resources/glossary/kernel The kernel is elan1 Govern's core: a single write function behind KernelPort. It runs the gates, approvals, proof records and metering for every governed write, and no other elan1 product builds any of these itself. Because the kernel is the only writer, every change to a system of record passes through it. ### What is KernelPort? The elan1 Govern API | elan1 URL: https://elan1.ai/resources/glossary/kernelport KernelPort is the only door into elan1 Govern's kernel. It has six calls: define, assert, seal, verify, scope and refuse. Agents and products reach it directly, through the MCP server or over HTTP, and every write intent enters the Right Path through KernelPort. There is no other way to write through elan1. ### What is L1 Guarded? Tamper-evident AI records | elan1 URL: https://elan1.ai/resources/glossary/l1-guarded L1 Guarded is elan1 Govern's first assurance level. Every proof record is SHA-256 hash-chained to the one before, so any change to an earlier record is evident to you when you recompute the chain. It is tamper-evident, not tamper-proof: it shows that a change happened, rather than claiming one is impossible. ### What is L2 Attested? Signed AI audit records | elan1 URL: https://elan1.ai/resources/glossary/l2-attested L2 Attested is elan1 Govern's second assurance level. It adds an Ed25519 signature from the residency domain's key, an outside timestamp and an eight-member evidence bundle to each proof record. A free offline verifier lets an auditor, lender or insurer check the evidence without contacting elan1. L2 Attested is available. ### What is L3 Proven? Evidence that survives the vendor | elan1 URL: https://elan1.ai/resources/glossary/l3-proven L3 Proven is elan1 Govern's third assurance level: evidence that remains checkable even if elan1 no longer exists. It has no date. It starts for a tenant when an outside auditor accepts that tenant's L2 Attested evidence bundle in writing, and only then does the L3 price apply. ### What is a line in elan1 Work? ERP, Revenue and more | elan1 URL: https://elan1.ai/resources/glossary/line A line is a module of elan1 Work for one kind of work: ERP on ERPNext, Revenue for CRM, Commerce for storefronts, or Voice for approvals by phone. ERP is the base line, and the others sit on top of it. Every line writes through elan1 Govern, with the same gates, approvals and proof record. ### What is a meter? How elan1 charges for AI agents | elan1 URL: https://elan1.ai/resources/glossary/meter A meter is the single unit each elan1 platform charges for: governed actions for elan1 Govern, credits for elan1 Work, decisions for elan1 Decide and node-years for elan1 Run. Meters never double-count: a Work change that passes through Govern is counted once, and a refused action is metered at 0.4 of a governed action. ### What is Mode A (Enforced) in AI agent governance? | elan1 URL: https://elan1.ai/resources/glossary/mode-a-enforced Mode A (Enforced) is the deployment in which elan1 runs in-process and holds the write credential for the system of record. Because the agent never holds the credential, no write can reach the system without a gate decision and a proof record. It is the only mode in which elan1 describes its rules as enforced. Questions answered on this page: - What is the difference between Mode A and Mode B? - When can elan1 say 'enforced'? ### What is Mode B (Attested advisory)? | elan1 URL: https://elan1.ai/resources/glossary/mode-b-attested-advisory Mode B (Attested advisory) is the deployment in which elan1 is reached over MCP or HTTP and does not hold the write credential. Every write intent is still evaluated and recorded in a proof record, but because the agent's system holds the credential, elan1 advises rather than enforces. Mode A is required for enforcement. ### What is a module in elan1? Platform parts defined | elan1 URL: https://elan1.ai/resources/glossary/module A module is a named part of one elan1 platform, such as elan1 Decide Router or elan1 Run Substitution. It is always shown with its platform at first mention and is never a separate product or brand. elan1 Work's modules are called lines, and L1, L2 and L3 are levels of a claim, not modules. ### What is a pack? Rule sets for MCA, GST and RBI | elan1 URL: https://elan1.ai/resources/glossary/pack A pack is configuration of elan1 Govern for one rule set: ledger1 for MCA requirements, invoice1 for GST and collect1 for RBI collection rules. A pack contains no code and is not a separate brand. It sets which writes are checked, which gates apply and who approves, using the same Right Path. ### What is a plane in the elan1 reference architecture? | elan1 URL: https://elan1.ai/resources/glossary/plane A plane is one of nine levels in elan1's reference architecture, from P0 residency to P8 packs. The kernel, which performs every governed write, sits at P3. Planes keep concerns apart, so residency, identity, the write path, evidence and configuration can each change without weakening the others. ### What is a proof record? The AI agent audit record | elan1 URL: https://elan1.ai/resources/glossary/proof-record A proof record is the 16-field record elan1 writes for every action an AI agent proposes, whether it is allowed or refused. It holds who acted, what was proposed against which record, which declaration and rules version applied, and the digest of the previous record; the outcome and approver are shown beside it. Records are SHA-256 hash-chained, and there is never a seventeenth field. Questions answered on this page: - What does a proof record contain? - Is a refused action recorded? ### What is a refusal? A typed 'no' to an AI agent | elan1 URL: https://elan1.ai/resources/glossary/refusal A refusal is a typed "no" from any rung of the Right Path when an AI agent's write fails a check. It names the rung and reason in a structured envelope that code can handle. Every refusal still writes a proof record, and it is metered at 0.4 of a governed action, less than an allowed write costs. ### What is a residency domain? Data residency in India | elan1 URL: https://elan1.ai/resources/glossary/residency-domain A residency domain is a region with its own database and its own signing key. Today elan1 has one, "in", in Mumbai. Proof records stay in the domain they were written in, and L2 signatures use that domain's key. Gulf and EU domains open only on a signed contract. ### What is the Right Path? How an AI write is checked | elan1 URL: https://elan1.ai/resources/glossary/right-path The Right Path is the fixed route every write takes in elan1 Govern, from rung 0b STOP to rung 9 METERED. On the way it checks identity, opens the write door, runs the pre-gates, evaluates versioned rules, applies a blast-radius guardrail and the autonomy check, acts, writes the proof record and meters the action. Questions answered on this page: - What are the rungs of the Right Path? - Can a rung be skipped? ### What is a rung on the Right Path? | elan1 URL: https://elan1.ai/resources/glossary/rung A rung is one step on elan1's Right Path: stop, identity, write door, pre-gates, evaluate, guardrail, autonomy, act, proof and metered. Each rung can refuse an AI agent's write with a typed reason. The proof record shows how far a write climbed and where it stopped, if it stopped. ### What is a seal? How a proof record gets its digest | elan1 URL: https://elan1.ai/resources/glossary/seal A seal is the method that turns a proof record into its digest. elan1 uses Seal v6, which is frozen, so the same 16 fields always give the same SHA-256 digest. Because the method is published, anyone can recompute a record's digest and check that it links to the next record in the chain. ### What is the single-writer pattern for AI agents? | elan1 URL: https://elan1.ai/resources/glossary/single-writer Single writer means only one component, the elan1 kernel, writes to the system of record, using a single-use credential that expires after ten minutes. AI agents propose changes but never hold standing write access, so a compromised or confused agent cannot change records outside the Right Path. Questions answered on this page: - Why should AI agents not hold write credentials? ### What is a write intent? An AI agent's proposal | elan1 URL: https://elan1.ai/resources/glossary/write-intent A write intent is a typed proposal to change a record in a system such as an ERP. AI agents and elan1 Decide may produce write intents, but only elan1 Govern can turn one into an allow. Each write intent climbs the Right Path and ends in a proof record, whether it is allowed or refused. Questions answered on this page: - Can an AI agent write directly? ### AI agent governance docs: KernelPort, MCP, HTTP | elan1 URL: https://elan1.ai/docs The elan1 docs explain how to build on the governed write path. They start with a quickstart for a first governed write, explain core concepts, modes and assurance levels, and give references for KernelPort, the MCP server, the HTTP API, refusals, declarations, proof records, fusion.*/v1 contracts and conformance. ### Quickstart: your first governed AI agent write | elan1 URL: https://elan1.ai/docs/quickstart The quickstart walks through a first governed write: an AI agent sends a write intent, elan1 Govern checks it on the Right Path, returns an allow or a typed refusal, and writes a proof record you can read. It uses the HTTP API or the MCP server and needs a console invitation. ### Core concepts: write intents, allows and proof | elan1 URL: https://elan1.ai/docs/concepts The core concepts of elan1 fit on one page. An AI agent proposes a write intent; only elan1 Govern can turn it into an allow; any rung can return a typed refusal; a committed write is a governed action; and every outcome, allowed or refused, leaves a 16-field proof record written by the kernel. ### The Right Path: how an AI agent write is checked | elan1 URL: https://elan1.ai/docs/right-path The Right Path is the fixed sequence every write takes in elan1 Govern, from rung 0b STOP to rung 9 METERED. This page explains each rung: what it checks, how it refuses, where the autonomy check calls a named approver, and how the proof record shows which rungs a write passed. ### Mode A, Mode B and assurance levels explained | elan1 URL: https://elan1.ai/docs/modes-and-levels elan1 has two modes and three assurance levels. Mode A (Enforced) runs in-process and holds the write credential; Mode B (Attested advisory) evaluates and records over MCP or HTTP without it. Separately, L1 Guarded, L2 Attested and L3 Proven describe how strongly the evidence can be relied on. ### KernelPort v1 API reference | elan1 URL: https://elan1.ai/docs/kernelport KernelPort v1 is the only interface into the elan1 Govern kernel. It has six calls: define registers a declaration, assert submits a write intent, seal and verify work with proof-record digests, scope limits what a caller may touch, and refuse records a stop. This page gives each call's parameters and envelopes. ### MCP server reference: read, stage and act tools | elan1 URL: https://elan1.ai/docs/mcp-server The elan1 MCP server exposes 34 tools to AI agents, grouped into three classes. Read tools return data, stage tools prepare a change without committing it, and act tools submit a write intent that climbs the Right Path. This page lists each tool, its class and the refusals it can return. ### HTTP API reference: /v1 endpoints and refusals | elan1 URL: https://elan1.ai/docs/http-api The elan1 HTTP API lets any system submit write intents and read proof records over /v1 endpoints. This reference covers authentication tokens, idempotency keys that make retries safe, the response envelopes for allows and refusals, and the endpoints for reading records and verifying the chain. ### Errors and refusals: the typed refusal envelope | elan1 URL: https://elan1.ai/docs/errors-and-refusals A refusal is elan1's typed "no" to a write intent, and it is different from an error. The refusal envelope names the rung that refused and a reason code your code can act on. Errors mean the request could not be processed. This page lists both and shows how to handle each safely. ### Declarations: AI agent rules in seven blocks | elan1 URL: https://elan1.ai/docs/declarations A declaration is the rule set elan1 Govern checks every write intent against. It has seven versioned blocks covering what may change, which gates apply, the limits, the autonomy level and who approves. This page explains each block, how versions work and how the version in force is recorded in every proof record. ### Proof record spec: 16 fields, Seal v6 and chain | elan1 URL: https://elan1.ai/docs/proof-record This is the specification of elan1's proof record. It lists the 16 fields, defines the Seal v6 preimage, shows how the SHA-256 digest is computed and explains how each record carries the previous record's digest to form a chain. With it, anyone can recompute a digest and check the chain independently. ### fusion.*/v1 contracts: AI stack interfaces | elan1 URL: https://elan1.ai/docs/fusion-contracts The fusion.*/v1 contracts are the ten versioned interfaces elan1 Run places between applications and the open-source AI stack. This reference describes what each contract covers, its calls and invariants, and the two licence-clean implementations each one has, so applications can be written against the contract rather than a component. ### Conformance: K1–K7 suite and C1–C14 agent tests | elan1 URL: https://elan1.ai/docs/conformance Conformance in elan1 means passing a published suite before making a claim. The K1–K7 suite tests elan1 Run components against the fusion.*/v1 contracts, and C1–C14 test third-party AI agents that write through elan1. Both run offline, and this page explains each test and how to run it. ### Docs glossary: elan1 terms and identifiers URL: https://elan1.ai/docs/glossary-links The docs glossary gives short definitions of the terms and identifiers used across the elan1 documentation, such as write_id, rung codes, gate numbers, modes and assurance levels. Each entry links to the full definition in the main glossary and to the docs page where the identifier is used. ### Docs changelog: elan1 documentation versions URL: https://elan1.ai/docs/changelog The docs changelog lists every version of the elan1 documentation with its date and what changed. Use it to see when an API reference, contract description or rule explanation was added, corrected or clarified, and which version of a page your integration was built against. ### AI agent governance blog: notes from the build | elan1 URL: https://elan1.ai/blog The elan1 blog publishes short, dated notes from building the governed write path for AI agents, each by a named author with any corrections listed. Topics include why a refusal costs less than an allowed action, why a model may propose but never allow a write, what tamper-evident means at L1 and why systems should fail toward a human. ### Why a refusal costs 40% of a governed action | elan1 URL: https://elan1.ai/blog/why-refusals-are-free elan1 charges a refused write 40% of one governed action at the same rate. A refusal still runs the checks up to the rung that says no, returns a typed code and writes a proof record, but nothing is written to your books. So it costs less than an allowed action, and tightening a rule never makes a write intent cost more. ### AI models may propose a write, never allow it | elan1 URL: https://elan1.ai/blog/a-model-may-produce-a-write-intent-never-an-allow In elan1, a model may produce a write intent, a typed proposal to change a record, but never an allow. The allow comes only from elan1 Govern, after identity, gates, versioned rules, a guardrail, the autonomy check and, where required, a named person. Keeping models off the allow path means no model can approve its own change. ### Two crossings: where AI governance layers meet | elan1 URL: https://elan1.ai/blog/two-crossings elan1's four layers meet in only two places. Above, every write intent enters through KernelPort; below, elan1 Run reaches the open-source AI stack only through fusion.*/v1 contracts. With two crossings, there are only two places to audit, and components on either side can change without opening a new path to the system of record. ### Tamper-evident vs tamper-proof AI audit logs | elan1 URL: https://elan1.ai/blog/what-tamper-evident-means-at-l1 Tamper-evident means a change to a record can be detected, not that a change is impossible. At L1 Guarded, elan1 hash-chains every proof record, so recomputing the chain shows whether an earlier record was altered. That is why elan1 says tamper-evident, not tamper-proof or immutable: it claims only what you can check. ### Designing a 16-field audit record for AI agents | elan1 URL: https://elan1.ai/blog/designing-the-16-field-proof-record elan1's proof record has 16 fields, chosen so that an auditor can answer who asked, what was proposed, which rules ran, who approved, what happened and how the record links to the one before. The set is fixed: adding a seventeenth field would change the seal and break every verifier already in use. ### Fail toward a human: AI agents that stop and ask | elan1 URL: https://elan1.ai/blog/fail-toward-a-human Failing toward a human means that when something is missing or unclear, such as a rule, an approver or a confident answer, the AI agent's write stops and a person is asked. elan1 never fails toward an action. The stop is recorded in a proof record, so the pause itself is evidence. ### elan1 company: who builds the governed write path URL: https://elan1.ai/company elan1 is made by ELAN1 AGENTIC TECHNOLOGIES PRIVATE LIMITED, a company incorporated in 2026 in Tamil Nadu, India, with its office in T Nagar, Chennai, and founded by M. K. Elango. It builds one governed write path for AI agents, so a named person is answerable for every consequential action an agent takes. ### About elan1: AI agent governance from Chennai, India URL: https://elan1.ai/company/about elan1 is the governed write path for AI agents, built by ELAN1 AGENTIC TECHNOLOGIES PRIVATE LIMITED in Chennai, Tamil Nadu. It was founded by M. K. Elango, a strategist to family business groups, founders and large organisations in India, the Gulf and South-East Asia, who also founded StartNet Ventures, Publytics and the Think TN Foundation. Questions answered on this page: - Who founded elan1? - Where is elan1 based? - What does ELAN1 AGENTIC TECHNOLOGIES PRIVATE LIMITED do? ### Careers at elan1: build the part that says no URL: https://elan1.ai/company/careers elan1 hires people to build the part of AI systems that says no: the rule checks, approvals and proof records between AI agents and business records. The company is based in Chennai, Tamil Nadu. This page explains how elan1 hires, what it values and how to apply. ### AI governance design partner programme | elan1 URL: https://elan1.ai/company/design-partners The elan1 design partner programme puts one real process on the governed write path with the elan1 team. It has ten places and a 30-minute call every two weeks. elan1 Work is ₹0 for 90 days within fair use of 20,000 credits a month, followed by a 12-month price lock. Questions answered on this page: - Who can become a design partner? - What does it cost? - What is expected of a design partner? ### elan1 news: announcements, with their evidence URL: https://elan1.ai/company/news elan1 news publishes announcements with the evidence behind them. Recent posts cover the availability of all four platforms, elan1 Govern, Work, Decide and Run; the opening of the design partner programme; the one-masterbrand, four-layer brand architecture; and the publication of the claims register and roadmap. ### elan1 Govern, Work, Decide and Run are available URL: https://elan1.ai/company/news/four-platforms-available elan1 Govern, Work, Decide and Run are available. The four platforms make up one governed write path for AI agents: Govern checks and records every write, Work runs governed agents on ERPNext, Decide routes calibrated decisions by risk, and Run operates the open-source AI stack. L1 Guarded and L2 Attested are available. ### elan1 opens its design partner programme URL: https://elan1.ai/company/news/design-partner-programme-opens elan1 has opened its design partner programme. Ten organisations can each put one real process on the governed write path for AI agents, meet the team for 30 minutes every two weeks, and use elan1 Work at ₹0 for 90 days within fair use, followed by a 12-month price lock. ### Brand architecture: one masterbrand, four layers | elan1 URL: https://elan1.ai/company/news/one-masterbrand-four-layers elan1 uses one masterbrand with four layers: elan1 Govern, elan1 Work, elan1 Decide and elan1 Run. Modules, Work lines and assurance levels are always named with their platform, never as separate brands, so a buyer can tell at a glance which layer does what and which one writes. ### We publish our claims register and what comes next | elan1 URL: https://elan1.ai/company/news/public-roadmap-and-claims-register elan1 has published its claims register and roadmap. The register lists each claim the company makes about its products with the assurance level at which it becomes true, such as tamper-evident at L1 and signed from L2. The roadmap lists what improves next, in order, with no invented dates. ### Contact elan1: talk to a person about AI agents URL: https://elan1.ai/contact To contact elan1, write to elango@elan1.ai or use the form; a person replies within two working days. Grievances, legal notices and legal action under the DPDP Act go to Hariharan at hariharan@elan1.ai. The office is at 114, B Block, Second Floor, Sir Theagaraya Road, T Nagar, Chennai 600017. Questions answered on this page: - How quickly will someone reply? - Who handles grievances and legal matters? - Can I see a demo? ### Legal: privacy, terms, cookies and grievances | elan1 URL: https://elan1.ai/legal elan1's legal pages set out the rules for elan1.ai in plain words: a privacy notice under the DPDP Act, 2023, website terms of use, a cookie notice and the grievance officer's details. Legal notices, legal action and DPDP Act matters are handled by Hariharan. The documents are effective from 10 October 2026. ### Privacy notice under the DPDP Act, 2023 | elan1 URL: https://elan1.ai/legal/privacy This privacy notice explains how ELAN1 AGENTIC TECHNOLOGIES PRIVATE LIMITED handles personal data under the Digital Personal Data Protection Act, 2023: when it acts as Data Fiduciary or Data Processor, why it collects data, how long it keeps it, your rights, and how Hariharan handles grievances and legal matters. ### Website terms of use for elan1.ai URL: https://elan1.ai/legal/terms These terms govern use of the elan1.ai website. They explain that the site is information, not an offer, warranty or legal advice; set out acceptable use, intellectual property and liability; and state that legal notices go to Hariharan and that the courts at Salem, Tamil Nadu have jurisdiction. ### Cookie notice: what elan1.ai stores and why URL: https://elan1.ai/legal/cookies This cookie notice lists the cookies and local storage elan1.ai uses, what each is for and how long it lasts. Essential storage keeps the site working; anything non-essential stays off until you agree. You can change your choice at any time from the cookie settings link in the footer. ### Grievance officer for IT Act and DPDP Act matters | elan1 URL: https://elan1.ai/legal/grievance-officer elan1's grievance officer is Hariharan, reachable at hariharan@elan1.ai or by post to the office in T Nagar, Chennai. He handles grievances under the IT Act, 2000 and the DPDP Act, 2023, and also legal notices and any legal action under the DPDP Act. Grievances are resolved within one week of receipt. ### Accessibility statement for elan1.ai URL: https://elan1.ai/accessibility This statement explains how elan1.ai is built to be accessible: the standard it aims for, the checks it runs, such as keyboard operation, visible focus, reduced motion and real tables, any known limits, and how to report a barrier so a person can fix it. ### elan1 service status for Govern, Work, Decide and Run URL: https://elan1.ai/status This page shows the current service status of elan1 Govern, Work, Decide and Run. Any incident is described in plain words, with what is affected and what to do. If something is not working and this page does not show it, write to elango@elan1.ai. ### AI agent governance guides: practical, sourced | elan1 URL: https://elan1.ai/guides elan1 guides are long-form, sourced explainers for teams putting AI agents to work on real records. They cover AI agent governance, human-in-the-loop approval, audit trails, MCP security, the EU AI Act, India's MCA audit trail rule and AI governance guidelines, Tally to ERPNext migration, and AI for chartered accountants. ### AI agent governance: a practical guide for 2026 | elan1 URL: https://elan1.ai/guides/ai-agent-governance AI agent governance is the set of controls that decides what an AI agent may change, who must approve it and what evidence is kept. For agents that write to business systems, it works best at the write itself: one path every change must take, with rules, a named approver and a tamper-evident record. Questions answered on this page: - What is AI agent governance? - How is it different from AI model governance? - What are guardian agents? - Should AI agents have write access to production? - Where should I start? ### Human-in-the-loop for AI agents that isn't theatre | elan1 URL: https://elan1.ai/guides/human-in-the-loop-ai-agents Human-in-the-loop for AI agents means a named person decides before a consequential change is made, with enough context to say no. It fails when approvers rubber-stamp unreadable requests. It works when approval is reserved for changes above a risk threshold, the approver is not the requester, and each decision is recorded. Questions answered on this page: - What is human-in-the-loop for AI agents? - When is human approval theatre? - What is maker-checker for AI? - How do I avoid approval fatigue? - What does the EU AI Act say about human oversight? ### AI agent audit trail: what to record, field by field | elan1 URL: https://elan1.ai/guides/ai-agent-audit-trail An AI agent audit trail is a record of every action an agent proposed, the rules that were checked, who approved it and what happened, linked so later changes can be detected. Most teams log tool calls but not the policy decision. A useful trail records both, including refused actions. Questions answered on this page: - What should an AI agent audit trail record? - Is logging tool calls enough? - What is the difference between tamper-evident and immutable? - How long should AI agent logs be kept? - Can an auditor verify the trail without the vendor? ### EU AI Act and AI agents: logging and oversight | elan1 URL: https://elan1.ai/guides/eu-ai-act-ai-agents The EU AI Act does not regulate AI agents as a category; it regulates AI systems by risk. An agent used in a high-risk area, such as credit scoring or employment, must log events automatically (Article 12), support human oversight (Article 14), and its deployer must keep those logs (Article 26). Questions answered on this page: - Are AI agents regulated by the EU AI Act? - What does Article 12 require? - What does Article 14 require? - Does the EU AI Act apply to Indian companies? - When do high-risk obligations apply? ### MCA audit trail Rule 3(1) explained for AI-era books | elan1 URL: https://elan1.ai/guides/mca-audit-trail-rule-3-1 India's MCA audit trail rule, the proviso to Rule 3(1) of the Companies (Accounts) Rules, 2014, requires companies to use accounting software that records an audit trail of every transaction, with an edit log of each change and its date, that cannot be disabled. Auditors report on it under Rule 11(g). Questions answered on this page: - What is the MCA audit trail rule? - Which companies must comply? - What must the edit log record? - How long must the audit trail be kept? - What changes when an AI agent posts entries? ### Tally to ERPNext migration: a step-by-step guide | elan1 URL: https://elan1.ai/guides/tally-to-erpnext-migration Moving from Tally to ERPNext means exporting masters and balances from Tally, mapping them to ERPNext's chart of accounts, parties, items and tax templates, importing them in a dry run, reconciling the trial balance and GST figures, and going live only after your chartered accountant signs off the tie-out. Questions answered on this page: - How long does a Tally to ERPNext migration take? - Can I keep my GST history? - What data moves and what does not? - Do I need my CA involved? - What does it cost? ### MCP server security and governance for write tools | elan1 URL: https://elan1.ai/guides/mcp-server-governance Securing an MCP server whose tools can write means treating each tool by what it can change. Separate read, stage and act tools, keep write credentials away from the agent, require approval for act tools above a risk threshold, and record each act call with the policy decision. Questions answered on this page: - What are the main MCP security risks? - How should MCP write tools be approved? - Should the agent hold the credential? - How do I audit MCP tool calls? - Can I govern an MCP server I did not build? ### AI for chartered accountants in India: a guide | elan1 URL: https://elan1.ai/guides/ai-for-chartered-accountants Chartered accountants in India can use AI to draft entries, reconcile GST data and prepare returns, provided every change to a client's books is reviewed, attributable and recorded. The safe pattern is an AI agent that proposes, a CA who approves consequential changes, and an audit trail the CA can read. Questions answered on this page: - Which AI tools can chartered accountants use? - Can AI post entries in client books? - How does AI affect the MCA audit trail? - Who is responsible for an AI-made entry? - How should a CA firm price AI-assisted work? ### RBI FREE-AI and India's AI governance guidelines | elan1 URL: https://elan1.ai/guides/india-ai-governance-rbi-free-ai RBI's FREE-AI framework, published in August 2025, sets out principles and recommendations for responsible AI in Indian financial services, and MeitY's India AI Governance Guidelines of November 2025 set principles for all sectors. Neither is a single statute; both expect board oversight, risk-based controls, human accountability and auditable records. Questions answered on this page: - What is RBI's FREE-AI framework? - Is FREE-AI binding on banks and NBFCs? - What are MeitY's India AI Governance Guidelines? - How does the DPDP Act apply to AI? - What evidence should a bank keep for AI decisions? ### AI for AML alert triage and KYC review | elan1 URL: https://elan1.ai/guides/aml-kyc-ai-triage AI can triage AML alerts and KYC reviews by scoring each case and routing it by risk, provided its confidence is calibrated on the institution's own cases. High-confidence low-risk cases can be prepared automatically; everything else goes to an analyst, and every decision, with its route and reviewer, is recorded. Questions answered on this page: - Can AI close AML alerts on its own? - What is calibrated confidence? - How do regulators view AI in AML? - How do I audit AI-assisted KYC decisions? - Where should a human always decide? ## Guides (full text) ### AI agent governance: a practical guide for 2026 URL: https://elan1.ai/guides/ai-agent-governance Author: M. K. Elango · Published 2026-10-10 · Updated 2026-10-10 AI agent governance is the set of controls that decides what an AI agent may change, who must approve it and what evidence is kept. For agents that write to business systems, it works best at the write itself: one path every change must take, with rules, a named approver and a tamper-evident record. Key takeaways: - Govern the action, not only the model: the risk of an AI agent sits in what it can change, so controls belong where a change is decided. - Five controls cover most of the ground: an inventory of agents, an identity per agent, versioned rules, human approval above a risk threshold, and evidence for every action. - Start small: in 30 days you can list your agents, classify their actions, put consequential writes on one path and begin collecting evidence. #### What AI agent governance means An AI agent is software that takes a goal, decides on steps and calls tools to carry them out. Some of those tools only read: they search, summarise or look up a record. Others write: they post a journal entry, change a price, refund an order or update a customer's address. AI agent governance is the set of controls that decides what an agent may change, who must approve it and what evidence is kept afterwards. It overlaps with AI model governance but is not the same thing. Model governance asks whether a model is fit for purpose: how it was trained, how it performs, whether it is biased, who signed off its release. Agent governance asks a narrower, more operational question each time the agent acts: should this specific change happen, now, under these rules, and can we prove afterwards what happened? A well-governed model can still be wired into an agent that has too much access. The distinction matters because most governance programmes were built for models that produce text or scores for a person to read. An agent removes that person from the loop unless you put them back deliberately. This guide is about putting the controls where agents act. #### Why agents that write change the risk A wrong answer from a chatbot is a quality problem: someone reads it, doubts it and moves on. A wrong write from an agent is an operational problem: the ledger is now wrong, the customer has been refunded twice, the stock count no longer matches the shelf. The cost of a mistake moves from embarrassment to correction, reconciliation and, sometimes, a regulator's question. The OWASP Top 10 for LLM Applications 2025 names this risk “Excessive Agency” (LLM06) and traces it to three root causes: too much functionality, too many permissions and too much autonomy. All three are properties of the agent's wiring, not of the model. That is good news, because wiring is something you control. A practical rule follows. Sort every tool an agent can call into reads and writes, then split the writes into routine changes within limits and consequential changes. Reads need access control. Routine writes need limits and a record. Consequential writes need a decision, by rules and, above a threshold, by a named person. #### The five controls: inventory, identity, rules, approval, evidence Across frameworks and vendors, the same five controls keep appearing. You can implement them with any stack. ##### 1. Inventory List every agent in use, who owns it, which systems it can reach and which tools it can call. Include agents built into SaaS products you already pay for. Most organisations find more agents than they expected, many with write access granted for a pilot and never removed. ##### 2. Identity Give each agent its own identity, separate from the person who runs it, and record both on every action: the agent that proposed the change and the person or process it acted for. Shared service accounts make it impossible to say afterwards which agent did what. ##### 3. Rules Write down what each agent may change, within what limits and under which conditions, as versioned rules a machine can check. A policy document that says “agents must not make material changes without approval” is a statement of intent; a rule that says “journal entries above ₹50,000 to accounts in group 4 need an approver” can be tested on every write. ##### 4. Human approval Above a risk threshold, a named person who is not the requester decides, with enough context to say no. Below the threshold, the agent works within limits. The threshold is the design decision; asking for approval on everything produces rubber-stamping. ##### 5. Evidence Keep a record of every action the agent proposed, which rules were checked, who approved it and what happened, including the actions that were refused. Link the records so a later edit is detectable. Evidence is what turns a governance programme into something an auditor can test. #### Five failure patterns to look for first Before designing anything new, look for the patterns that cause most agent incidents. Each one is cheap to find and usually cheap to fix. - Shared service accounts. Several agents, or an agent and a batch job, write with the same credential. Nobody can say afterwards which one made a change. - Pilot permissions that never expired. Write access granted for a proof of concept is still live months later, often broader than the pilot needed. - Prompt-only controls. The only thing standing between the agent and a payment is an instruction in its system prompt. Instructions steer; they do not bind. - Approvals by the requester. The person who asked the agent to act is the one who clicks approve, so the approval adds no independent check. - Logs nobody can verify. Records live only in a vendor dashboard or in a database the agent's operators can edit, so they cannot serve as evidence. If you find any of these, fix them before adding new agents. #### Where to enforce: prompts, tool permissions or the write path There are three places to put controls on an agent, and they are not interchangeable. [Figure] Three layers of control. Prompt guardrails and tool permissions narrow what an agent tries; only a check on the write itself sees, and can stop, the specific change. Where each control sits, and what it can and cannot do: | Layer | What it does well | What it cannot do | | Prompt guardrails | Steer the model away from unwanted topics and formats; filter obvious misuse. | Bind the agent. A manipulated input or an unexpected plan can route around instructions. | | Tool permissions | Remove tools the agent does not need; scope credentials to systems and objects. | Judge an individual change. A permission to post journal entries allows every journal entry. | | Governed write path | Check each proposed change against rules, hold it for a named approver above a threshold, record the outcome. | Make a model smarter. It decides on changes; it does not improve the agent's reasoning. | Use all three, but rely on the third for anything consequential. The strongest version is a single path that every change must take, where the agent never holds the write credential itself: it proposes, and a separate component that does hold the credential commits only what the rules allow. If an agent can reach the system of record by another route, the path is advisory. #### Guardian agents and AI TRiSM: what the analyst categories mean Analysts have started naming this market. Gartner uses “AI TRiSM” (AI trust, risk and security management) for the broad discipline and, in a June 2025 press release, described “guardian agents” as technologies that oversee other agents and can redirect or block their actions. For a buyer, the labels matter less than three questions you can ask any product in the category: - Does it see the action or only the conversation? Monitoring prompts and outputs is useful, but only a control that sees the proposed change can stop it. - Is its decision deterministic where it needs to be? Using one model to supervise another is useful for triage. For an allow or a refusal on a consequential write, you want rules you can read and test, plus a named person above the threshold. - What evidence does it leave, and can you check it without the vendor? A dashboard is not evidence. Records you can export, verify and hand to an auditor are. #### Human approval that works Human-in-the-loop is the control most often promised and least often designed. It fails in predictable ways: approvers are asked about everything, so they approve everything; the request is a wall of model output rather than a clear diff; the person approving is the person who asked. It works when approval is reserved for changes above a threshold set by value, reversibility and blast radius; when the approver sees exactly what will change and which rule caused the hold; when the approver is a named person other than the requester; and when the system stops and asks a person whenever something is missing, rather than proceeding. Our guide to human-in-the-loop for AI agents covers thresholds, maker-checker and approval fatigue in detail. #### The evidence an auditor will ask for Auditors test whether controls operate, not whether they exist on paper. For agents, that means a record for each action that answers six questions: who or what asked, what was proposed, which rules ran and in which version, who approved or refused, what changed, and how this record links to the one before it so an edit would show. Two details separate useful trails from logs. First, record the policy decision, not only the tool call: a log that shows an API was called does not show why it was allowed. Second, record refusals, because a control that never refuses anything cannot be shown to work. The AI agent audit trail guide goes through the fields one by one. #### Regulation map: what the main frameworks expect No framework regulates “AI agents” as a separate category yet. They regulate AI systems by risk or set management-system expectations, and agents inherit those duties. The table maps the five controls to the main sources, as of October 2026. Where the five controls show up in law and standards: | Framework | What it expects that applies to agents | Status | | EU AI Act, Regulation (EU) 2024/1689 | For high-risk systems: automatic logging (Article 12), design for human oversight (Article 14), deployers to keep logs and assign competent overseers (Article 26). | In force. High-risk duties for Annex III systems apply from 2 December 2027 after Regulation (EU) 2026/1744. | | ISO/IEC 42001:2023 | An AI management system with defined roles, risk treatment and operating controls, including event logging in Annex A. | Voluntary, certifiable standard. | | NIST AI RMF 1.0 (NIST AI 100-1) | Four functions, Govern, Map, Measure and Manage, including defined human oversight processes. | Voluntary framework. | | India: DPDP Act, 2023 and Rules, 2025 | Purpose limitation, security safeguards and accountability when agents process personal data. | Rules notified November 2025; most duties apply from May 2027. | | India: MeitY AI Governance Guidelines | Seven principles, including accountability and “people first”, with human oversight and grievance redressal. | Guidelines, released 5 November 2025. | For the detail, see EU AI Act Articles 12 and 14 for AI agents, ISO 42001 audit evidence for AI agents and NIST AI RMF for AI agents. #### A 30-day plan You do not need a programme office to start: one owner, one process and four weeks. 1. Week 1: inventory. List every agent, its owner, its tools and the credentials it holds. Remove write access nobody can justify. 2. Week 2: classify actions. For one business process, sort each tool call into read, routine write and consequential write. Agree the threshold with the process owner. 3. Week 3: one write path. Route the consequential writes through a single checkpoint that applies versioned rules and holds changes above the threshold for a named approver. Take the write credential away from the agent. 4. Week 4: evidence. Confirm every action, allowed or refused, leaves a linked record. Ask someone outside the team to check a week of records without your help. At day 30 you should be able to show three things to someone outside the team: a current list of agents and their access, a written threshold for one process, and a week of linked records, including at least one refusal, that they can check on their own. That is real evidence, and it scales one process at a time. Two free tools help: the 12-question AI agent readiness assessment, and a set of RFP questions for AI agents that write for when you buy rather than build. #### How elan1 handles this elan1 is a governed write path for AI agents. Agents and our own products propose changes as write intents; only elan1 Govern can allow one. Every write climbs the Right Path: identity, nine pre-gates, versioned rules, a blast-radius guardrail and an autonomy check, then a named approver where your rules ask. The outcome, allowed or refused, is written to a 16-field proof record, SHA-256 hash-chained so that a change to an earlier record is evident. In Mode A, where the credential is held by elan1 and the agent never has it, the rules are enforced. Over MCP or HTTP without the credential (Mode B), every intent is still evaluated and recorded, but enforcement stays with your system. Records are tamper-evident at L1 Guarded; from L2 Attested they are signed, and an auditor can check them offline. A refusal costs 40% of one governed action. See AI agent governance with human approval for the detail. #### Frequently asked questions Q: What is AI agent governance? A: AI agent governance is the set of controls that decides what an AI agent may change, who must approve it and what evidence is kept. In practice that means an inventory of agents, an identity per agent, versioned rules, human approval above a risk threshold and a linked record of every action. Q: How is it different from AI model governance? A: Model governance asks whether a model is fit for purpose: its training, testing and performance. Agent governance asks, each time an agent acts, whether that specific change should happen and how you will prove what happened. A well-tested model can still be connected to an agent with too much access, so you need both. Q: What are guardian agents? A: Guardian agents is Gartner's term for technologies that oversee other AI agents and can redirect or block their actions. When assessing one, ask whether it sees the proposed action or only the conversation, whether its decisions on consequential writes are deterministic, and whether its records can be checked without the vendor. Q: Should AI agents have write access to production? A: Only through a governed path. An agent may propose changes to production systems, but consequential writes should pass a rule check, be held for a named approver above a threshold and be committed by a component that holds the credential, so the agent itself never does. Reads and routine writes within limits can be granted more freely. Q: Where should I start? A: Start with an inventory: list every agent, its owner, the tools it can call and the credentials it holds, and remove write access nobody can justify. Then pick one process, classify its actions into reads, routine writes and consequential writes, and put the consequential ones on a single checked and recorded path. #### Sources [1] Regulation (EU) 2024/1689 (Artificial Intelligence Act), EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj [2] Regulation (EU) 2026/1744 (Digital Omnibus on AI), amending the AI Act, EUR-Lex. https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng [3] ISO/IEC 42001:2023, Artificial intelligence — Management system, ISO. https://www.iso.org/standard/81230.html [4] NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST. https://doi.org/10.6028/NIST.AI.100-1 [5] LLM06:2025 Excessive Agency, OWASP Top 10 for LLM Applications 2025, OWASP GenAI Security Project. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/ [6] Gartner Predicts that Guardian Agents will Capture 10-15% of the Agentic AI Market by 2030 (press release, 11 June 2025), Gartner. https://www.gartner.com/en/newsroom/press-releases/2025-06-11-gartner-predicts-that-guardian-agents-will-capture-10-15-percent-of-the-agentic-ai-market-by-2030 [7] India AI Governance Guidelines (5 November 2025), Ministry of Electronics and Information Technology, via PIB. https://static.pib.gov.in/WriteReadData/specificdocs/documents/2025/nov/doc2025115685601.pdf ### Human-in-the-loop for AI agents that isn't theatre URL: https://elan1.ai/guides/human-in-the-loop-ai-agents Author: M. K. Elango · Published 2026-10-10 · Updated 2026-10-10 Human-in-the-loop for AI agents means a named person decides before a consequential change is made, with enough context to say no. It fails when approvers rubber-stamp unreadable requests. It works when approval is reserved for changes above a risk threshold, the approver is not the requester, and each decision is recorded. Key takeaways: - Ask a person only above a threshold set by value, reversibility and blast radius. Approval on everything produces approval of everything. - The approver must be a named person who is not the requester, and must see the exact change, the rule that triggered the hold and the consequence. - When anything is missing, such as a rule, an approver or a confident input, the system should stop and ask a person, and record that it did. #### What human-in-the-loop means for AI agents Human-in-the-loop (HITL) is used loosely, so it helps to separate three arrangements. In the loop: a person decides before the agent's action takes effect. On the loop: the agent acts, and a person monitors and can intervene or reverse. Out of the loop: the agent acts and nobody looks, except perhaps in a later sample. All three have a place. Reading a document needs nobody. Drafting an invoice can run with a person on the loop. Posting a ₹40 lakh payment, closing a fraud alert or changing a customer's bank details should have a person in the loop. The design question is not whether to have human approval, but which actions get which arrangement, and why. For agents, in-the-loop approval has a precise meaning in this guide: a named person decides before a consequential change is made, with enough context to say no, and that decision is recorded. #### Why most human-in-the-loop is theatre Approval steps fail in four recognisable ways. - Everything is asked. When every action needs a click, approvers learn that clicking is the job. Volume turns review into ritual. - The request is unreadable. The approver sees a paragraph of model output, not a before-and-after view of the record. A person cannot meaningfully refuse what they cannot read. - The requester approves. If the person who asked the agent to act is also the one who approves, the approval adds no independent check. - Automation bias. People tend to accept a system's suggestion, especially under time pressure. Research on human use of automation, such as Parasuraman and Manzey (2010), describes this complacency and bias in detail. The EU AI Act names the last of these directly: Article 14 requires that people overseeing a high-risk system remain aware of the tendency to over-rely on its output. A design that ignores these failure modes produces records of approvals that prove very little. #### Who should approve: maker-checker Banking solved a version of this problem long ago with the maker-checker principle: one person prepares a transaction and a different person authorises it. For AI agents, the model is the maker. The checker must be a person who is independent of the request, competent to judge it and has the authority to refuse. Three practical rules help. Name the approver by role and by person, so the record shows who decided, not just that someone did. Prevent self-approval in the system, not by policy alone. And give approvers the authority to say no without escalation, otherwise refusal is theoretical. Article 26 of the EU AI Act asks deployers of high-risk systems to assign oversight to people with the necessary competence, training and authority, which is the same idea in legal form. For high-stakes cases, use two checkers. The AI Act itself does this for remote biometric identification: under Article 14(5), no action is taken on an identification unless at least two competent people have verified it separately. See how a named approver works for operations teams, and maker-checker for banks for decisions on alerts and disputes. #### When to ask: autonomy levels and risk thresholds Decide the threshold per process, before the agent goes live, and write it down as a rule. Five factors set it. Factors that decide whether a change needs a person: | Factor | Lower risk | Higher risk | | Value | Small amounts within a tested limit | Amounts above a set limit, or cumulative value in a period | | Reversibility | Easy to undo with a reversing entry | Payments sent, messages delivered, data deleted | | Blast radius | One record | Many records, a master record, or another party's system | | Novelty | A pattern the agent has done many times | A first-time counterparty, account or action type | | Confidence | Inputs complete; calibrated confidence high | Missing data, conflicting sources, low confidence | ##### An example: accounts payable Take an agent that prepares supplier payments for a fictional manufacturer, Kolam Components*. A sensible first design might let it prepare any payment, pay invoices under ₹50,000 to known suppliers within agreed terms on its own, and hold everything else: payments above ₹50,000, any first payment to a new supplier, any change to a supplier's bank details, and any payment where the invoice and the purchase order disagree. The bank-detail rule matters most, because it is the classic route for payment fraud and the change is hard to reverse once money has left. Review the thresholds after a month. If the controller approves 300 payments a week and refuses none, the threshold is probably too low; if refusals cluster on one rule, that rule or the agent's data needs attention. Illustrative specimen. Not customer data: the figures are examples, so set yours with the process owner and your auditors. Many teams express the result as an autonomy level per process, from “propose only” to “act within limits and report”. Whatever scale you use, record the level that applied on every action, so a reader can see why a person was or was not asked. [Figure] A simple approval flow. The threshold decides whether a person is asked; anything missing stops the change; every outcome is recorded. #### What the approver must see An approval request should answer five questions on one screen, in this order: 1. What will change: the record, the field, the old value and the new value, as a diff. 2. Why it was held: the rule and its version that triggered the hold, in plain words. 3. What happens next: the consequence of approving, such as “₹4,20,000 leaves the current account on 14 October”. 4. Who asked and for whom: the agent, the person or process it acted for, and the reason it gave. 5. What refusing does: the change does not happen, and the requester is told why. Anything else is optional context. Approvers who must scroll through a model's reasoning to find the amount will stop reading. For an example of the layout, see a write held for a named approver, an illustrative specimen. #### Failing toward a human Most incidents happen at the edges: the rule that does not cover a new case, the approver on leave, the confidence score that is missing because an upstream service timed out. The safe default is to stop the change and ask a person, never to proceed because nothing said no. Write this as an explicit rule: if no rule matches, if no approver is reachable within the time limit, or if a required input is missing, the change waits. Record the stop as an outcome in its own right. A pause that is recorded is evidence that the control works. We explain the reasoning in fail toward a human. #### Approval channels and step-up Approvals arrive by console, email, chat app or phone. More channels mean faster decisions but also more ways to impersonate an approver. Two rules keep channels honest. First, every channel reaches the same approval, with the same checks and the same record; a channel adds reach, not power. Second, apply step-up authentication in proportion to the change: a high-value approval by phone should require a stronger check than a routine one in a logged-in console. Plan for absence. Every approver role needs a named deputy, set up in advance rather than improvised when someone is on leave. Delegation should itself be recorded, with its start and end dates, so that a reader can see why a deputy approved a given change. Never let an absent approver turn into an approval by default. Set time limits too. An approval request that waits indefinitely invites someone to find a workaround. When the limit passes, the change should expire or escalate to a named deputy, and the record should show which. #### Recording the decision so it counts as evidence An approval that is not recorded is an opinion. The record should hold who approved or refused, when, through which channel, against which rule version, what they were shown and what happened next. Link each record to the one before it so later edits are detectable, and keep refused and expired requests as well as approved ones. Before going live, check the design against a short list: - Each process has a written threshold, agreed with its owner, and the rule that implements it is versioned. - Approvers are named, with deputies, and the system prevents a requester from approving their own change. - The approval screen shows the diff, the rule that held the change and its consequence on one view. - Missing rules, unreachable approvers and missing inputs stop the change rather than letting it through. - Every channel reaches the same approval with step-up for high-value changes. - Approved, refused and expired requests are all recorded and linked. Then measure the control itself. Track approval rates, time to decide and the share of approvals made in under a few seconds. A rate near 100% with very fast decisions suggests the threshold is too low or the request too hard to read. #### What the EU AI Act's Article 14 adds Article 14 of Regulation (EU) 2024/1689 requires high-risk AI systems to be designed so that people can oversee them effectively. The people assigned must be able to understand the system's capacities and limits, stay aware of over-reliance, interpret its output, decide not to use or to override it, and interrupt it through a stop procedure. Deployers must assign that oversight to competent people under Article 26. Following the amendments in Regulation (EU) 2026/1744, these duties apply to Annex III high-risk systems from 2 December 2027. Even where your agent is not high-risk, Article 14 is a useful checklist for designing approvals. Our page on EU AI Act Article 14 maps it to controls, and the NIST AI RMF asks for the same thing in voluntary form: defined roles for human-AI configurations and documented oversight processes. #### How elan1 handles this In elan1 Govern, every process has a declaration that sets its rules and its autonomy level. A write the rules mark as consequential is held at the autonomy rung for a named approver, and your rules can require that the approver is someone other than the requester. The approver sees exactly what will change before saying yes. If a rule, an approver or a confident input is missing, the write stops and a person is asked. Approvals can be given in the console or by phone through elan1 Work Voice, which lets a named approver approve by voice with the same checks and step-up as the console. Every outcome, allowed or refused, is written to a hash-chained proof record that is tamper-evident at L1 Guarded, and signed from L2 Attested. #### Frequently asked questions Q: What is human-in-the-loop for AI agents? A: It means a named person decides before an AI agent's consequential change takes effect, with enough context to say no. Routine changes within tested limits can run without a person, while consequential ones are held for approval and every decision is recorded. Q: When is human approval theatre? A: Approval becomes theatre when people are asked about everything, when the request is unreadable, when the requester approves their own change, or when approvers simply accept the system's suggestion. The result is a record of clicks rather than decisions. Q: What is maker-checker for AI? A: Maker-checker means one party prepares a change and a different, named party approves it. For AI, the model or agent is the maker and a competent person who is independent of the request is the checker, with the authority to refuse. Q: How do I avoid approval fatigue? A: Raise the threshold so that only consequential changes reach a person, and make each request readable as a clear before-and-after view with the rule that held it. Then monitor approval rates and decision times: near-total approval in a few seconds is a sign of fatigue. Q: What does the EU AI Act say about human oversight? A: Article 14 requires high-risk AI systems to be designed for effective human oversight: people must understand the system, stay alert to over-reliance, be able to override it and be able to stop it. Article 26 requires deployers to assign that oversight to competent people; for Annex III systems these duties apply from 2 December 2027. #### Sources [1] Regulation (EU) 2024/1689 (Artificial Intelligence Act), Articles 14 and 26, EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj [2] Regulation (EU) 2026/1744 (Digital Omnibus on AI), EUR-Lex. https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng [3] NIST AI 100-1, AI Risk Management Framework 1.0 (Govern 3.2, Map 3.5), NIST. https://doi.org/10.6028/NIST.AI.100-1 [4] ISO/IEC 42001:2023, Annex A controls on the use of AI systems, ISO. https://www.iso.org/standard/81230.html [5] LLM06:2025 Excessive Agency, OWASP Top 10 for LLM Applications 2025, OWASP GenAI Security Project. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/ [6] Complacency and Bias in Human Use of Automation: An Attentional Integration (Parasuraman and Manzey, Human Factors, 2010), SAGE. https://doi.org/10.1177/0018720810376055 ### AI agent audit trail: what to record, field by field URL: https://elan1.ai/guides/ai-agent-audit-trail Author: M. K. Elango · Published 2026-10-10 · Updated 2026-10-10 An AI agent audit trail is a record of every action an agent proposed, the rules that were checked, who approved it and what happened, linked so later changes can be detected. Most teams log tool calls but not the policy decision. A useful trail records both, including refused actions. Key takeaways: - Record the policy decision, not only the tool call: which rules ran, in which version, and who approved or refused. - Record refused actions too. A control that never refuses anything cannot be shown to work. - Link each record to the one before it, so any later change is detectable, and make sure an auditor can check the chain without your vendor. #### What an AI agent audit trail is An AI agent audit trail is the record of what an agent tried to do and what happened as a result. For each action it captures who or what asked, what change was proposed, which rules were checked, who approved or refused it, and the outcome. The records are linked in order, so that if anyone edits or removes one later, the break is detectable. It differs from an application log in purpose. An application log helps engineers debug; it is verbose, rotated and often edited by the people it describes. An audit trail is evidence: it is written for a reader who was not there, such as an internal auditor, a statutory auditor, a regulator or a court, and it has to stand up on its own. #### Why logging tool calls is not enough Most teams start by logging the agent's tool calls: the function name, the arguments and the response. That shows what the agent did, but not why it was allowed to. If an agent posted a ₹6 lakh journal entry, the tool-call log tells you the entry was posted. It does not tell you whether a rule should have held it, whether anybody approved it, or which version of the policy was in force that day. The missing piece is the policy decision. A useful trail records, for every proposed action, the rules evaluated, the result of each, the threshold that applied and the approval, if any. Without it, an auditor can confirm that changes happened but cannot test whether the controls around them operated, and testing controls is the auditor's job. #### The minimum fields, one by one Whatever system you use, each record should be able to answer the questions below. The names are illustrative; the content is what matters. Minimum fields for an AI agent audit record: | Field | What it holds | Why an auditor needs it | | Actor | The agent's own identity and version | Distinguishes one agent from another, and from people | | On behalf of | The person, role or process the agent acted for | Accountability sits with a person or process, not a model | | Intent | The proposed change: object, field, old and new value | Shows what was asked, even if it never happened | | Target | The system and record the change was aimed at | Ties the evidence to the books or system it affects | | Rules version | The identifier of the rule set in force | Lets a reader re-run the decision against the same rules | | Checks and results | Each check that ran and whether it passed | Shows the control operated, not just that it exists | | Approver | The named person who approved or refused, and when | Evidence of human oversight, with independence visible | | Outcome | Allowed and committed, refused, held or stopped | Includes the actions that did not happen | | Timestamps | When proposed, decided and committed | Sequence and timeliness, for example for a period close | | Previous digest | A hash of the preceding record | Links records so a later edit or deletion is detectable | ##### Where the trail lives Keep the trail out of reach of the thing it records. The agent, and the people who operate it, should be able to append records but not edit or delete them, and access to the trail should itself be logged. ICAI's implementation guide on the MCA audit trail makes the same point for accounting software: access to the audit trail and its back-ups should be restricted, and changes to its configuration authorised and logged. Store the trail in the jurisdiction its law requires; for Indian books of account, that means records accessible in India at all times. Keep the set fixed once you publish it. If fields change every quarter, every verifier and every auditor's test script has to change with them. #### Record refusals too A trail that only contains allowed actions describes what happened, but not what the controls prevented. Refusals are the evidence that a control operates: the payment held because the counterparty was new, the journal stopped because the period was closed, the change blocked because no approver was available. Refusals also tell you where agents are being pointed at work they should not do. A cluster of refusals at the same rule is either a misconfigured agent or a rule that needs revisiting, and both are worth knowing. Record them in the same chain, with the same fields, and never charge for them or hide them in a separate log. #### Tamper-evident, tamper-proof and immutable: what each can honestly mean Vendors use these words loosely. They make different claims, and only one of them is easy to test. Three claims about audit logs: | Word | The claim | How you could test it | | Tamper-evident | A change to a past record can be detected. | Recompute the links. If a record was altered or removed, the chain no longer verifies. | | Tamper-proof | A change is impossible. | You cannot test impossibility. Anyone with enough access to the storage can rewrite it. | | Immutable | The storage will not allow changes. | Only as strong as the storage settings and the people who administer them. | Write-once storage and retention locks are useful, and you should use them where you can. But for evidence, the claim that matters is detection: if the records were changed, can someone outside your team tell? That is a property you can demonstrate, which is why careful vendors claim tamper-evidence rather than tamper-proofing. We go deeper in what tamper-evident means at L1. #### Hash chains and signatures: how detection works A hash chain is the simplest detection mechanism. Each record includes a cryptographic digest, such as SHA-256, of the record before it. Change one byte of an earlier record and its digest changes, so the next record's link no longer matches, and nor does any link after it. Certificate Transparency logs, described in RFC 6962, use a related structure, a Merkle tree, to make public logs auditable at scale. [Figure] Each record stores the previous record's digest. Altering record n − 1 breaks the link stored in record n, and every link after it. A chain has limits. Whoever controls the storage could rewrite the whole chain from the altered record onwards, recomputing every digest. Two additions close that gap. Signatures: each record, or each batch, is signed with a key the writer does not share, so a rewritten chain would not carry valid signatures. Outside anchors: digests are periodically timestamped by an independent party, so a rewrite would contradict an anchor that someone else holds. With both, an auditor can check the trail offline, without trusting the system that wrote it. #### Retention and personal data in an append-only log Retention periods come from the law that applies to the records, not from the logging tool. In India, books of account and their audit trail must be kept for eight years under section 128(5) of the Companies Act, 2013. Under the EU AI Act, providers of high-risk systems keep automatically generated logs for at least six months (Article 19) and deployers keep the logs under their control for at least six months (Article 26(6)), unless other law requires longer. Personal data creates a tension: India's Digital Personal Data Protection Act, 2023 and the EU's GDPR both give people rights to erasure, while an append-only chain cannot be edited. The usual answer is to keep personal data out of the chained record itself: store a reference or a salted hash in the record, keep the personal data in a separate store that can be erased, and rely on the legal exception for data that must be retained to comply with another law. Our paper on DPDP and append-only logs covers this in detail. #### How an auditor tests the trail without the vendor An audit trail that can only be read inside the vendor's dashboard asks the auditor to trust the vendor. A better design lets the auditor take an export and test it independently. A typical test plan looks like this: - Obtain the full export for the period, including refused and held actions, with the published field definitions. - Recompute every record's digest and confirm each link to the previous record. Any mismatch is an exception. - Where records are signed, verify each signature against the published public key, and check outside timestamps against the anchor. - Sample actions and trace them to the system of record: every committed change should appear there, and nothing should appear there without a record. - Sample held actions and confirm the approver was named, independent of the requester and acted within the time limit. - Re-run a sample of decisions against the rules version recorded, and confirm the same outcome. The ISO/IEC 42001 control on event logging (Annex A, A.6.2.8) and the logging duties in Article 12 of the EU AI Act both assume that logs can be reviewed by someone other than the operator. For a field-by-field reading, see our paper on evidence for auditors. #### Worked example: one journal entry, field by field An agent at a fictional manufacturer, Kolam Components*, prepares the month-end accrual for an unbilled freight invoice. The rules say accruals above ₹2,00,000 need the finance controller. Here is what the record should show. Illustrative specimen (not customer data): Month-end accrual, held and approved - Actor: agent: close-assistant v3.2 - On behalf of: Process: month-end close, owner Finance Controller - Intent: Journal entry: Dr Freight expense ₹2,64,000 / Cr Accrued liabilities ₹2,64,000, period Sept 2026 - Target: ERPNext, company Kolam Components*, Journal Entry (draft) - Rules version: close-rules v14 - Checks: Period open: pass. Account mapping: pass. Amount above ₹2,00,000: hold - Approver: A. Raman, Finance Controller (not the requester), approved 30 Sept 2026 18:42 IST - Outcome: Allowed and committed, JV-2026-09-0418 - Previous digest: 9c41…e07a - Record digest: e2d0…4b19 Three gaps appear often when teams first review trails like this: the approver's identity is a shared mailbox rather than a person; the rules version is missing, so nobody can say which threshold applied that day; and the entry number in the books is not recorded, so tracing a record to the ledger takes guesswork. Each is a one-line fix in the record, and each saves hours in an audit. Notice what an auditor can do with this: confirm the rule existed in that version, that the threshold triggered correctly, that the approver was independent, and that the entry in the books matches the intent. Notice too what is absent: no customer names or personal data, only references. #### How elan1 handles this elan1 writes a 16-field proof record for every action an agent proposes, allowed or refused. The field set is fixed and published in the proof record specification, with the method used to compute each SHA-256 digest, so anyone can recompute a record and check the chain. Refused actions are recorded in the same chain and metered at 0.4 of a governed action. At L1 Guarded, records are hash-chained and tamper-evident: changes are detectable, not impossible. From L2 Attested, each record is also signed with the residency domain's key and anchored with an outside timestamp, giving signed records for auditors and a free offline verifier. You can verify a proof record yourself, without asking us. #### Frequently asked questions Q: What should an AI agent audit trail record? A: Each record should show the agent's identity, who or what it acted for, the proposed change, the target system and record, the rules version, each check and its result, the approver, the outcome, timestamps and the previous record's digest. Refused and held actions should be recorded with the same fields. Q: Is logging tool calls enough? A: No. A tool-call log shows that a change happened but not why it was allowed. Auditors test whether controls operated, so the trail must also record the policy decision: which rules ran, their results and who approved or refused. Q: What is the difference between tamper-evident and immutable? A: Tamper-evident means a change to a past record can be detected, for example because a hash chain no longer verifies. Immutable is a claim that the storage will not allow changes at all, which is only as strong as the storage settings and its administrators. Detection is the claim you can test. Q: How long should AI agent logs be kept? A: As long as the law that governs the records requires. In India, books of account and their audit trail are kept for eight years under section 128(5) of the Companies Act, 2013; under the EU AI Act, high-risk system logs are kept for at least six months unless other law requires longer. Q: Can an auditor verify the trail without the vendor? A: It should be able to. A well-designed trail can be exported with its field definitions, so an auditor can recompute the digests, check signatures and outside timestamps where they exist, and trace samples to the system of record without the vendor's help. #### Sources [1] Regulation (EU) 2024/1689 (Artificial Intelligence Act), Articles 12, 19 and 26(6), EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj [2] ISO/IEC 42001:2023, Annex A control A.6.2.8, AI system recording of event logs, ISO. https://www.iso.org/standard/81230.html [3] NIST SP 800-92, Guide to Computer Security Log Management, NIST. https://csrc.nist.gov/pubs/sp/800/92/final [4] RFC 6962, Certificate Transparency, IETF. https://www.rfc-editor.org/rfc/rfc6962 [5] The Digital Personal Data Protection Act, 2023 (No. 22 of 2023), Ministry of Electronics and Information Technology. https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf [6] Regulation (EU) 2016/679 (General Data Protection Regulation), Article 17, EUR-Lex. https://eur-lex.europa.eu/eli/reg/2016/679/oj [7] Implementation Guide on Reporting on Audit Trail under Rule 11(g), Revised 2024 Edition, The Institute of Chartered Accountants of India. https://eirc-icai.org/uploads/background_materials/Revised%202024_Implementation%20Guide%20on%20Reporting%20of%20Audit%20Trail%20%281%29_1712114860.pdf ### MCP server security and governance for write tools URL: https://elan1.ai/guides/mcp-server-governance Author: M. K. Elango · Published 2026-10-10 · Updated 2026-10-10 Securing an MCP server whose tools can write means treating each tool by what it can change. Separate read, stage and act tools, keep write credentials away from the agent, require approval for act tools above a risk threshold, and record each act call with the policy decision. Key takeaways: - Classify every MCP tool as read, stage or act. Only act tools change anything, and they are the ones that need a policy check, an approver above a threshold and a record. - Tool annotations such as readOnlyHint are hints from the server, not controls. The specification says clients must treat them as untrusted unless the server is trusted. - Keep write credentials away from the agent: let it propose through MCP, and let a separate component that holds the credential commit only what the rules allow. #### What MCP changes: tools any agent can call The Model Context Protocol (MCP) is an open protocol for connecting AI applications to tools and data. An MCP server describes a set of tools, each with a name, a description and an input schema; an MCP client inside an AI application lists those tools and lets the model call them. The specification is public and versioned, and both servers and clients are now common across developer tools, office suites and business software. The benefit is reuse: one server can serve many agents. The risk follows from the same fact. A tool that posts an invoice, issues a refund or changes a record is now callable by any agent that connects to the server, with whatever credential the server holds, on the strength of whatever the model decided. MCP standardises how tools are called. It does not decide which calls should be allowed. That decision is yours. Where the server runs matters too. A local server started on a laptop over standard input and output runs with that user's permissions and whatever tokens sit in its configuration file. A remote server reached over HTTP runs with its operator's credentials and, under the specification's authorisation model, should validate tokens issued to it rather than accept any token it is handed. Inventory both kinds: local servers are the ones most often missed, because they never pass through a procurement process. #### The main threats to MCP servers with write tools Most MCP risks are familiar security problems in a new shape. The ones that matter most for write tools are these. MCP threats that matter for write tools: | Threat | What happens | Main control | | Prompt injection through tool output | Text returned by one tool, such as an email or web page, carries instructions the model follows when calling another tool. | Policy on the write itself; never trust the model's plan for consequential changes | | Tool poisoning | A tool's description or schema contains hidden instructions, or changes after you approved the server. | Pin and review tool definitions; alert on changes | | Excessive agency | Tools offer more functionality, permissions or autonomy than the task needs (OWASP LLM06). | Least privilege; separate read, stage and act tools | | Credential sprawl | Long-lived tokens for business systems sit in server configurations and agent environments. | Short-lived, scoped credentials held outside the agent | | Confused deputy | The server uses its own broad credential to act for a user who should not have that access. | Act with the caller's authority; check it per call | The OWASP Top 10 for LLM Applications 2025 ranks prompt injection first, and OWASP's agentic AI threats and mitigations guidance covers tool misuse and privilege compromise. The common thread is that you cannot fully prevent a model from being misled, so the protection has to sit at the point where a tool changes something. #### Classify tools: read, stage, act Sort every tool on a server into one of three classes, by what it can change, not by what its name suggests. [Figure] Three classes of MCP tool. Read and stage tools change nothing that matters; act tools submit a change that is checked, approved above a threshold and committed by a separate writer. Read tools return data and change nothing. They still need access control, because they can leak what the user should not see. Stage tools prepare a change without committing it: a draft invoice, a proposed journal, a quote. They let the agent do useful work while leaving the decision for later. Act tools commit a change to a system of record. Keep act tools few and narrow: “post this staged journal” is safer than “run any accounting operation”. Example: classifying the tools of an accounting MCP server: | Tool | Class | Why | | get_trial_balance | Read | Returns figures; changes nothing | | search_suppliers | Read | Returns records the user may see | | draft_journal_entry | Stage | Creates a draft that is not posted | | draft_payment_batch | Stage | Prepares payments without releasing them | | post_journal_entry | Act | Posts a staged draft to the ledger | | release_payment_batch | Act | Sends money; hard to reverse | | update_supplier_bank_details | Act | Changes where future payments go; always held | The stage class is the one most servers lack, and it is the one that makes approval practical. An approver can review a staged change as a diff; an approver asked about a free-form instruction cannot. #### Tool annotations are hints, not controls MCP lets a server annotate each tool with hints: readOnlyHint (the tool does not modify its environment), destructiveHint (a modifying tool may make destructive rather than additive changes), idempotentHint and openWorldHint. They help a client decide when to ask the user for confirmation. They are, however, claims made by the server about itself. The specification states that clients must treat annotations as untrusted unless they come from a trusted server, and the protocol's own blog post on tool annotations explains why: a server can declare a tool read-only and still delete data. Use annotations to improve the user experience. Do not use them as the reason a write was allowed. The same applies to tool descriptions in general. A description is text the model reads, which makes it an input an attacker can shape. Review descriptions as you would review code, and treat a change to one as a change that needs approval. #### Keep the credential away from the agent The strongest single control for MCP write tools is architectural: the agent, and the MCP server it talks to, never hold a standing credential that can write to the system of record. Instead, an act tool submits a write intent. A separate component checks it against rules, obtains an approval where needed, and only then uses a short-lived, single-use credential, scoped to that one change, to commit it. This is the single writer pattern. With a single writer, a compromised or misled agent can propose a bad change but cannot make one outside the rules. Without it, every control is only as strong as the agent's willingness to follow it. For HTTP-based servers, follow the specification's authorisation model and its security best practices, which warn against passing a client's token straight through to downstream services. #### Approvals for act tools above a threshold The MCP specification expects hosts to keep a person able to deny tool calls. For write tools, make that concrete: set a threshold per act tool, by amount, by record type, by counterparty or by reversibility, and hold calls above it for a named approver who is not the requester. Below the threshold, act calls proceed within limits and are recorded. Two details matter. The approver should see the staged change as a diff, not the model's reasoning. And the approval should bind to that exact change: if the agent alters the arguments after approval, the approval should no longer apply. Our guide to human-in-the-loop for AI agents covers thresholds and approval fatigue. #### Record each act call with its policy decision A transport log of JSON-RPC messages is useful for debugging but weak as evidence. For each act call, record the calling agent and the user or process it acted for, the tool and its arguments, the rules evaluated and their results, the approver if any, the outcome, and a link to the previous record so later edits are detectable. Record refused calls too. Pin the tool definitions you approved, with a digest of each description and schema, and record which definition was in force for each call. If a server changes a tool's description after review, you will see it, and so will your auditor. The AI agent audit trail guide lists the fields in detail. Give every act call a correlation identifier that travels from the agent's session through the MCP server to the record and, where the downstream system allows, into the change itself, such as a reference on the journal entry. Then a reviewer can trace a ledger line back to the agent, the rules and the approver in one step, and trace a refused call to the conversation that produced it. #### Governing an MCP server you did not build Many MCP servers come from vendors. You cannot change their code, but you can put a governing layer in front of them: a proxy or gateway that lists the server's tools, classifies them, applies your rules to each call, holds act calls above the threshold and records every decision. Be honest about what this gives you. If the vendor's server holds its own credential to the downstream system, your gateway can evaluate and record every call that passes through it, but it cannot stop a call made by another route. That is an advisory arrangement, useful and auditable, but not enforcement. Enforcement needs the credential to sit with the component that makes the decision. #### A checklist for MCP write tools - Every tool on every connected server is classified as read, stage or act, and the list is reviewed when a server updates. - Act tools are few and narrow, and each has a written threshold for approval. - No agent or MCP server holds a standing credential that can write to a system of record. - Credentials for act calls are short-lived, single-use and scoped to the change. - Approvals bind to the exact staged change and are given by a named person who is not the requester. - Tool descriptions and schemas are pinned by digest; changes raise an alert. - Every act call, allowed or refused, leaves a linked record with its policy decision. - Annotations are used for user experience only, never as the basis for allowing a write. #### How elan1 handles this The elan1 MCP server exposes its tools in exactly these three classes. Read tools return data, stage tools prepare a change without committing it, and every act tool submits a write intent that climbs the Right Path in elan1 Govern: identity, pre-gates, versioned rules, a guardrail, an autonomy check and a named approver where your rules ask. The MCP server reference: read, stage and act tools lists each tool and the typed refusals it can return. Where elan1 holds the write credential (Mode A), the kernel is the single writer and commits with a short-lived, single-use credential, so the rules are enforced. Where you connect over MCP or HTTP and keep the credential, elan1 works in Mode B (Attested advisory): every intent is evaluated and recorded, and enforcement stays with your system. See MCP governance for the integration options, and safe AI agent write access to production for the developer view. #### Frequently asked questions Q: What are the main MCP security risks? A: For servers with write tools, the main risks are prompt injection through tool output, poisoned or changed tool descriptions, excessive agency, long-lived credentials sitting in server configurations and the confused-deputy problem. Most of them are contained by checking each write itself rather than trusting the model's plan. Q: How should MCP write tools be approved? A: Classify act tools, set a threshold for each by amount, record type, counterparty or reversibility, and hold calls above it for a named approver who is not the requester. The approver should see the staged change as a diff, and the approval should bind to that exact change. Q: Should the agent hold the credential? A: No. The agent and the MCP server should not hold a standing credential that can write to a system of record. A separate component that makes the policy decision should commit approved changes with a short-lived, single-use credential scoped to the change. Q: How do I audit MCP tool calls? A: Record each act call with the calling agent, the user or process it acted for, the tool and arguments, the rules evaluated and their results, the approver, the outcome and a link to the previous record. Pin the tool definition in force for each call, and record refused calls too. Q: Can I govern an MCP server I did not build? A: Yes, by placing a governing gateway in front of it that classifies tools, applies your rules, holds act calls for approval and records every decision. If the vendor's server keeps its own credential, this is advisory rather than enforcement, because a call by another route would bypass the gateway. #### Sources [1] Model Context Protocol specification, Server: Tools (2026-07-28 revision), Model Context Protocol. https://modelcontextprotocol.io/specification/2026-07-28/server/tools [2] Security Best Practices (2026-07-28 revision), Model Context Protocol. https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices [3] Tool Annotations as Risk Vocabulary: What Hints Can and Can't Do (16 March 2026), Model Context Protocol blog. https://blog.modelcontextprotocol.io/posts/2026-03-16-tool-annotations/ [4] LLM01:2025 Prompt Injection, OWASP Top 10 for LLM Applications 2025, OWASP GenAI Security Project. https://genai.owasp.org/llmrisk/llm01-prompt-injection/ [5] LLM06:2025 Excessive Agency, OWASP Top 10 for LLM Applications 2025, OWASP GenAI Security Project. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/ [6] Agentic AI: Threats and Mitigations, OWASP GenAI Security Project, Agentic Security Initiative. https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/ [7] NIST AI 100-1, AI Risk Management Framework 1.0, NIST. https://doi.org/10.6028/NIST.AI.100-1 ### EU AI Act and AI agents: logging and oversight URL: https://elan1.ai/guides/eu-ai-act-ai-agents Author: M. K. Elango · Published 2026-10-10 · Updated 2026-10-10 The EU AI Act does not regulate AI agents as a category; it regulates AI systems by risk. An agent used in a high-risk area, such as credit scoring or employment, must log events automatically (Article 12), support human oversight (Article 14), and its deployer must keep those logs (Article 26). Key takeaways: - The EU AI Act regulates AI systems by risk, not “agents” as a category. An agent inherits the duties of the risk class its use falls into. - For high-risk uses, three articles shape agent design: automatic logging (Article 12), effective human oversight (Article 14) and deployer duties, including keeping logs for at least six months (Article 26). - As amended by Regulation (EU) 2026/1744, high-risk duties for Annex III systems apply from 2 December 2027. Indian companies are in scope when they place systems on the EU market or their output is used in the EU. #### How the Act treats agents: systems by risk Regulation (EU) 2024/1689, the AI Act, defines an AI system broadly: a machine-based system that operates with some autonomy and infers from its inputs how to generate outputs, such as predictions, recommendations or decisions, that can influence physical or virtual environments. An AI agent that plans steps and calls tools fits comfortably inside that definition. The Act does not create a separate category for agents. Instead, it sorts AI systems by risk. A small set of practices is prohibited. High-risk systems carry the heaviest duties. Certain systems carry transparency duties, such as telling people they are interacting with AI. Everything else is largely untouched. Separately, providers of general-purpose AI models have their own obligations. So the first question for any agent is not “is this an agent?” but “what is this agent used for, and does that use fall into a risk class?” One duty reaches agents whatever their risk class. Under Article 50, which applies from 2 August 2026, providers must design systems that interact directly with people so that those people are told they are dealing with AI, unless that is obvious from the context. An agent that emails suppliers, answers customers or calls people on the phone falls within that duty. It is a small design change, but it applies now. #### When an agent is high-risk, and when it is not Under Article 6, a system is high-risk in two cases. It is a safety component of, or itself, a product covered by the EU product-safety laws listed in Annex I, such as machinery or medical devices. Or it is used in one of the areas listed in Annex III. Annex III areas most relevant to business agents: | Area | Examples where an agent could be high-risk | | Employment and workers management | Screening CVs, ranking candidates, allocating tasks or evaluating performance | | Access to essential private services | Assessing creditworthiness or a credit score of a natural person; risk assessment and pricing for life and health insurance | | Access to essential public services | Evaluating eligibility for public benefits | | Education and vocational training | Admissions, assessment of learning outcomes, proctoring | | Biometrics | Remote biometric identification, biometric categorisation, emotion recognition | Article 6(3) adds an important exception: a system in an Annex III area is not high-risk if it does not pose a significant risk of harm, for example because it performs a narrow procedural task or only improves the result of a human activity already completed. An Annex III system that profiles natural persons is always high-risk. An agent that reconciles bank statements or drafts purchase orders is unlikely to be high-risk; an agent that decides which loan applicants proceed probably is. Document your assessment either way. #### Article 12, record-keeping: what logs must capture Article 12 requires high-risk systems to technically allow the automatic recording of events, logs, over the lifetime of the system. The logging must enable the recording of events relevant to three purposes: identifying situations that may present a risk or lead to a substantial modification, facilitating post-market monitoring by the provider, and monitoring the system's operation by the deployer. For most systems the Act does not prescribe a field list; it prescribes what the logs must make possible. For remote biometric identification it is more specific, requiring at minimum the period of each use, the reference database, the input data that led to a match and the identity of the people who verified the result. For an agent, the practical reading is that each action needs a record of what was proposed, what was checked, who verified or approved it, and what happened. Our guide to the AI agent audit trail turns that into fields. Providers keep the logs under their control for at least six months (Article 19), unless other EU or national law requires otherwise. If you buy the agent rather than build it, the logging capability is the provider's job, but using it is yours. Ask the provider what events the system logs, where the logs are kept, how you export them and how long they are retained, and check the answers against its instructions for use. A deployer that cannot reach the logs cannot meet its own duties under Article 26. #### Article 14, human oversight: what the overseer must be able to do Article 14 requires high-risk systems to be designed so that natural persons can oversee them effectively while they are in use. Oversight measures must be proportionate to the risks, the level of autonomy and the context. The people assigned must be enabled, as appropriate, to: 1. understand the system's relevant capacities and limitations and monitor its operation, including detecting anomalies; 2. remain aware of the tendency to rely automatically or excessively on the system's output (automation bias); 3. correctly interpret the system's output; 4. decide not to use the system in a particular situation, or to disregard, override or reverse its output; 5. intervene in its operation or interrupt it through a stop button or similar procedure. For remote biometric identification, Article 14(5) goes further: no action is taken on an identification unless at least two competent people have separately verified it. For agents, items 4 and 5 are the design test. Can a person stop a specific change before it takes effect, and stop the agent entirely? Our guide to human approval covers how to make that real without approval fatigue. #### Article 26, deployer duties Most businesses using an agent are deployers, not providers. Article 26 gives deployers of high-risk systems their own list of duties: - use the system in accordance with the provider's instructions for use; - assign human oversight to natural persons who have the necessary competence, training and authority, and the support they need; - ensure input data under their control is relevant and sufficiently representative for the intended purpose; - monitor operation, and inform the provider and authorities of serious incidents and risks; - keep the logs automatically generated by the system, to the extent they are under the deployer's control, for at least six months, unless other law provides otherwise (Article 26(6)); - inform workers' representatives and affected workers before putting a high-risk system into use at the workplace. Some deployers, including public bodies and those using systems for credit scoring or for life and health insurance pricing, must also carry out a fundamental rights impact assessment under Article 27. And under Article 86, people affected by certain decisions based on high-risk systems can ask the deployer for an explanation. #### General-purpose AI models versus the agent built on them Obligations for providers of general-purpose AI models, such as technical documentation, copyright policies and, for models with systemic risk, evaluations and incident reporting, have applied since 2 August 2025. They fall on the model provider, not on every business that calls the model through an API. The agent you build on top of a model is a separate AI system. If you put it on the market or into service under your own name, you may be its provider, with the provider's duties if its use is high-risk. Article 25 also turns a deployer or distributor into a provider if they substantially modify a high-risk system or change its intended purpose so that it becomes high-risk. Model choice does not move your obligations to the model vendor. #### Does the EU AI Act apply to Indian companies? It can. Under Article 2, the Act applies to providers that place AI systems on the EU market or put them into service in the EU, wherever they are established, and to providers and deployers in third countries where the output produced by the system is used in the EU. Providers outside the EU of high-risk systems must appoint an authorised representative in the EU (Article 22). In practice, an Indian software company selling an agent to EU customers is likely to be a provider in scope. An Indian business using an agent purely for its own Indian operations is not, unless the output is used in the EU, for example decisions about EU-based employees or customers. Penalties for breaching high-risk obligations can reach €15 million or 3% of worldwide annual turnover, whichever is higher (Article 99). #### Timeline: what applies now, and what was moved The Act entered into force on 1 August 2024 and applies in stages. In 2026 the EU adopted the Digital Omnibus on AI, Regulation (EU) 2026/1744, published on 24 July 2026 and in force since 27 July 2026, which postponed the high-risk dates. As of October 2026, the dates are: [Figure] EU AI Act application dates as of October 2026, including the changes made by Regulation (EU) 2026/1744. Check the Official Journal before relying on a date. Postponement is not removal. The design work for logging and oversight takes longer than the time left for most teams, and customers in regulated sectors are already asking for the evidence in procurement. The European Commission's AI Act pages and service desk track the guidance and standards still to come. #### From obligation to control: a working table EU AI Act obligations mapped to agent controls: | Obligation | Agent control | Evidence to keep | | Art. 12 automatic logging | A record for every proposed action, linked in sequence | Exportable records with published field definitions | | Art. 14(4)(d) override | Consequential changes held for a named person who can refuse | Approval and refusal records with the approver's identity | | Art. 14(4)(e) stop | A stop that halts the agent and pending changes | Records of stops and who triggered them | | Art. 26(2) competent overseers | Named approvers with deputies, trained on the process | Role assignments and training records | | Art. 26(5) monitoring | Review of refusal patterns, approval rates and incidents | Monitoring reports and incident notifications | | Art. 26(6) log retention | At least six months, longer where other law requires | Retention settings and a test restore | None of these controls makes a system compliant on its own. They produce the evidence a conformity assessment, an auditor or a customer will ask to see. #### How elan1 handles this elan1 helps produce evidence for Articles 12, 14 and 26; it does not make a system compliant by itself. Every action an agent proposes is written to a 16-field proof record, allowed or refused, and consequential writes are held for a named approver who can refuse them. From L2 Attested, records are signed and packed into a signed evidence bundle that an auditor or customer can verify offline. Records stay in the residency domain where they were written; today that is India, in Mumbai, and EU domains open on a signed contract (see residency). For the article-by-article mapping, read EU AI Act Articles 12 and 14 for AI agents; for risk and audit teams, see audit evidence for AI agent actions. #### Frequently asked questions Q: Are AI agents regulated by the EU AI Act? A: Not as a separate category. The Act regulates AI systems by risk, and an AI agent is an AI system, so it carries the duties of the risk class its use falls into. An agent used for credit scoring or recruitment is likely to be high-risk; one that reconciles invoices usually is not. Q: What does Article 12 require? A: Article 12 requires high-risk AI systems to allow automatic recording of events over their lifetime. The logs must make it possible to identify risk situations, support the provider's post-market monitoring and let the deployer monitor operation; providers keep them for at least six months under Article 19. Q: What does Article 14 require? A: Article 14 requires high-risk systems to be designed for effective human oversight. The people overseeing them must be able to understand and monitor the system, stay aware of automation bias, interpret its output, override or reverse it, and stop it. Q: Does the EU AI Act apply to Indian companies? A: It can. The Act applies to providers placing AI systems on the EU market wherever they are established, and to providers and deployers outside the EU where the system's output is used in the EU. An Indian company selling an agent to EU customers is likely to be in scope. Q: When do high-risk obligations apply? A: As amended by Regulation (EU) 2026/1744, high-risk obligations for Annex III systems apply from 2 December 2027, and for AI in Annex I regulated products from 2 August 2028. Prohibitions have applied since February 2025 and general-purpose AI model duties since August 2025. #### Sources [1] Regulation (EU) 2024/1689 (Artificial Intelligence Act): Articles 2, 6, 12, 14, 19, 22, 25, 26, 27, 86, 99 and Annex III, EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj [2] Regulation (EU) 2026/1744 (Digital Omnibus on AI), amending Regulation (EU) 2024/1689, EUR-Lex. https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng [3] AI Act: Annex III, high-risk AI systems referred to in Article 6(2), European Commission, AI Act Service Desk. https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-3 [4] AI Act: regulatory framework and application timeline, European Commission, Shaping Europe's digital future. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai [5] ISO/IEC 42001:2023, Artificial intelligence — Management system, ISO. https://www.iso.org/standard/81230.html [6] NIST AI 100-1, AI Risk Management Framework 1.0, NIST. https://doi.org/10.6028/NIST.AI.100-1 ### MCA audit trail Rule 3(1) explained for AI-era books URL: https://elan1.ai/guides/mca-audit-trail-rule-3-1 Author: M. K. Elango · Published 2026-10-10 · Updated 2026-10-10 India's MCA audit trail rule, the proviso to Rule 3(1) of the Companies (Accounts) Rules, 2014, requires companies to use accounting software that records an audit trail of every transaction, with an edit log of each change and its date, that cannot be disabled. Auditors report on it under Rule 11(g). Key takeaways: - Since financial years beginning on or after 1 April 2023, every company that keeps its books in accounting software must use software that records an edit log of every change, with dates, that cannot be disabled. - The statutory auditor reports under Rule 11(g) on whether the feature existed, operated all year for all transactions, was not tampered with and was preserved. The edit log is kept for eight years, accessible in India. - When an AI agent posts entries, give it its own user so the edit log attributes changes correctly, and keep a second record of the policy decision and the approval behind each entry. #### The rule in one paragraph The Companies (Accounts) Amendment Rules, 2021, notified on 24 March 2021, added a proviso to Rule 3(1) of the Companies (Accounts) Rules, 2014. It says that for financial years commencing on or after 1 April 2023, every company that uses accounting software for its books of account must use only software that records an audit trail of each and every transaction, creates an edit log of each change made in the books along with the date of the change, and ensures that the audit trail cannot be disabled. A companion amendment to the Companies (Audit and Auditors) Rules, 2014, notified the same day, added Rule 11(g), under which the auditor reports on it. Three limbs, then: an audit trail of every transaction, an edit log with the date of every change, and no way to switch it off. Software that logs deletions but not modifications fails the second; software that lets an administrator pause logging fails the third. “Books of account” has its meaning under section 2(13) of the Companies Act, 2013: records of money received and spent, sales and purchases, assets and liabilities, and certain cost items. So the rule follows the books wherever they are kept. A sub-ledger in a separate billing system that posts into the general ledger is part of the books; a planning spreadsheet that nobody posts from is not. #### Who must comply, and since when Every company incorporated under the Companies Act that maintains its books in accounting software is covered. The ICAI Implementation Guide confirms there is no exemption for small or medium companies, and none for banks and NBFCs incorporated as companies. One Person Companies and section 8 companies are covered too. The requirement was first due from 1 April 2021 and was deferred twice. It finally applied to financial years commencing on or after 1 April 2023, so FY 2023-24 was the first year of compliance and of Rule 11(g) reporting; FY 2025-26 audits, being signed now, are the third cycle. Limited liability partnerships and proprietorships are outside these Companies Act rules, though the CGST Rules separately require a log of edited or deleted entries in electronic records (Rule 56). #### What the edit log must record, and “cannot be disabled” The rule's text requires the date of each change. ICAI's guide sets out what management should ensure in practice, and it goes further: - when changes were made, and who made them; - what data was changed, so the original and the changed value are both available; - that the audit trail covers every transaction that changes the books, including master data that feeds them, such as supplier or item masters where those records drive accounting entries; - that the trail is enabled at the database level where direct database changes are possible; - that the trail is protected from modification, access to it is restricted and logged, and changes to its configuration are authorised and recorded. “Cannot be disabled” is about the feature, not about intent. If the software has a setting that can turn the log off, the company needs controls showing it was never turned off, and the auditor needs evidence of that for the whole year. A log that keeps only the latest change, or an error log that users can edit, does not meet the requirement. #### Retention and back-ups in India The audit trail is part of the books of account, so it carries their retention period: at least eight financial years under section 128(5) of the Companies Act, 2013. Rule 3(1) requires books kept in electronic form to remain accessible in India at all times, so they can be used for later reference. Since an amendment in August 2022, Rule 3(5) requires the back-up of books kept in electronic mode, including at a place outside India, to be kept on servers physically located in India on a daily basis. Two practical consequences follow. When you change software, export and preserve the old system's edit log; a lapsed subscription is not a retention policy. And if your software is hosted abroad, check where the daily back-up and the audit trail sit, and whether you can reach them from India at any time. Finally, make sure the export is readable without the old software: a proprietary backup file that only a lapsed licence can open is not much better than no copy at all. #### What the auditor reports under Rule 11(g) Rule 11(g) asks the statutory auditor to state whether the company has used accounting software with an audit trail (edit log) facility; whether it operated throughout the year for all transactions recorded in the software; whether the audit trail feature was tampered with; and whether the audit trail was preserved as per the statutory requirements for record retention. Common reasons for a modified Rule 11(g) comment: | Situation | Why it is reported | | The feature was enabled part-way through the year | It did not operate throughout the year | | Direct database changes were not logged | Not all changes to the books were captured | | Part of the books was kept in a spreadsheet that fed the ledger | Those records had no audit trail | | A service provider's assurance report did not cover the full year | Insufficient evidence for the whole period | | The previous system's log was not preserved after a migration | Not preserved for the retention period | ICAI's guide notes that a modified comment under Rule 11(g) also has to be considered in the auditor's reporting on whether proper books of account have been kept. It is not a footnote; it is a statement about the books, and clients, lenders and investors read it as one. A clean Rule 11(g) paragraph is now part of what good books look like. Where the software is hosted by a service provider, auditors often rely on an independent assurance report on the provider's controls. ICAI's guide expects that report to cover the audit trail requirements and the company's whole financial year. A report that ends in December for a year that ends in March leaves a gap the auditor has to close some other way, so ask your provider early which period its report will cover. #### Tally, ERPNext and other software: what to check Most widely used accounting packages in India now offer an edit log. The question is not which brand you trust but whether, in your installation, the feature meets all three limbs for the whole year. Check, for whatever you run: - The edit log is on, and the setting cannot be switched off, or every change to the setting is itself logged. - Modifications and deletions are both logged, with user, date and time, and the old and new values. - Master data that drives entries is covered. - Direct database access is restricted, and logged where it exists. - The log is retained for eight years and can be exported in a readable form. - Back-ups are taken daily to servers in India. Two examples. TallyPrime offers an edit log for this purpose; confirm that the release you run has it enabled for the whole year. For ERPNext, the India Compliance app's audit trail setting can be enabled from Accounts Settings and, once enabled, cannot be disabled. Cloud and desktop installations differ in one respect that matters here. With cloud software the provider controls the database, so direct edits are rarer but you depend on its assurance report; with a desktop or self-hosted installation, anyone with database access can bypass the application, so database-level logging and access control carry more weight. If you are moving between them, our Tally to ERPNext migration guide covers preserving the old log. #### When an AI agent posts entries The rule says nothing about AI, and it does not need to: an entry posted by an agent is an entry in the books, and it must appear in the edit log like any other. Three things change in practice. ##### Attribution If an agent posts under a person's login, the edit log will say that person made the change. Give each agent its own user in the accounting software, with permissions limited to what it needs, so the log attributes changes correctly. Never let an agent share a chartered accountant's or a director's credentials. ##### Approval The edit log records that a change happened, not whether anyone checked it. For consequential entries, such as journals above a limit, entries to closed periods or changes to supplier bank details, hold the agent's change for a named person before it is posted. ##### Period locks Agents work quickly and do not get tired at month end, which makes it easy for one to post into a period the accountant thought was closed. Set and record a lock date at every close, and make entries before it a change that always waits for a named person. The edit log will show back-dated entries, but it is better to stop them than to explain them. ##### The second record Keep a record outside the accounting software of the agent's proposal, the rules that were checked, the approver and the outcome, linked to the entry number in the books. The edit log remains the statutory record; the second record shows the control around it, which is what an auditor testing the agent will want to see. See a small firm's journal entry, read by its CA, an illustrative specimen. #### A checklist for CFOs and CAs - List every system that holds any part of the books, including spreadsheets that feed entries, and confirm each has an audit trail that meets the rule. - Obtain evidence that the edit log was on for the whole year: configuration screenshots with dates, change logs for the setting, vendor assurance reports covering the full period. - Restrict and log direct database access. - Set and record a lock date at every period close. - Preserve the edit log of any system you leave, in a readable export, for eight years. - Confirm daily back-ups to servers in India, and test a restore. - Give every AI agent and integration its own user; review their permissions quarterly. - Review deletions and back-dated edits as part of the close, not only at the audit. #### How elan1 handles this elan1 Work runs ERPNext AI agents with approval and audit trail. Every change an agent proposes passes a rule check and, where your rules ask, a named approver before it is posted, and it is committed by a single writer, so the ERPNext edit log keeps recording every change while elan1 records who proposed it, which rules ran and who approved it. The ledger1 pack configures elan1 Govern for MCA requirements. Alongside the ERPNext edit log, each change leaves a proof record: tamper-evident at L1 Guarded, signed from L2 Attested. For accounting firms, CA seats are free for every client, so the chartered accountant can read and approve what changes. See AI for chartered accountants, and our guide to AI for chartered accountants in India. #### Frequently asked questions Q: What is the MCA audit trail rule? A: It is the proviso to Rule 3(1) of the Companies (Accounts) Rules, 2014. From financial years commencing on or after 1 April 2023, every company using accounting software must use software that records an audit trail of every transaction, with an edit log of each change and its date, that cannot be disabled. Q: Which companies must comply? A: Every company that maintains its books of account in accounting software, with no exemption for small companies, One Person Companies or section 8 companies. Limited liability partnerships and proprietorships fall outside the Companies Act rules, although the CGST Rules separately require a log of edited or deleted electronic entries. Q: What must the edit log record? A: The rule requires an edit log of each change with the date it was made. ICAI's implementation guide expects it also to show who made the change and what was changed, to cover master data that drives entries, and to be protected from modification. Q: How long must the audit trail be kept? A: As long as the books of account: at least eight financial years under section 128(5) of the Companies Act, 2013. The trail must remain accessible in India, and daily back-ups must be kept on servers in India. Q: What changes when an AI agent posts entries? A: The entries must appear in the edit log like any other, so the agent needs its own user for correct attribution. Consequential entries should be held for a named approver before posting, and a second record of the policy decision and approval should link to the entry number. #### Sources [1] Notifications: Companies (Accounts) Amendment Rules, 2021 and Companies (Audit and Auditors) Amendment Rules, 2021 (24 March 2021), Ministry of Corporate Affairs. https://www.mca.gov.in/content/mca/global/en/acts-rules/ebooks/notifications.html [2] Implementation Guide on Reporting on Audit Trail under Rule 11(g) of the Companies (Audit and Auditors) Rules, 2014 (Revised 2024 Edition), The Institute of Chartered Accountants of India. https://eirc-icai.org/uploads/background_materials/Revised%202024_Implementation%20Guide%20on%20Reporting%20of%20Audit%20Trail%20%281%29_1712114860.pdf [3] Companies Act, 2013, section 128 (books of account) and section 143 (auditor's report), Ministry of Corporate Affairs. https://www.mca.gov.in/content/mca/global/en/acts-rules/companies-act/companies-act-2013.html [4] Audit Trail (India Compliance app for ERPNext), India Compliance documentation. https://docs.indiacompliance.app/docs/miscellaneous/audit_trail [5] Central Goods and Services Tax Rules, 2017, Rule 56 (maintenance of accounts), Central Board of Indirect Taxes and Customs. https://cbic-gst.gov.in/ [6] ISO/IEC 42001:2023, Annex A control A.6.2.8 (event logs), ISO. https://www.iso.org/standard/81230.html ### RBI FREE-AI and India's AI governance guidelines URL: https://elan1.ai/guides/india-ai-governance-rbi-free-ai Author: M. K. Elango · Published 2026-10-10 · Updated 2026-10-10 RBI's FREE-AI framework, published in August 2025, sets out principles and recommendations for responsible AI in Indian financial services, and MeitY's India AI Governance Guidelines of November 2025 set principles for all sectors. Neither is a single statute; both expect board oversight, risk-based controls, human accountability and auditable records. Key takeaways: - India governs AI through principles and sector regulators rather than one AI law. For finance, the anchor is RBI's FREE-AI report of August 2025: 7 Sutras, 6 pillars and 26 recommendations. - FREE-AI and MeitY's November 2025 guidelines share the same seven principles. Both expect board oversight, risk-based controls, human accountability and records that can be audited. - The binding duties today come from existing law: the DPDP Act and Rules for personal data, CERT-In's directions for logs and incidents, and RBI's own directions such as KYC and outsourcing. #### India's approach: guidelines and sector regulators India has chosen not to pass a single, horizontal AI statute for now. The government's position, set out in MeitY's India AI Governance Guidelines, is that most AI risks can be handled under existing laws, applied by the regulators that already supervise each sector, supported by common principles and new institutions. For banks, NBFCs and other regulated entities, that means the Reserve Bank of India sets the expectations, and its main AI document is the FREE-AI committee report. This matters for how you read the documents. Neither FREE-AI nor the MeitY guidelines is a law you can be fined under directly. But a supervisor that has published a framework will examine regulated entities against it, and the binding obligations that already exist, in data protection, cyber security, KYC and outsourcing, apply in full when AI is involved. #### RBI's FREE-AI framework: Sutras, pillars and recommendations On 13 August 2025 the Reserve Bank published the report of its committee on a Framework for Responsible and Ethical Enablement of Artificial Intelligence (FREE-AI). It is organised in three layers. The structure of FREE-AI: | Layer | What it contains | | 7 Sutras | Trust is the foundation; people first; innovation over restraint; fairness and equity; accountability; understandable by design; safety, resilience and sustainability. | | 6 pillars | Three for enabling innovation (infrastructure, policy, capacity) and three for managing risk (governance, protection, assurance). | | 26 recommendations | Actions addressed to RBI, other regulators, industry bodies and regulated entities, each with an indicative short- or medium-term timeline. | Some recommendations build shared infrastructure, such as an AI innovation sandbox for the financial sector. Others are addressed to regulated entities directly: board-approved policies, governance across the AI life cycle, consumer protection, cyber security, incident reporting and audit. Recommendation 8 proposes a graded liability approach: regulated entities remain liable for customer losses, but supervisors may take a more tolerant view of a first-time lapse where the entity followed sound safety practice such as incident reporting, audits and red teaming. Recommendation 18 asks each regulated entity for a board-approved consumer protection framework with accessible recourse. #### What FREE-AI expects in practice Read across the governance, protection and assurance pillars, the report points to a familiar set of controls. For a bank or NBFC deploying AI, including agents, they translate as follows. - A board-approved AI policy that defines permitted uses, risk appetite and accountability, with named senior owners. - An inventory of AI systems, including vendor and embedded models, with their purpose, data and risk tier. - Risk-based controls by tier: more testing, monitoring and human involvement as the impact on customers grows. - Human oversight and accountability: a person answerable for each AI-assisted decision, and the ability to intervene. - Consumer protection: telling customers when they are dealing with AI, explaining outcomes in terms they understand, and a grievance route that reaches a person. - Assurance: independent audit, monitoring for drift and bias, and reporting of AI incidents. Each item needs evidence, not only a policy: an inventory you can produce, records of decisions and overrides, and audit reports. The evidence table later in this guide lists what to keep. Agents raise the stakes because they act rather than advise. A model that suggests a collections message is one thing; an agent that sends it, changes a repayment schedule or updates a customer's contact details is another. For agents, the expectations above become concrete: each consequential action needs a rule check, a named person accountable for it above a threshold, and a record that links the action to the decision behind it. Customer-facing actions also need to respect the RBI's existing conduct rules, such as those on recovery and fair practices, which apply whether a person or a machine acts. #### MeitY's India AI Governance Guidelines On 5 November 2025 the Ministry of Electronics and Information Technology released the India AI Governance Guidelines under the IndiaAI Mission. They apply across sectors and are voluntary. The document has four parts: seven principles, recommendations across six pillars, an action plan with short-, medium- and long-term steps, and practical guidance for industry and regulators. The seven principles are the same Sutras as FREE-AI, adapted for all sectors, which makes the two documents easy to read together. The guidelines also propose institutions to coordinate AI governance across government, including an AI Governance Group, a Technology and Policy Expert Committee and the AI Safety Institute, and they favour graded, risk-based obligations, voluntary commitments and techno-legal measures over new prohibitions. For a business, the practical message is the same as FREE-AI's: know what AI you use, match controls to risk, keep a human accountable, protect the people affected and keep records that let someone check what happened. Because the guidelines prefer existing law, their real effect is on how sector regulators and courts will read that law. Expect questions about AI to arrive inside familiar processes: an inspection, a grievance, a data breach inquiry, an audit. The organisation that can answer them with records rather than descriptions will be in a better position. #### The DPDP Act 2023 and Rules 2025: where agents touch personal data The Digital Personal Data Protection Act, 2023 is binding law, and its Rules were notified on 13 November 2025. They take effect in phases: provisions on the Data Protection Board applied on notification, the consent manager framework from 13 November 2026, and most obligations on Data Fiduciaries from 13 May 2027. An AI agent that reads or changes customer records is processing personal data, so the usual duties apply: a lawful basis, purpose limitation, reasonable security safeguards, breach notification, and honouring rights to access, correction and erasure. Significant Data Fiduciaries carry more, including an annual data protection impact assessment and audit, and a duty under Rule 13 to verify that algorithmic software they use is not likely to pose a risk to the rights of Data Principals. For agents, that is a direct requirement to understand and test what the software does with personal data. Notice and purpose deserve particular care. Personal data collected to open an account cannot simply be reused to train or run a new AI use without checking that the purpose is covered by the notice or another lawful basis. Agents also make it easy to copy data into new places, such as prompts, caches and logs, so map where personal data flows before an agent goes live, not after. Roles matter. When a bank uses a vendor's agent on its customer data, the bank is usually the Data Fiduciary and the vendor its Data Processor, under a contract. Our page on the DPDP Act and AI agents explains how this works for elan1's deployments, and our paper on DPDP and append-only logs covers erasure requests against records that cannot be edited. #### Other rules and regulators to watch Several existing instruments apply to AI systems already, without mentioning AI. - CERT-In's [directions of 28 April 2022](https://www.cert-in.org.in/Directions70B.jsp) under section 70B of the IT Act require specified cyber incidents to be reported within six hours and ICT system logs to be kept for 180 days within India. Logs from AI agents and the systems they touch are part of that estate. - RBI's KYC directions (Master Direction on KYC, 2016, as amended) govern customer due diligence, whether a person or a model does the first review. - RBI's outsourcing and IT governance directions apply when an AI capability is bought from a vendor or runs on a third party's infrastructure. - SEBI and IRDAI have their own supervisory expectations for the entities they regulate; check their current circulars rather than relying on summaries. #### An evidence table for a bank or NBFC Supervisors and auditors will ask to see that controls operate. This table maps the main expectations to the records worth keeping. It is a starting point, not legal advice. Expectations and the evidence to keep: | Expectation | Source | Record to keep | | Board oversight of AI | FREE-AI governance pillar; MeitY accountability Sutra | Board-approved AI policy, minutes, named owners | | Know your AI | FREE-AI governance pillar | AI inventory with purpose, data, vendor and risk tier | | Human accountability | FREE-AI and MeitY Sutras | Per decision: who reviewed, approved or overrode, and when | | Explainable outcomes | Understandable by design Sutra | The reason codes or explanation given to the customer | | Grievance redressal | FREE-AI Recommendation 18 | Complaints about AI decisions and their resolution | | Security and logs | DPDP Act s.8(5); CERT-In directions | System and agent logs kept 180 days in India; breach records | | Algorithmic due diligence | DPDP Rules, Rule 13 (Significant Data Fiduciaries) | Test results and reviews of algorithmic software | | Assurance | FREE-AI assurance pillar | Independent audit reports, drift and bias monitoring, incident log | For decisions made with AI, such as alert triage or credit pre-screening, the per-decision record is the hardest to produce after the fact. Build it in from the start: the input, the model's answer and confidence, the route it took, the reviewer and the final decision. Keep the institution-level records current too. An inventory that was accurate at the board meeting and stale three months later gives false comfort; tie updates to the change process, so a new model or vendor cannot go live without an inventory entry and a risk tier. #### A 90-day plan for a bank or NBFC 1. Days 1–30: inventory and ownership. List every AI system and agent in use, including models inside vendor products, with an owner, purpose, data and customer impact. Assign each a risk tier. Draft or refresh the board AI policy. 2. Days 31–60: controls by tier. For high-impact uses, such as credit, collections, fraud and AML, confirm human accountability per decision, the explanation given to customers, the grievance route and the records kept. Check data processing against the DPDP Act and log retention against CERT-In's directions. 3. Days 61–90: assurance. Commission an independent review of one high-impact use. Set up AI incident reporting into existing operational risk processes. Report the inventory, tiers and findings to the board. The plan does not need new systems to begin. Most of the first month is finding out what is already running, and that alone is usually the most useful finding. #### How elan1 handles this For banks and NBFCs, elan1 Decide and elan1 Govern implement maker-checker AI for banks. elan1 Decide gives each answer a calibrated confidence and routes it by risk; answers below your threshold reach a person. AML and KYC decision packs package common cases. Every answer is kept with its route and reviewer in the AI decision audit log, and any write that follows goes through elan1 Govern's rule check, named approver and proof record. Records stay in India: elan1 runs in AWS Mumbai, and proof records never leave the residency domain they were written in (see data residency in India). The collect1 pack configures elan1 Govern for RBI collection rules. elan1 helps produce evidence for these expectations; it does not make an institution compliant on its own. #### Frequently asked questions Q: What is RBI's FREE-AI framework? A: FREE-AI is the report of an RBI committee on a Framework for Responsible and Ethical Enablement of Artificial Intelligence, published on 13 August 2025. It sets out 7 Sutras, 6 pillars and 26 recommendations for responsible AI adoption in India's financial sector. Q: Is FREE-AI binding on banks and NBFCs? A: Not in itself. FREE-AI is a committee report with recommendations, some addressed to RBI to issue guidance. Regulated entities should still treat it as the supervisor's stated expectation, and existing binding directions on KYC, outsourcing, IT governance and data protection already apply to AI. Q: What are MeitY's India AI Governance Guidelines? A: They are cross-sector, voluntary guidelines released by MeitY on 5 November 2025. They set out seven principles shared with FREE-AI, recommendations across six pillars, an action plan and implementation guidance, and they propose coordinating institutions such as an AI Governance Group. Q: How does the DPDP Act apply to AI? A: Whenever an AI system processes digital personal data, the DPDP Act's duties apply: lawful basis, purpose limitation, security safeguards, breach notification and data principal rights. The Rules were notified on 13 November 2025 and most obligations apply from 13 May 2027; Significant Data Fiduciaries must also verify their algorithmic software. Q: What evidence should a bank keep for AI decisions? A: For each AI-assisted decision, keep the input, the model's answer and confidence, the route it took, the reviewer and the final decision, plus any explanation given to the customer. At institution level, keep the board-approved AI policy, the AI inventory, audit reports, incident records and logs retained as CERT-In requires. #### Sources [1] FREE-AI Committee Report: Framework for Responsible and Ethical Enablement of Artificial Intelligence (13 August 2025), Reserve Bank of India. https://www.rbi.org.in/Scripts/PublicationReportDetails.aspx?UrlPage=&ID=1306 [2] India AI Governance Guidelines (5 November 2025), Ministry of Electronics and Information Technology, via PIB. https://static.pib.gov.in/WriteReadData/specificdocs/documents/2025/nov/doc2025115685601.pdf [3] The Digital Personal Data Protection Act, 2023 (No. 22 of 2023), Ministry of Electronics and Information Technology. https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf [4] Digital Personal Data Protection Rules, 2025, Ministry of Electronics and Information Technology. https://www.meity.gov.in/documents/act-and-policies/digital-personal-data-protection-rules-2025-gDOxUjMtQWa [5] Directions under section 70B(6) of the Information Technology Act, 2000 (28 April 2022), CERT-In. https://www.cert-in.org.in/Directions70B.jsp [6] Master Direction – Know Your Customer (KYC) Direction, 2016, as amended, Reserve Bank of India. https://www.rbi.org.in/CommonPerson/english/scripts/notification.aspx?id=2607 ### Tally to ERPNext migration: a step-by-step guide URL: https://elan1.ai/guides/tally-to-erpnext-migration Author: M. K. Elango · Published 2026-10-10 · Updated 2026-10-10 Moving from Tally to ERPNext means exporting masters and balances from Tally, mapping them to ERPNext's chart of accounts, parties, items and tax templates, importing them in a dry run, reconciling the trial balance and GST figures, and going live only after your chartered accountant signs off the tie-out. Key takeaways: - Move at a period end, ideally the start of a financial year, and bring across masters, opening balances and open documents. Leave closed history in Tally, preserved and readable. - Never go live on the first import. Do a dry run in a copy of ERPNext and reconcile the trial balance, receivables, payables, stock and GST figures to the rupee. - Your chartered accountant should sign off the tie-out before go-live, and the old Tally data and its edit log must be kept for the statutory retention period. #### Should you move? Signs Tally is limiting you Tally is fast, familiar and understood by almost every accountant in India. Many businesses should stay on it. A move to ERPNext, an open-source ERP built on the Frappe framework, makes sense when the business has outgrown what an accounting package does well, not because a new system is fashionable. The usual signs: several people need to work on the same books from different places at once; sales, purchasing, stock and manufacturing live in spreadsheets around the ledger; you need approvals and workflows, not only entries; you want your own reports and integrations through an API; or you want AI agents to draft work in the system, with permissions and a record. If none of these applies, the cost and disruption of a migration may not be worth it. Stay put, or delay, if you are in the middle of an audit, a GST notice or a funding round, or if nobody in the business has time to own the project for a few weeks. Migrations fail for lack of an owner more often than for technical reasons. What usually changes when you move from Tally to ERPNext: | Area | Typical Tally setup | Typical ERPNext setup | | Access | Installed per machine or served on a local network | Browser-based; hosted in the cloud or on your own server | | Scope | Accounting, inventory and statutory reports | Accounting plus selling, buying, stock, manufacturing, projects and HR modules | | Workflow | Entries by users with ledger-level permissions | Role permissions, document workflows and approvals | | Integration | Import and export files, connectors | REST API and webhooks on every document type | | Licensing | Commercial licence | Open-source software; you pay for hosting, support and implementation | #### What moves: masters, opening balances, open documents, history What to bring across, and how: | Data | Move it? | How in ERPNext | | Chart of accounts | Yes, mapped and cleaned | Chart of Accounts Importer | | Customers and suppliers, with GSTINs and addresses | Yes | Data Import | | Items, units, HSN/SAC codes, warehouses | Yes | Data Import | | Opening ledger balances | Yes, at the cut-over date | An opening journal entry | | Unpaid sales and purchase invoices | Yes, as opening invoices | Opening Invoice Creation Tool | | Stock quantities and values | Yes, at the cut-over date | Stock reconciliation | | Closed vouchers from past years | Usually no | Keep in Tally, read-only, for the retention period | Bringing every historical voucher across is tempting and rarely worth it. It multiplies the reconciliation work, and the history is already final, filed and audited in Tally. Move balances and open items; keep history where it was created, preserved and readable. #### Plan: cut-over date, financial-year boundary, freezing Tally Choose the cut-over date first; everything else follows from it. The cleanest is the first day of a financial year, after the previous year is closed, because opening balances are then the audited closing balances. A quarter or month end works too, but you will reconcile a part-year in two systems. Then set a freeze: a date after which nobody posts to the old period in Tally except agreed closing adjustments, each one logged. Name an owner in the business and an owner on the accounting side, usually your chartered accountant, and agree in writing what “reconciled” means before you start. Plan for a short parallel period in which new transactions go into ERPNext while late adjustments to the old period still go into Tally. #### Map the chart of accounts, parties, items and GST templates Mapping is where most of the real work happens. Tally's groups and ledgers do not map one-to-one to ERPNext's account tree, and a migration is the best chance you will get to clean up duplicates, dormant ledgers and accounts used inconsistently. - Chart of accounts. Map every Tally ledger to an ERPNext account, merging duplicates and retiring dormant ones. Keep a mapping sheet; your auditor will want it. - Parties. Customers and suppliers need clean names, GSTINs, state codes and billing addresses, because GST place-of-supply logic depends on them. - Items. Codes, units, HSN or SAC codes and tax categories. Merge items that differ only in spelling. - Tax templates. Set up GST sales and purchase templates in ERPNext, typically with the India Compliance app, and map each Tally tax ledger to them. - Cost centres and dimensions. Decide what you will track, rather than copying every Tally cost centre. ##### Keep a mapping sheet Record every decision in one sheet with four columns: the Tally ledger or master, the ERPNext record it maps to, the reason for any merge or change, and who agreed it. A few illustrative rows for a fictional company, Kolam Components*: “Freight Inward” and “Freight Charges” both map to “Freight and Forwarding Charges” because they were used interchangeably; “Suspense A/c” is cleared before cut-over rather than migrated; each GST ledger maps to a tax template account. Illustrative specimen. Not customer data. Frappe's guide to preparing and mapping legacy data is a good checklist for this stage. #### Export from Tally and import into ERPNext TallyPrime can export masters, vouchers and reports in formats including Excel and XML. Export the masters, the trial balance at the cut-over date, the outstanding receivables and payables with invoice detail, and the stock summary by item and warehouse. In ERPNext, import in dependency order: the chart of accounts first, then parties and items, then tax templates, then opening balances, opening invoices and opening stock. Use the Data Import tool's preview to catch errors before records are created, and import in batches you can check. Scripts can automate the transformation between Tally's export and ERPNext's import templates, but every script output should still be reviewed against the source. #### The dry run and the reconciliation Do the whole import first into a copy of ERPNext that nobody uses for real work. Then reconcile, and do not move on until every figure ties. [Figure] The six steps. The dry run and reconciliation are repeated until every figure ties; only then does anything go live. - Trial balance: every account in ERPNext equals its mapped Tally ledger(s) at the cut-over date. - Receivables and payables: party-wise balances and invoice-wise ageing match. - Stock: quantities by item and warehouse match, and the stock value equals the stock ledger balance. - GST: input tax credit balances in the electronic credit ledger agree with the books; open invoices carry the right GSTINs and place of supply. - Spot checks: a sample of parties, items and invoices opened and compared field by field. Keep the reconciliation workpapers. They are the evidence that the opening position in ERPNext is the closing position in Tally, and your auditor will ask for them in the first audit after the move. #### CA sign-off and go-live When the dry run ties, your chartered accountant reviews the tie-out and signs it. That sign-off is not a formality: the CA will audit or review the first year in ERPNext, and the opening balances are part of that work. Then repeat the import in production, using the same files and scripts, and run the same reconciliation again. Set a lock date in Tally so the old period cannot change, export Tally's data and its edit log in a readable form, and store them for the statutory retention period: eight years for books of account under the Companies Act, and for GST, until 72 months after the due date of the annual return for the year, under section 36 of the CGST Act. #### After go-live: e-invoicing, the edit log and user roles - E-invoicing. Businesses whose aggregate annual turnover has exceeded ₹5 crore in any year since 2017-18 must issue e-invoices for B2B supplies. Since 1 April 2025, taxpayers with turnover of ₹10 crore or more cannot report an e-invoice to the IRP more than 30 days after its date, per the GSTN advisory. Configure and test e-invoice generation before the first live invoice. - Edit log. Companies must keep an audit trail that cannot be disabled under the MCA audit trail rule. In ERPNext, enable the India Compliance audit trail setting from day one; once on, it cannot be switched off. - User roles. Give each person, integration and AI agent its own user with the narrowest role that works. Shared logins defeat the edit log. - First close. Run the first month-end close with your CA watching, and fix the process before habits form. #### Common pitfalls, and how to avoid them - Duplicate parties. The same customer appears twice in Tally under slightly different names, sometimes with different GSTINs for different states. Decide whether they are one party with several addresses or genuinely separate before import. - Negative stock. Tally often allows stock to go negative; ERPNext, by default, does not. Fix negative balances in Tally, or post the missing entries, before you take the stock snapshot. - The opening balance difference. Opening invoices are posted against a temporary opening account in ERPNext. After all opening entries, that account must net to zero. If it does not, something is missing or counted twice. - Unreconciled bank accounts. Reconcile every bank account in Tally to the cut-over date first. Otherwise old uncleared cheques become a mystery in the new system. - Round-off and suspense ledgers. Clear them before cut-over rather than carrying unexplained balances into a clean chart. - Users who learn on go-live day. Train the people who will post entries on the dry-run copy, with real examples, before production opens. #### Cost and time There is no honest single figure for what a Tally to ERPNext migration costs or how long it takes in general. It depends on the number of ledgers, parties and items, how clean they are, whether stock and manufacturing are involved, and how quickly the business can answer mapping questions. Be wary of anyone who quotes a market average without seeing your data. What we can give is our own list price: elan1's Tally to ERPNext migration is ₹24,999 one-time, exclusive of GST, and includes a dry run, reconciliation and CA sign-off. The time it takes is mostly the time your team needs to clean and confirm the masters; the import itself is the quick part. #### How elan1 handles this elan1 Work runs governed AI agents for ERP on ERPNext, hosted by elan1 or attached to your own instance. The migration follows the steps in this guide, with a dry run, a reconciliation and your CA's sign-off before go-live, at the same price whether hosted or attached. After the move, ERPNext AI agents can draft entries, invoices and reconciliations, and each change passes a rule check, a named approver where your rules ask, and leaves a proof record. Plans are set by turnover band; see elan1 Work plans by turnover. Most small firms come to us through your CA, whose seat is always free. #### Frequently asked questions Q: How long does a Tally to ERPNext migration take? A: It depends on how many ledgers, parties and items you have, how clean they are and how quickly your team can confirm the mapping. The import itself is quick; cleaning masters, the dry run and the reconciliation take most of the time, so plan around your team's availability rather than a generic estimate. Q: Can I keep my GST history? A: Yes, by keeping it where it was filed. GST returns are already filed and history stays final in Tally, so you move opening balances and open invoices and keep Tally's data, read-only, for at least 72 months after the due date of each year's annual return. Q: What data moves and what does not? A: Masters, opening ledger balances at the cut-over date, unpaid invoices and opening stock move. Closed vouchers from past years usually stay in Tally, preserved and readable, because moving them multiplies reconciliation work without changing anything already filed. Q: Do I need my CA involved? A: Yes. Your chartered accountant should agree what reconciled means, review the tie-out of the trial balance, receivables, payables, stock and GST, and sign it off before go-live, because they will audit or review the first year in ERPNext. Q: What does it cost? A: There is no reliable market average, because cost depends on data volume and quality. elan1's own Tally to ERPNext migration is ₹24,999 one-time, exclusive of GST, including a dry run, reconciliation and CA sign-off. #### Sources [1] Export Data in TallyPrime, Tally Solutions, TallyHelp. https://help.tallysolutions.com/export-data-in-tally/ [2] Data Import, Frappe Documentation (ERPNext). https://docs.frappe.io/erpnext/data-import [3] Chart of Accounts Importer, Frappe Documentation (ERPNext). https://docs.frappe.io/erpnext/chart-of-accounts-importer [4] Import Outstanding Invoices (Opening Invoice Creation Tool), Frappe Documentation (ERPNext). https://docs.frappe.io/erpnext/opening-invoice-creation-tool [5] Prepare and Map Legacy Data, Frappe Documentation (ERPNext). https://docs.frappe.io/erpnext/prepare-and-map-legacy-data [6] Audit Trail, India Compliance documentation. https://docs.indiacompliance.app/docs/miscellaneous/audit_trail [7] Advisory: Time limit for reporting e-invoices on the IRP portal, threshold lowered to AATO ₹10 crore (from 1 April 2025), GSTN e-invoice system. https://einvoice1.gst.gov.in/Documents/advisory270325.pdf ### AI for chartered accountants in India: a guide URL: https://elan1.ai/guides/ai-for-chartered-accountants Author: M. K. Elango · Published 2026-10-10 · Updated 2026-10-10 Chartered accountants in India can use AI to draft entries, reconcile GST data and prepare returns, provided every change to a client's books is reviewed, attributable and recorded. The safe pattern is an AI agent that proposes, a CA who approves consequential changes, and an audit trail the CA can read. Key takeaways: - AI already saves real time in a CA practice: drafting entries from documents, reconciling bank and GST data, and preparing returns and notice replies for review. - Judgement, sign-off and confidentiality stay with the CA. The safe pattern for client books is an agent that proposes, a CA who approves consequential changes, and a record the CA can read. - Every AI-made entry still has to sit in an edit log that meets the MCA audit trail rule, attributed to its own user, and client data has to be handled under the DPDP Act. #### Where AI helps a CA practice today Most of the hours in a small or mid-sized CA practice go into work that is necessary, repetitive and checkable: turning bank statements and invoices into entries, matching records against each other, preparing returns and drafting replies. That is exactly where current AI is useful, because the output can be reviewed before it matters. Practice work where AI can draft and a person reviews: | Work | What AI can do | What the CA checks | | Bookkeeping | Draft entries from bank statements, invoices and bills; suggest ledgers | Classification, period, unusual items | | Bank reconciliation | Match statement lines to entries; flag unmatched items | Unmatched and partially matched items | | GST input tax credit | Match the purchase register to GSTR-2B; list mismatches | Credit eligibility and follow-up with suppliers | | Return preparation | Prepare GSTR-1 and GSTR-3B drafts from the books | Figures, exceptions, the decision to file | | Notices | Summarise a notice, gather relevant entries, draft a reply | Legal position, tone, what to concede | | Management reports | Draft monthly MIS and variance commentary | Interpretation and what to tell the client | In each case the AI does the first pass and the CA does the part that needs professional judgement. The gain shows up as fewer hours on preparation and more on review and advice, which is also the more valuable work. Know the weak spots too. Language models can state a section number, a due date or a rate with confidence and be wrong, especially after a recent notification. They struggle with poor scans and handwritten bills, and they cannot know what the client did not tell you. Treat any statement of law in an AI draft as unverified until you have checked it against the current notification, and keep a person on anything that depends on facts outside the documents. #### What must stay with the CA Three things cannot be handed to a tool. - Judgement. Whether a receipt is income or an advance, whether a credit is eligible, whether a provision is needed: these are professional calls, and an AI suggestion is an input to them, not a substitute. - Sign-off. Audit reports, certificates and filings carry the CA's name and membership number. The responsibility does not move because a model drafted the working. The Standards on Auditing, including those on audit evidence and documentation, still govern any audit work AI assists. - Confidentiality. The ICAI Code of Ethics requires members to protect client information. Pasting a client's ledger into a consumer chatbot that may retain or train on it is hard to reconcile with that duty. The practical test is simple. For any AI-assisted output, could you explain to the client, the department or a peer reviewer what you checked and why you accepted it? If not, the review was not real. #### AI agents in client books: propose, approve, record Drafting outside the books is one thing; an agent that changes the books is another. When an agent can post entries in a client's accounting system, use a three-part pattern. 1. Propose. The agent drafts the change, a journal, an invoice, a reconciliation adjustment, as a draft or staged entry, not a posted one. 2. Approve. Rules decide what can post on its own, such as routine entries within limits, and what waits for the CA, such as entries above a value, entries to closed periods, or anything touching tax ledgers. 3. Record. Every proposal, approval and refusal is recorded with the rule that applied, linked to the entry number in the books. This pattern also answers the question clients ask most: “who is responsible if the AI gets it wrong?” The client remains responsible for its books, and the CA for the work they sign; the record shows exactly which entries the CA approved and which posted within agreed limits. For an example, see a small firm's journal entry, read by its CA, an illustrative specimen. #### The MCA audit trail and Rule 11(g) when AI posts For corporate clients, every entry, including one an agent posts, must sit in accounting software whose edit log records each change and its date and cannot be disabled, under the proviso to Rule 3(1) of the Companies (Accounts) Rules, 2014. As statutory auditor, you report on it under Rule 11(g). Two consequences for AI. Give each agent its own user in the client's software, so the edit log attributes its changes to the agent rather than to you or to the client's accountant. And when you audit a client that uses agents, test the controls around them as well as the log: who can change the agent's permissions, what it may post without approval, and whether its changes reconcile to its records. The ICAI implementation guide on Rule 11(g) sets the reporting framework, and our guide to the MCA audit trail covers the detail. For clients you only advise, the same points are good practice: ask to see the agent's permissions, the limits on what it can post alone and a month of its records before you rely on books it has touched. A short written note of what you checked protects both the client and the firm. #### GST: reconciliation, e-invoices and returns with review GST work suits AI well because so much of it is matching. Input tax credit depends on the supplier's invoices appearing in the recipient's GSTR-2B, under section 16(2)(aa) of the CGST Act, so a monthly match of the purchase register against GSTR-2B, with mismatches listed by supplier, is valuable and easy to check. The Invoice Management System on the GST portal, where recipients act on supplier invoices, makes timely matching more important still. E-invoicing adds deadlines. Clients whose aggregate turnover has exceeded ₹5 crore in any year since 2017-18 must issue e-invoices for B2B supplies, and since 1 April 2025 those with turnover of ₹10 crore or more cannot report an invoice to the IRP more than 30 days after its date, under the GSTN advisory. An agent that watches for invoices approaching the limit prevents a lost invoice from becoming a lost credit for the customer. Returns themselves should stay with review. Let AI prepare GSTR-1 and GSTR-3B drafts and the list of exceptions; let the CA decide what to file. #### Data protection: client data, the DPDP Act and residency Client books contain personal data: names, PANs, bank details and salaries. Under the Digital Personal Data Protection Act, 2023, whoever decides why and how that data is processed is a Data Fiduciary, with duties of purpose limitation, security and breach notification; a firm processing data on a client's instructions acts for it. The DPDP Rules, 2025 bring most of those duties into force from 13 May 2027. Before you use any AI tool on client data, ask four questions: where is the data stored and processed, is it kept in India, is it used to train anyone's model, and what does the contract say about deletion and breaches? Put the answers in your engagement letters, along with what the client must tell you, such as which systems hold its books and who may approve changes, and what you will do if a tool is found to have mishandled data. Our page on the DPDP Act and AI agents shows how one vendor answers them. #### Practice economics: pricing AI-assisted work honestly Suppose an engagement used to take 20 hours and now takes 8: billing 20 is not sustainable once clients notice, and they will, while billing 8 at the old rate gives away the investment you made. Most firms that handle this well move routine compliance to fixed monthly fees, priced on the value and the risk carried rather than the hours, and say plainly that AI does the preparation and a CA does the review. Be specific about what the fee buys: the scope of review, the response time, who signs. The review is the product. Clients pay a CA for judgement and accountability, and AI makes it possible to spend more of the fee on exactly that. #### Moving clients off Tally Many clients who want agents in their books will need a system with an API, user roles and approval workflows, and for many small businesses that means moving from Tally to an ERP such as ERPNext. The CA's role in that move is central: agreeing the mapping, reviewing the reconciliation and signing off the opening position. Plan the move for a quiet month, ideally the start of a financial year, and keep the old data readable for the full retention period. Our step-by-step guide to Tally to ERPNext migration sets out the process and the evidence to keep. #### ICAI guidance to follow Start with the guidance that already governs practice. The Code of Ethics governs confidentiality, professional competence and due care. The Standards on Auditing govern evidence and documentation in any audit AI assists. The implementation guide on Rule 11(g) governs audit trail reporting. ICAI's boards and committees publish technology guidance and training; check the ICAI website for the current material rather than relying on summaries. Document your own policy too: which tools the firm uses, for what, with which client data, and how outputs are reviewed. A peer reviewer will ask. #### Getting started: a 60-day plan for a practice 1. Days 1–10: choose one workflow and three clients. Bank reconciliation or GSTR-2B matching are good first choices: high volume, easy to check. Pick clients whose books are already in reasonable order. 2. Days 11–20: write the firm's AI policy. Which tools, for which work, with which client data, where the data is stored, and how output is reviewed and recorded. Add a clause to engagement letters. 3. Days 21–40: run it alongside the old way. Do the work both ways for one cycle and compare. Note what the AI got wrong and how long review took. 4. Days 41–50: set the limits. Decide what can post without the CA, if anything, and what always waits. Write the limits as rules, per client. 5. Days 51–60: review and extend. Show the results to the partners, adjust the policy, and add the next workflow or the next set of clients. Keep the comparison data from the parallel run. It is the evidence for your pricing conversation with clients and for your own peer review. #### How elan1 handles this “elan1 Work for small firms, through your CA” is built around this pattern. An AI agent drafts and applies changes in a client's ERPNext books; each change passes a rule check, waits for the CA where the rules ask, and leaves a proof record the CA can read. CA seats are free for every client site, always, and the multi-client console is included. See AI for chartered accountants: governed client books. The compliance filing pack, ₹1,999 per month exclusive of GST, prepares GSTR-1 and GSTR-3B, runs the GSTR-2B reconciliation and monitors e-invoices, all for review. Data stays in India, in AWS Mumbai. #### Frequently asked questions Q: Which AI tools can chartered accountants use? A: CAs can use AI for drafting entries from documents, bank and GSTR-2B reconciliation, return preparation, notice summaries and MIS commentary, provided a CA reviews the output. Choose tools that keep client data in India, do not train on it, and leave a record of what was generated and approved. Q: Can AI post entries in client books? A: Yes, if the agent proposes and the CA or rules decide. Routine entries within agreed limits can post on their own; entries above a value, to closed periods or touching tax ledgers should wait for the CA, and every change should be recorded and appear in the edit log under the agent's own user. Q: How does AI affect the MCA audit trail? A: It does not change the rule: every entry, including an AI-made one, must appear in an edit log that records each change and its date and cannot be disabled. The agent needs its own user so changes are attributed correctly, and auditors should test the controls around the agent under Rule 11(g). Q: Who is responsible for an AI-made entry? A: The company remains responsible for its books, and the CA for the work they sign. A record showing which entries the CA approved and which posted within agreed limits makes that division clear. Q: How should a CA firm price AI-assisted work? A: Move routine compliance towards fixed fees priced on value and risk rather than hours, and be open that AI prepares and a CA reviews. Define what the fee buys, including the scope of review, response times and who signs. #### Sources [1] Implementation Guide on Reporting on Audit Trail under Rule 11(g) (Revised 2024 Edition), The Institute of Chartered Accountants of India. https://eirc-icai.org/uploads/background_materials/Revised%202024_Implementation%20Guide%20on%20Reporting%20of%20Audit%20Trail%20%281%29_1712114860.pdf [2] Code of Ethics and Standards on Auditing (current editions), The Institute of Chartered Accountants of India. https://www.icai.org/ [3] Advisory: Time limit for reporting e-invoices on the IRP portal (from 1 April 2025), GSTN e-invoice system. https://einvoice1.gst.gov.in/Documents/advisory270325.pdf [4] Central Goods and Services Tax Act, 2017, section 16 (eligibility for input tax credit), Central Board of Indirect Taxes and Customs. https://cbic-gst.gov.in/ [5] The Digital Personal Data Protection Act, 2023, Ministry of Electronics and Information Technology. https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf [6] Digital Personal Data Protection Rules, 2025, Ministry of Electronics and Information Technology. https://www.meity.gov.in/documents/act-and-policies/digital-personal-data-protection-rules-2025-gDOxUjMtQWa [7] Notifications under the Companies Act, 2013, including the Companies (Accounts) Amendment Rules, 2021, Ministry of Corporate Affairs. https://www.mca.gov.in/content/mca/global/en/acts-rules/ebooks/notifications.html ### AI for AML alert triage and KYC review URL: https://elan1.ai/guides/aml-kyc-ai-triage Author: M. K. Elango · Published 2026-10-10 · Updated 2026-10-10 AI can triage AML alerts and KYC reviews by scoring each case and routing it by risk, provided its confidence is calibrated on the institution's own cases. High-confidence low-risk cases can be prepared automatically; everything else goes to an analyst, and every decision, with its route and reviewer, is recorded. Key takeaways: - Use AI to score, summarise and route AML alerts and KYC reviews, not to close them. Closing an alert or filing a report stays a human decision. - A raw model score is not a probability. Calibrate it on your own cases before you let any route depend on it, and re-check it as behaviour drifts. - Route by risk and confidence, then record every decision with its route, reviewer and reasons. Measure each route's precision and recall, not just the fall in alert volumes. #### The triage problem Banks, NBFCs and payment companies in India must monitor transactions and report suspicious ones to the Financial Intelligence Unit, FIU-IND, under the Prevention of Money-laundering Act, 2002 and its rules. Most monitoring still starts with rules: thresholds, velocity checks and typology scenarios. Rules are explainable and easy to audit, but they are blunt, so they generate many alerts that turn out, on review, to be ordinary activity. Every alert needs an analyst to gather the customer's profile, recent transactions and any adverse information, then decide whether to close it, escalate it or file a report. The work is repetitive, time-bound and error-prone at volume. KYC review has the same shape: periodic updates of customer information, re-verification and checks against lists, many of them routine and a few that matter a great deal. The FATF's 2021 report on new technologies for AML/CFT describes how AI and analytics can make this work more accurate and better targeted, and it is equally clear that human review remains essential. The task is to use AI to put analyst time where the risk is, without letting it decide what only an accountable person should. #### Where AI fits: scoring, summarising, routing, not closing What to give AI, and what to keep with people: | Task | AI's role | Person's role | | Alert scoring | Estimate how likely an alert is to need escalation | Set and review the thresholds | | Case preparation | Gather profile, transactions, linked accounts and adverse media into a summary | Check the summary against source records | | Routing | Send each case to the right queue by score and risk tier | Own the routing policy | | Disposition | Draft a closure or escalation note with reasons | Decide to close, escalate or file | | Reporting | Prepare a draft suspicious transaction report | The Principal Officer decides whether to file | The line is simple: AI may prepare, a person decides. Even where your policy lets low-risk, high-confidence alerts be closed with light review, a named analyst should own each closure, and a sample should be re-reviewed. A regulator asking why an alert was closed expects to hear about a person's decision, supported by the evidence the AI gathered. Keep the data the model sees to what the decision needs. An alert-triage model rarely needs a customer's full document images; a case summary rarely needs every field in the core banking record. Minimising inputs reduces the personal data processed under the DPDP Act, narrows what can leak, and makes the model's reasoning easier to explain. #### Calibrated confidence: a raw score is not a probability Most models output a number between 0 and 1. It is tempting to read 0.9 as “90% likely”. It usually is not. A well-known study by Guo and colleagues (2017) showed that modern neural networks are often overconfident: their stated confidence is higher than their actual accuracy. Large language models asked to rate their own certainty can be worse. Calibration fixes this. A model is calibrated when, among all cases it scores at 0.9, about 90% turn out to be true positives. You calibrate on your own labelled cases, from your own customers and typologies, by comparing scores with outcomes and fitting a correction. A reliability diagram, which plots predicted confidence against observed frequency, shows at a glance whether the model is over- or under-confident in each band. Calibrate before automating anything, and re-check regularly. Customer behaviour, fraud patterns and the model's inputs drift, and a model that was calibrated last year may not be now. A route that depends on a confidence threshold is only as good as the calibration behind it. Illustration: Suppose that during a trial a model marks 1,000 alerts as “no escalation needed” with a raw score above 0.9, and analysts later escalate 60 of them. The model's real accuracy in that band is 94%, not the 99% its scores implied, and those 60 cases are exactly the ones an automatic route would have closed. Calibration on your own cases exposes this before customers or examiners do. The figures are illustrative, not from any institution. #### Routing by risk: four routes Combine two inputs: the calibrated score, and a risk tier your policy assigns from the customer, the product and the typology. Then give each case one of four routes. [Figure] Each case gets a calibrated score and a policy risk tier, takes one of four routes, and ends in a recorded decision with its route. - Prepare automatically. Low-risk tier and high calibrated confidence that no escalation is needed. The AI prepares the case and the closure note; an analyst confirms in bulk, and a sample is re-reviewed. - Analyst review. Anything below the confidence threshold, or in a medium-risk tier. The analyst sees the case summary and the score side by side. - Second pass. Conflicting signals, such as a low score but a new adverse media hit. A more thorough check runs, by a stronger model or a senior analyst, before routing again. - Hold for a person. High-risk tiers, politically exposed persons, sanctions near-matches, or missing data. A senior analyst decides; nothing is prepared to close. Write the thresholds down, version them and record which version applied to each case. When you change a threshold, you should be able to show what it would have done to last month's cases. #### KYC review: documents, periodic updates and adverse media, with a checker RBI's Master Direction on KYC requires customer due diligence at onboarding and periodic updation of KYC by risk: at least once every two years for high-risk customers, every eight years for medium-risk and every ten years for low-risk. Much of that work is routine: checking that documents are valid and consistent, confirming that nothing has changed, and screening names against lists and adverse media. AI can read documents, extract and compare fields, flag inconsistencies, summarise adverse media and draft the reviewer's note. The reviewer, the checker, confirms the result. Keep a checker on anything that changes a customer's risk rating, restricts an account, or rests on an adverse media match, because these affect customers directly and are the decisions most likely to be questioned. Periodic updation also has a customer-facing side. The Master Direction asks regulated entities to give customers at least three advance intimations before KYC falls due, including at least one by letter, with clear instructions and the consequences of not updating. AI can draft, personalise and schedule those notices and read the replies, while a person handles the exceptions: customers who dispute a change, cannot provide documents or ask for help. #### Explainability and the record regulators expect RBI's FREE-AI report includes “understandable by design” among its seven Sutras, and its protection and assurance pillars expect explanations, grievance routes and audit. For alert triage, that means each decision should come with reasons a supervisor can follow: which factors raised or lowered the score, what the summary drew on, and what the analyst concluded. Record, for every case: the alert or review trigger, the inputs used, the model version and calibrated score, the risk tier, the route and the threshold version, the analyst and their decision, the reasons, and timestamps. Link it to the case management system's identifier. This is the record that answers the question every examiner eventually asks: “why was this alert closed, and who decided?” Prefer structured reasons to free text. A short list of reason codes, such as “salary credit pattern consistent with profile” or “counterparty previously reviewed”, lets you count how often each reason closes an alert, spot reasons that are being overused, and test whether the AI's suggested reasons match the analyst's. Free-text notes are still useful, but they are hard to measure, so keep both. #### Measuring it: precision, recall, drift and overrides Alert reduction is the number vendors like to quote, and on its own it is the wrong one. Closing more alerts faster is only good if the alerts that mattered still reached a person. Measure each route separately: - Recall of escalations: of the cases that were ultimately escalated or reported, what share did the AI route to review, second pass or hold? This is the safety metric. - Precision of each route: of the cases routed to review, how many needed it? This is the efficiency metric. - Below-threshold sampling: re-review a random sample of auto-prepared closures every month, and treat any missed escalation as an incident. - Calibration drift: compare predicted confidence with outcomes each month, by band. - Overrides: how often analysts disagree with the AI's suggestion, and in which direction. A rising rate is an early warning. Report these to the committee that owns the AML programme, not only to the team that runs the model. The NIST AI RMF Measure function describes the same discipline in general terms. #### A pilot design: shadow mode first Do not switch AI triage on and watch the backlog fall. Run it in shadow mode first: the AI scores, summarises and suggests a route for every case, but analysts work exactly as before and do not see the suggestion until they have decided. After a period long enough to include your usual mix of typologies, compare the two. - Label the shadow-period cases with the analysts' final outcomes, and calibrate the scores against them. - Measure what each proposed route would have done: how many eventual escalations would have been auto-prepared? The target is none. - Read a sample of AI case summaries against source records for accuracy and omissions. - Agree thresholds, routes and the sampling rate with the AML committee and record the approval. - Switch on one route at a time, usually analyst review with AI summaries first, and automatic preparation last. The shadow period also gives you the baseline that makes later measurement honest. Without it, any claim about time saved or alerts reduced is a guess. #### How elan1 handles this elan1 Decide is built for this pattern. Each alert or review becomes a typed decision with a tested confidence from the Calibration Lab: no calibration, no automation (see calibrated confidence). The Router can route AI decisions by risk: automatic, human review, a System-2 second pass, or hold. Unsure cases reach the human review queue, where the analyst sees the case and the score side by side. Decision packs package AML alert triage, KYC review and disputes as ready sets of decisions, routes and review rules. Every answer is kept in the Decision Ledger with its route and reviewer, and any write that follows, such as a change to a customer's risk rating, goes through elan1 Govern's rule check, named approver and proof record. See AML, KYC and disputes for banks and NBFCs. #### Frequently asked questions Q: Can AI close AML alerts on its own? A: It should not. AI can score alerts, prepare the case and draft a closure note, but a named analyst should own each closure, and the decision to file a suspicious transaction report stays with the institution's Principal Officer. Even low-risk, high-confidence closures should be confirmed and sampled. Q: What is calibrated confidence? A: Calibrated confidence means a model's stated confidence matches how often it is right: among cases scored at 0.9, about 90% turn out positive. Raw model scores are often overconfident, so you calibrate them on your own labelled cases and re-check them as behaviour drifts. Q: How do regulators view AI in AML? A: Regulators and standard setters support well-governed technology in AML. The FATF's 2021 report sees real gains from AI and analytics but stresses that human review remains important, and RBI's FREE-AI report expects explainable outcomes, human accountability and independent assurance. Q: How do I audit AI-assisted KYC decisions? A: Keep a record for every case: the trigger, inputs, model version and calibrated score, risk tier, route and threshold version, the reviewer, the decision and the reasons, with timestamps. Then re-review samples and measure each route's precision and recall against final outcomes. Q: Where should a human always decide? A: A person should always decide on closing or escalating high-risk cases, filing suspicious transaction reports, changing a customer's risk rating, restricting an account, and any decision resting on a sanctions near-match or adverse media. These affect customers and are the decisions most likely to be examined. #### Sources [1] Opportunities and Challenges of New Technologies for AML/CFT (July 2021), Financial Action Task Force. https://www.fatf-gafi.org/en/publications/Digitaltransformation/Opportunities-challenges-new-technologies-for-aml-cft.html [2] Master Direction – Know Your Customer (KYC) Direction, 2016, as amended, Reserve Bank of India. https://www.rbi.org.in/CommonPerson/english/scripts/notification.aspx?id=2607 [3] Financial Intelligence Unit – India (reporting under the Prevention of Money-laundering Act, 2002), FIU-IND, Ministry of Finance. https://fiuindia.gov.in/ [4] FREE-AI Committee Report: Framework for Responsible and Ethical Enablement of Artificial Intelligence (13 August 2025), Reserve Bank of India. https://www.rbi.org.in/Scripts/PublicationReportDetails.aspx?UrlPage=&ID=1306 [5] On Calibration of Modern Neural Networks (Guo, Pleiss, Sun and Weinberger, ICML 2017), arXiv. https://arxiv.org/abs/1706.04599 [6] NIST AI 100-1, AI Risk Management Framework 1.0, NIST. https://doi.org/10.6028/NIST.AI.100-1 ## Glossary (full definitions) ### AI agent governance URL: https://elan1.ai/resources/glossary/ai-agent-governance The controls that decide what an AI agent may change, who must approve it and what evidence is kept. AI agent governance is narrower than AI model governance. Model governance asks whether a model is fit for use; agent governance asks what an agent may do once it can act: which records it may change, which changes need a named person, and what is kept as evidence. It works best at the write itself. Prompt guardrails and tool permissions help, but the dependable control is one path every consequential change must take, with versioned rules, a named approver where the rules ask, and a tamper-evident record of each outcome, allowed or refused. Where this shows up in elan1: The whole of elan1 Govern: the Right Path, named approvers and a proof record for every write intent. ### AI audit trail URL: https://elan1.ai/resources/glossary/ai-audit-trail A linked record of every action an AI system proposed, the rules checked, who approved it and the outcome. Most logs record what a tool did. An AI audit trail also records why it was allowed: which rules ran, at which version, which gates passed and who approved. Without the policy decision, a log shows activity but cannot show control. Refused actions belong in the trail too. In elan1 every write intent, allowed or refused, ends in one proof record, and records are SHA-256 hash-chained, so a change to an earlier record is evident. Where this shows up in elan1: The 16-field proof record elan1 Govern writes for every write intent, allowed or refused. ### Allow URL: https://elan1.ai/resources/glossary/allow Govern's decision that a write may happen. Only elan1 Govern produces one; a model never does. An allow is the end of a climb, not a single check. The write intent passes STOP, IDENTITY and the WRITE DOOR, the nine pre-gates, evaluate() with versioned rules, the blast-radius guardrail and the autonomy check. Where the autonomy level asks for it, a named person who is not the asker says yes. No model sits on the allow path. A model may draft the change; Decide may propose the answer; a Run guard verdict may be an input. None of them is the allow. If Decide and Govern disagree, Govern wins. Where this shows up in elan1: Rungs 0b to 6 of the Right Path in elan1 Govern; every allowed write ends in a proof record. ### Assurance level URL: https://elan1.ai/resources/glossary/assurance-level A level of claim about the evidence (L1, L2, L3), never a product tier. Levels describe what you can rely on. They are not tiers you buy. L1 asks "Can I let this run?", L2 asks "Can I hand this over?", and L3 asks "Does this survive the vendor?" Every claim on this site is tied to the level and the mode in which it is true. L1 Guarded and L2 Attested are available; L3 Proven begins on an outside auditor's written acceptance. Where this shows up in elan1: On every capability claim, the claims register and the proof-record specimens. ### Autonomy level URL: https://elan1.ai/resources/glossary/autonomy-level How much an agent may do alone, A0 to A5; recorded on every proof record. The autonomy level decides whether a person must say yes. Above the ceiling a write type is allowed to run at, a named approver who is not the asker sees the difference, the gates and the policy, and decides. Earned autonomy uses a deterministic score, with no model involved. The level a write actually ran at is sealed into its record, so an auditor can see when a person was in the loop and when not. Where this shows up in elan1: Rung 6 AUTONOMY on the Right Path, and field F11 `autonomy_level` on every proof record. ### Conformance URL: https://elan1.ai/resources/glossary/conformance Passing a published test suite before making a claim: K1–K7 for Run components, C1–C14 for third-party agents. Suite K1–K7 is blocking-green and runs offline, including on your auditor's machine. A component that fails it does not replace the one in service. Third-party agents connect in Mode B, or Mode A by agreement. They make no claim to run on Govern until conformance tests C1–C14 pass. Where this shows up in elan1: elan1 Run's conformance suite, and the bar a third-party agent clears before it claims to run on Govern. ### Contract URL: https://elan1.ai/resources/glossary/contract One of ten versioned `fusion.*/v1` capability contracts in elan1 Run, each with two licence-clean implementations. The ten contracts are chat, gateway, inference, retrieval, vectors, trace, tools, run, memory and guard. A call names its contract in the `X-Fusion-Contract` header. Because every contract has two licence-clean implementations, a component can be replaced without rebuilding the integration. Run never depends on Govern: infrastructure gets swapped, but the write path must not. Where this shows up in elan1: elan1 Run, beneath the fusion.*/v1 seam — one of the only two crossings between layers. ### Declaration URL: https://elan1.ai/resources/glossary/declaration A process's rules in seven blocks: what may change, under which gates, who approves. Versioned. Every record names the declaration it was checked against, and which version was in force. Change the rules and the version moves; old records still point at the rules that applied to them. Decide's Decision Packs compile to the same seven blocks, so there is one rule format across the layers. Where this shows up in elan1: Declaration Studio in elan1 Govern; fields F06 `declaration_id` and F07 `declaration_version` on every proof record. ### Design partner URL: https://elan1.ai/resources/glossary/design-partner An early-adopter organisation that puts one real process on the governed path with us and shapes what comes next. Ten places. A design partner brings one process where a person already signs off, a named approver and a named owner. We configure it with them to its first governed write. We publish nothing about a design partner without written consent. An anonymised specimen appears only if the partner agrees. Where this shows up in elan1: The design partner programme for the launched platforms, open now. ### Fail toward a human URL: https://elan1.ai/resources/glossary/fail-toward-a-human When anything is unclear or unavailable, elan1 stops and asks a person. If elan1 is down, allows stop and changes wait for a person. If the runtime fails, writes stop. If nobody answers an approval before it expires, expiry means refusal. Stopping allows is the safe direction. A delayed change costs time; a wrong change committed to the books costs far more. Where this shows up in elan1: The failure rules of elan1 Govern and elan1 Run, and approval expiry on rung 6. ### Gate URL: https://elan1.ai/resources/glossary/gate A check a write must pass. Pre-gates G1–G9 run at rung 3; six can never be skipped. Gates run against your own data before anything is written. In elan1 Work, G1 Ledger, G2 Stock, G3 Permissions, G4 GST and G8 MCA all run before any write. A failed gate is a refusal with a typed code. The refusal still writes a proof record and costs 40% of one governed action. Where this shows up in elan1: Rung 3 PRE-GATES of the Right Path; elan1 Work builds gates from your own books. ### Governed action URL: https://elan1.ai/resources/glossary/governed-action One consequential write that passed the Right Path and was committed; Govern's meter unit. Paid per governed action. A refusal costs 40% of one. A credit in elan1 Work is a rendering of governed actions, never a separate count, so you never pay twice for one change. Every governed action has exactly one proof record and one meter event at rung 9 METERED. Where this shows up in elan1: elan1 Govern's meter, and the unit every other layer's charges render into rather than double-count. ### Governed write path URL: https://elan1.ai/resources/glossary/write-path The one route through which every AI agent change to a system of record must pass. The route is checked, approved and recorded. A governed write path separates proposing from writing. AI agents, people and elan1 Decide may propose changes as write intents; only the kernel in elan1 Govern writes to the system of record, using a single-use credential. Because there is one path, there is one place to check rules, one place for approvals and one record of every outcome. In Mode A elan1 holds the credential, so the path is enforced; in Mode B every write intent is evaluated and recorded, and enforcement is yours. Where this shows up in elan1: elan1 itself: the kernel in elan1 Govern is the single writer, and every write climbs the Right Path. ### Guardian agent URL: https://elan1.ai/resources/glossary/guardian-agent Gartner's term for software that inspects agent actions and allows, blocks or holds them for a person. The term describes a job rather than a product: something that sits between an AI agent and what it acts on, inspects each proposed action and decides whether it proceeds. Gartner uses it as a market category name; this glossary uses it only in that descriptive sense. elan1 Govern does that job for writes to systems of record. A model never makes the allow: rules, gates and a named person do, and every outcome is recorded. Naming the category is not a claim that elan1 has been assessed in it. Where this shows up in elan1: elan1 Govern does this job at the write: it checks each write intent and allows it, refuses it or holds it for a named approver. ### Hash chain URL: https://elan1.ai/resources/glossary/hash-chain Records where each one carries the digest of the one before, so altering one breaks every later link. Each record's digest is computed over its own fields, including the previous record's digest. Change any earlier record and its digest changes, so the next record's link no longer matches, and nor does any link after it. A hash chain shows that something changed; it does not show who changed it, and it does not stop the change. That is why elan1 adds signatures and outside timestamps from L2 Attested. Where this shows up in elan1: Field `prev_digest` on every proof record, sealed under Seal v6 with SHA-256. ### Human-in-the-loop approval URL: https://elan1.ai/resources/glossary/human-in-the-loop A named person decides before a consequential change is made, with enough context to say no. An approval counts only when the approver can understand what will change and can refuse it. In elan1 the approver sees the change, the rule that held it and the consequence, and the approver is never the asker. Not every change needs a person. Routine changes inside limits can run alone at the autonomy level your declaration sets; changes above a risk threshold wait for a named approver, and if nobody answers before the hold expires, expiry means refusal. Where this shows up in elan1: Rung 6 AUTONOMY of the Right Path, where the autonomy level and your rules decide whether a named approver must say yes. ### Kernel URL: https://elan1.ai/resources/glossary/kernel elan1 Govern's core: one write function behind KernelPort. No other product builds gates, approvals, proof or a meter. The Right Path lives in the kernel, and only Govern owns it. Work, Decide and Run never build their own gate, approval store, seal, meter or verifier. The earlier names "the elan1 kernel" and "the elan1 layer" now refer to elan1 Govern. Where this shows up in elan1: Plane P3 of the reference architecture — the kernel is shut; no other layer adds code there. ### KernelPort URL: https://elan1.ai/resources/glossary/kernelport The only door into the kernel: define, assert, seal, verify, scope, refuse. KernelPort v1 has six calls. An MCP server (34 tools) and an HTTP API serve the agents you already run. The record shape and KernelPort v1 are frozen; a breaking change ships as a new version. Layers meet in two places only — KernelPort and fusion.*/v1 — and CI fails the build anywhere else. Where this shows up in elan1: The seam between Work, Decide and Govern; also reached by third-party agents over MCP or HTTP. ### L1 Guarded URL: https://elan1.ai/resources/glossary/l1-guarded Records hash-chained so any change is evident to you. Available. L1 asks "Can I let this run?" It adds the Right Path, approvals, a single writer and a tamper-evident record you can read. At L1 you check a record by recomputing its digest and comparing it with prev_digest on the next record. Tamper-evident to you; not signed. Where this shows up in elan1: The baseline level of every governed write; the stamp at the foot of each specimen. ### L2 Attested URL: https://elan1.ai/resources/glossary/l2-attested Adds signatures, outside timestamps and a free offline verifier. Available. L2 asks "Can I hand this over?" From L2, each record is signed with Ed25519, Merkle roots are anchored to two RFC 3161 timestamp authorities within 15 minutes, and an eight-member evidence bundle can be checked offline on your own machine. Signing and the free offline verifier are both available. Records written before a tenant moves to L2 stay L1, labelled L1 for good. Where this shows up in elan1: elan1 Govern's evidence line from L2; the offline verifier explained on Verify a record. ### L3 Proven URL: https://elan1.ai/resources/glossary/l3-proven Evidence that survives the vendor. Starts when an outside auditor accepts an L2 bundle in writing; no date. L3 asks "Does this survive the vendor?" It is a receipt that outlives the vendor. We do not put a date on L3. It begins on an event we do not control: an outside auditor accepting an L2 bundle in writing. Where this shows up in elan1: The level reached on an outside auditor's written acceptance — never dated. ### Line URL: https://elan1.ai/resources/glossary/line A module of elan1 Work for one kind of work (ERP, Revenue, Voice, Commerce). Every line writes through elan1 Govern. elan1 Work ERP (with the Tally → ERPNext migration), elan1 Work Revenue, elan1 Work Voice and elan1 Work Commerce are all available. A line is always written with its platform at first mention ("elan1 Work ERP"), then short ("ERP"); never "elan1 Revenue". The small-firm edition crosses all lines and is not a line of its own. Where this shows up in elan1: The four elan1 Work lines, each with its own detail page and its own tab on the pricing page. ### Maker-checker URL: https://elan1.ai/resources/glossary/maker-checker One party prepares a change and a different, named party approves it. For AI, the model is the maker. Maker-checker, also called four-eyes, is a long-standing control in banking and finance: nobody approves their own work. Applied to AI, the model or agent prepares the change or the decision, and a named person checks it before it takes effect. In elan1, answers below your confidence threshold go to a reviewer in elan1 Decide, and any write that follows is held for a named approver in elan1 Govern where the rules ask. Both the maker and the checker are recorded. Where this shows up in elan1: Decisions routed to review in elan1 Decide, and every held write in elan1 Govern, where the approver is never the asker. ### MCA audit trail (edit log) URL: https://elan1.ai/resources/glossary/mca-audit-trail India's rule that a company's accounting software must keep an edit log of every change. The log cannot be disabled. The rule is the proviso to Rule 3(1) of the Companies (Accounts) Rules, 2014: accounting software must record an audit trail of each transaction, with an edit log of each change and the date it was made, and the feature must not be disabled. Auditors report on it under Rule 11(g) of the Companies (Audit and Auditors) Rules, 2014. When an AI agent posts entries, the edit log still lives in the accounting software. elan1 adds a second record: who or what proposed the change, which rules ran and who approved it, in a proof record your chartered accountant can read. Where this shows up in elan1: elan1 Work ERP on ERPNext, where the G8 MCA gate runs before any write and the ledger1 pack configures elan1 Govern for MCA requirements. ### Meter URL: https://elan1.ai/resources/glossary/meter The one unit each layer charges for: credit, decision, governed action, node-year. elan1 Work meters credits, elan1 Decide meters decisions, elan1 Govern meters governed actions and elan1 Run meters node-years. One unit per layer; never per seat or per outcome. A refusal is metered at 0.4 of a governed action: it uses 0.4 of an included action within the allowance, and costs ₹0.64 at L1 beyond it. Prices on this site are list prices, exclusive of GST. Where this shows up in elan1: Rung 9 METERED, and the pricing page's four meters. ### Mode A (Enforced) URL: https://elan1.ai/resources/glossary/mode-a-enforced elan1 in-process, holding the write credential. No write reaches the system of record without a gate decision and a proof record. In Mode A, elan1 holds the write credential, and only there do we say enforced. The single writer uses a 10-minute single-use credential held by the kernel. Third-party agents can run in Mode A by agreement, after conformance tests C1–C14 pass. Where this shows up in elan1: elan1 Work hosted on ERPNext, through the in-process SDK; the only place we say enforced. ### Mode B (Attested advisory) URL: https://elan1.ai/resources/glossary/mode-b-attested-advisory elan1 over MCP or HTTP, without the credential. Every write intent is evaluated and recorded. In Mode B we evaluate and record. We do not say a write was blocked, because elan1 does not hold the credential that makes it. elan1 Run tooling writes in Mode B and fails closed if elan1 is unreachable. Where this shows up in elan1: elan1 Work Attach, elan1 Decide, elan1 Run tooling and third-party agents. ### Module URL: https://elan1.ai/resources/glossary/module A named part of one platform, always shown with its platform at first mention (elan1 Decide Router, then Router). Never a separate product or brand; each has a detail page under its platform. Work's modules are called lines; L1, L2 and L3 are levels of a claim, not modules. elan1 Decide has six modules: Decision Studio, Router, Calibration Lab, Review Console, Decision Ledger and Decision Packs. elan1 Run has five: Contracts, Conformance, Substitution, Operate and Runtime Controls. Every module that leads to a consequential write sends it through elan1 Govern. All eleven modules are available. Where this shows up in elan1: The six elan1 Decide modules and the five elan1 Run modules, each with a detail page and a pricing tab. ### Pack URL: https://elan1.ai/resources/glossary/pack Configuration of Govern for a rule set — ledger1 (MCA), invoice1 (GST), collect1 (RBI). Never code, never a brand. elan1 owns the pack schema. A pack configures declarations and gates for a regulation; it never adds code to the kernel. Each pack lists how its gates map onto the nine kernel gates, and carries its own verifier profile where one applies. Where this shows up in elan1: Plane P8 of the reference architecture. ### Plane URL: https://elan1.ai/resources/glossary/plane One of nine architecture levels, P0 residency to P8 packs; the kernel is P3. From the top: P8 Packs, P7 Apps, P6 Channels, P5 Surfaces, P4 Declaration plane, P3 Kernel, P2 System of record, P1 Platform runtime, P0 Residency and tenancy. Four layers sit across the planes, and one assurance rail runs alongside them. Where this shows up in elan1: The interactive reference architecture. ### Proof record URL: https://elan1.ai/resources/glossary/proof-record The 16-field record written for every action, allowed or refused; SHA-256, chained. "No seventeenth field, ever." Each record is hashed with SHA-256 over a length-prefixed preimage and chained to the one before it. Change a past record and the chain shows it. That is what tamper-evident means at L1. Evidence rows cannot be updated or deleted. Wherever another surface shows a Govern decision, it carries one line: "Checked and recorded by elan1 Govern." Where this shows up in elan1: Rung 8 PROOF; every specimen on this site; the CA console in elan1 Work. ### Refusal URL: https://elan1.ai/resources/glossary/refusal A typed "no" from any rung. It still writes a proof record and costs 40% of one governed action. The caller receives a typed code from the frozen register; the record joins the chain; the meter shows 0.4 of a governed action. It costs less than an allowed write because nothing is written to your books. Refusals are information. They show how often agents propose writes your rules do not allow, and which rule said no. Where this shows up in elan1: Any rung of the Right Path; the refused-write specimen; the meter, at 0.4 of a governed action. ### Residency domain URL: https://elan1.ai/resources/glossary/residency-domain A region with its own database and signing key. Today there is one: "in" (Mumbai). Domain "in" runs on AWS ap-south-1 (Mumbai) across three zones. A cross-domain query is not slow; it is impossible. New regions open only on a signed contract, never a forecast; no US region is offered. Where this shows up in elan1: Plane P0; the security page; the DPDP regulation hub. ### Right Path URL: https://elan1.ai/resources/glossary/right-path The fixed route every write takes, from rung 0b STOP to rung 9 METERED. Five plain steps — ask, check, approve, act, record — map onto ten rungs. Any rung can refuse. Every consequential change takes the same path, wherever it starts: an agent, the Decide router or a person in the console. An undo changes the books too, so it takes the same path and leaves its own record. Where this shows up in elan1: The kernel of elan1 Govern; the walkthrough at See a governed action. ### Rung URL: https://elan1.ai/resources/glossary/rung One step on the Right Path: stop, identity, write door, pre-gates, evaluate, guardrail, autonomy, act, proof, metered. The rungs are 0b STOP, 1 IDENTITY, 2 WRITE DOOR, 3 PRE-GATES, 4 evaluate(), 5 GUARDRAIL, 6 AUTONOMY, 7 ACT, 8 PROOF and 9 METERED. Rungs 0b to 6 decide. Rung 7 makes the change through the single writer. Rungs 8 and 9 record and count it. Where this shows up in elan1: The Right Path in elan1 Govern; every refusal names the rung that said no. ### Seal URL: https://elan1.ai/resources/glossary/seal The method that turns a proof record into its digest: Seal v6, frozen. Seal v6 computes SHA-256 over a length-prefixed preimage of the 16 fields. The digest becomes the next record's F03 prev_digest, which is what links the chain. Because the method is frozen, anyone holding the records can recompute every digest the same way. From L2, the sealed digest is also signed. Where this shows up in elan1: Rung 8 PROOF; the specimen stamp; the L1 verification steps. ### Single writer URL: https://elan1.ai/resources/glossary/single-writer Only one component writes to the system of record, with a 10-minute single-use credential. In Mode A the kernel holds the credential. The change goes to a sandbox first, then to your system of record. Agents never hold a standing credential to your books. Each change gets one credential, used once, that expires in 10 minutes. Where this shows up in elan1: Rung 7 ACT; the write-path facts on the security page. ### Tamper-evident URL: https://elan1.ai/resources/glossary/tamper-evident A record where any later change can be detected. It does not claim that a change is impossible. Tamper-evident and tamper-proof are different claims. A tamper-evident record shows that a change happened; a tamper-proof one would claim a change cannot happen. elan1 makes only the first claim, because it is the one you can check. At L1 Guarded you check it yourself by recomputing the chain. From L2 Attested, signatures and outside timestamps let someone else, such as an auditor, check it without asking elan1. Where this shows up in elan1: Every proof record at L1 Guarded, where records are SHA-256 hash-chained. ### Write intent URL: https://elan1.ai/resources/glossary/write-intent A typed proposal to change a record. Agents and Decide may produce one; only Govern turns it into an allow. A write intent names the write type, the declaration it claims to fall under, the record it would change and a hash of the payload. Its identifier becomes F04 on the proof record, allowed or refused. "A model may produce a write intent. It may never produce an allow." Where this shows up in elan1: The input to KernelPort; field F04 `write_id` on every proof record. ## Library papers (abstracts and contents) ### The governed write path: an architecture paper URL: https://elan1.ai/resources/library/write-path-architecture Paper · Published · v1.0 · Ungated. No email needed to read or download. AI agents are starting to change systems of record: ledgers, invoices, claims and customer files. Most deployments govern the call — which model ran, what it cost — and leave the write itself to whatever credential the agent was given. This paper describes the alternative elan1 runs: a single, fixed route that every consequential write takes, owned by one component and ending in one record. It sets out the reference architecture (planes P0–P8), the Right Path from rung 0b STOP to rung 9 METERED, the two seams where layers meet (KernelPort v1 and fusion.*/v1), the single writer and its 10-minute single-use credential, and the failure rules. It states what each layer does, what it proves and what it does not. Contents: - 1. The problem: governing the write, not only the call: Why runtime controls and action governance are two different jobs. - 2. Planes P0–P8: Residency to packs; why the kernel at P3 is shut. - 3. The Right Path: Ten rungs, nine pre-gates, evaluate() with no model, the guardrail and autonomy. - 4. Two crossings: KernelPort's six calls and the ten fusion.*/v1 contracts; CI boundary checks. - 5. Modes A and B: Enforced where elan1 holds the credential; evaluated and recorded elsewhere. - 6. Failure directions: Why an outage stops allows, and expiry means refusal. - 7. Deployment choices: Rung 7 ownership, record location, key model, DPDP erasure. ### Evidence for auditors: reading an elan1 proof record URL: https://elan1.ai/resources/library/evidence-for-auditors Brief · Published · v1.0 · Ungated. No email needed to read or download. An auditor asked to rely on an AI agent's change needs three things: who proposed it, under which rules it was checked, and who approved it. This brief shows where each answer sits in an elan1 proof record, and how to test that the record has not changed since it was sealed. It covers L1 Guarded checks you can run yourself, the evidence bundle and offline verifier of L2 Attested, and a plain table of what verification proves and what it does not. It is written to be handed to an audit team without a sales conversation. Contents: - 1. The 16 fields, one question each: Chain, write, rules, actor, record, hashes, time. - 2. Walking the chain at L1: Recompute the digest, compare prev_digest, check seq. - 3. Refusals as evidence: Why a refused write leaves the same record, and why it costs 40% of a governed action. - 4. Mode A and Mode B: What "enforced" covers, and what "recorded" does not. - 5. From L2: the bundle and the verifier: Ed25519, Merkle roots, two RFC 3161 authorities. - 6. What verification does not prove: That the decision or the rules were right; activity outside elan1. ### An RFP question set for AI agents that write URL: https://elan1.ai/resources/library/rfp-question-set Question set · Published · v1.0 · free to reuse · Ungated. Free to reuse in your own RFPs. Most AI procurement questionnaires ask about models, data use and uptime. Few ask what happens at the moment an agent changes a record. This question set fills that gap. It is vendor-neutral by design: it does not assume elan1, and a vendor can answer it well without us. Questions are grouped by the moment they test — before the write, at the write, after the write and when something fails — and each one comes with the evidence a good answer should point to. Contents: - 1. Inventory and credentials: Which agents can write, and with what credential. - 2. Rules and approvals: Rules outside the model; a named approver who is not the requester. - 3. The record: One record per change; tamper evidence; hand-over without system access. - 4. Failure: What stops when the checking service is down. - 5. Residency, erasure and cost: Where logs live, how erasure works, what a refusal costs. - 6. Claims hygiene: How the vendor labels and levels its own claims. ### DPDP and the append-only chain URL: https://elan1.ai/resources/library/dpdp-and-the-append-only-chain Note · Published · v1.0 · not legal advice · Ungated. No email needed to read or download. An evidence chain is valuable because past records cannot be changed without the change showing. The DPDP Act gives people a right to erasure. These two facts meet in every system that keeps evidence about personal data, and we would rather state the tension than hide it. elan1's design keeps personal data out of evidence: the proof record holds F14 payload_hash, a hash of the payload, not the payload itself. An erasure request is honoured where the personal data lives, as a governed write that leaves its own record; the chain keeps only hashes. The note sets out the question that remains for each deployment — whether a hash of personal data is itself personal data — elan1's role under the Act, and the design options. Contents: - 1. What the Act asks: Erasure, security safeguards and notice, at a high level. Not legal advice. - 2. What the chain holds: Sixteen fields; hashes in place of payloads. - 3. Erasure as a governed write: Why an erasure goes through the Right Path and leaves a record. - 4. The remaining question: Whether a hash of personal data is itself personal data in this context. - 5. How elan1 handles it: Roles under the Act, the erasure write and what stays in the chain. ## Blog posts (full text) ### Fail toward a human URL: https://elan1.ai/blog/fail-toward-a-human Author: M. K. Elango · Published 2026-09-29 · Updated 2026-10-10 Every system fails. The design question is which way. When anything is unclear or unavailable, elan1 stops and asks a person. Every system fails eventually. The useful design question is not whether, but which way. For elan1 we wrote the answer as a rule: **when anything is unclear or unavailable, elan1 stops and asks a person.** #### The asymmetry A change that waits costs time. A wrong change committed to the books costs a correction, an explanation to an auditor and sometimes a restatement. Those costs are not symmetrical, so the failure direction should not be either. Stopping allows is the safe direction. #### What happens when Failure directions: | If… | Then… | | --- | --- | | elan1 Govern is unavailable | Allows stop. Changes wait for a person. | | The runtime is unavailable | Writes stop. | | elan1 is unreachable from Run tooling | The gate check fails closed. | | A named approver does not answer in time | The write expires. Expiry means refusal, with a record, metered at 0.4 of a governed action. | | elan1 Decide's confidence is below your threshold | The case goes to a person in the Review Console. | | A check cannot be completed | The write is refused with a typed code, never waved through. | #### The person is named, and is not the asker Failing toward a human only helps if the human can decide well. Where your autonomy level asks for a person, the approver is named, is never the one who proposed the change, and sees the difference, the gates and the policy before saying yes or no. Approvals arrive where people already work: the console, the CA console, through `/v1`, on WhatsApp or by voice. An approval that nobody answers does not quietly become an allow. The wait is held on Run's `run` contract, and expiry means refusal. A record is still written, so the queue that nobody cleared is visible later. #### What it costs Failing toward a human is slower, sometimes noticeably. A month-end close with a stalled approval waits. We think that is the right trade for writes that commit the business, and the wrong one for everything else — which is why the rule applies to consequential writes, not to reading, drafting or answering. > A runtime outage stops writes. An elan1 outage stops allows. Stopping allows is the safe direction. Available in elan1 Govern, Work, Decide and Run. Every Mode A onboarding includes a bypass test against the real system. ### Designing the 16-field proof record URL: https://elan1.ai/blog/designing-the-16-field-proof-record Author: M. K. Elango · Published 2026-09-15 · Updated 2026-10-10 "No seventeenth field, ever." Why the record has the fields it has, why it has no others, and why the payload itself stays out. The proof record has sixteen fields. We wrote "no seventeenth field, ever" into the design before we had finished arguing about the sixteen, because the hardest part of a record format is not choosing what goes in. It is refusing everything that wants to be added later. #### Seven questions, sixteen answers The fields, grouped by the question they answer: | Question | Fields | | --- | --- | | Which chain, and where in it? | F01 tenant_id · F02 seq · F03 prev_digest | | Which write? | F04 write_id · F05 write_type | | Under which rules? | F06 declaration_id · F07 declaration_version · F08 policy_version | | Who acted, and how freely? | F09 actor_id · F10 actor_kind · F11 autonomy_level | | What changed? | F12 record_id · F13 record_version | | What was said, in what words? | F14 payload_hash · F15 lexicon_hash | | When? | F16 recorded_at, with the time-zone offset | #### A hash of the payload, not the payload The most argued-over field is F14. The record holds a hash of the payload, not the payload itself. That keeps personal data out of evidence: a ledger line with a customer's name in it lives in your system of record, where your retention and erasure rules apply, and the evidence chain holds only a fingerprint of it. It also raises a question we have not hidden. How does erasure under India's DPDP Act work alongside an append-only chain? The [library note on DPDP](https://elan1.ai/resources/library/dpdp-and-the-append-only-chain) sets out elan1's role under the Act, how erasure works as a governed write, and the question that remains. #### Why the vocabulary is hashed too F15 `lexicon_hash` is the field people ask about most. A write is expressed in a vocabulary — what "posted", "approved" or "customer" mean in this tenant. If those meanings drift, an old record could be read in a new sense. Hashing the vocabulary pins the meaning that applied when the record was sealed. #### Why the count is fixed - **Every digest depends on the shape.** Add a field and every verifier must learn a new preimage. Seal v6 is frozen so that the method never moves under anyone's feet. - **Verifiers stay small.** From L2, a free offline verifier checks records on your own machine. A fixed shape keeps it small enough to read. - **New needs go elsewhere.** Anything new belongs in the declaration, which is versioned, or in the payload, which is hashed — never in the record. Refusals use the same sixteen fields. A refused write and an allowed write look alike on purpose: the difference is the verdict and the meter, not the format. You can see both side by side on the [specimens page](https://elan1.ai/resources/specimens). The record shape is frozen under Seal v6. Every specimen on this site is illustrative; values are invented. ### What tamper-evident means at L1 URL: https://elan1.ai/blog/what-tamper-evident-means-at-l1 Author: M. K. Elango · Published 2026-09-01 · Updated 2026-10-10 At L1 we make one integrity claim, and we chose the weakest honest word for it. Here is exactly what it covers and where it stops. At L1 Guarded, we make one claim about the integrity of the record: it is **tamper-evident to you**. Every word in that phrase is doing work, and this note explains each of them. #### The mechanism Every governed write, allowed or refused, produces a 16-field [proof record](https://elan1.ai/resources/glossary/proof-record). [Seal v6](https://elan1.ai/resources/glossary/seal) computes a SHA-256 digest over a length-prefixed preimage of those fields. The next record in the tenant's chain stores that digest in F03 `prev_digest`. F02 `seq` goes up by exactly one each time. 1. Recompute the digest of record n from its 16 fields. 2. Compare it with F03 `prev_digest` on record n + 1. 3. Check that F02 `seq` on record n + 1 is one more than on record n. 4. Walk the chain. A changed record breaks the next link; a missing record leaves a gap in `seq` and a mismatch in `prev_digest`. Length-prefixing matters more than it seems. Without it, two different records could serialise to the same bytes — the boundary between one field and the next could shift without changing the string. With a length in front of each field, there is only one way to read the preimage. #### Why "to you" A hash chain shows that something changed to anyone who holds an earlier digest. It does not, on its own, stop a party with full control of the store from rewriting a stretch of history and recomputing every digest after it. If you have kept digests — in your own systems, in a report, in an export — you would see the break. That is the honest scope of L1: evident to you, the holder of the records. Evidence rows cannot be updated or deleted, and the kernel is the single writer. Those are design facts that make tampering harder. They are not a promise a third party can check without us, so they are not what we claim. #### What changes from L2 From L2 Attested, each record is also signed with Ed25519, Merkle roots are anchored to two RFC 3161 timestamp authorities within 15 minutes, and a free offline verifier checks an eight-member evidence bundle on your own machine. Only at L2 do we use the words "signed" and "checkable offline", because only then can someone outside elan1 check the record without trusting us. What verification proves, and what it doesn't: | Proves | Does not prove | | --- | --- | | The record has not changed since sealed | The business decision was right | | Which rules and version applied | The rules were good | | Who acted, at what autonomy level | Nothing happened outside elan1 (Mode B) | #### The words we leave out We do not use stronger words at L1. Words that promise a record can never be changed, or that it will stand up in court on its own, describe what a third party can establish — and at L1 a third party cannot establish it without us. At L2 that changes, and the [claims register](https://elan1.ai/trust/claims) says so. L1 Guarded and L2 Attested are available. L3 Proven begins when an outside auditor accepts an L2 bundle in writing; it has no date. ### Two crossings: why the layers meet in only two places URL: https://elan1.ai/blog/two-crossings Author: M. K. Elango · Published 2026-08-25 · Updated 2026-10-10 Four layers, two seams. KernelPort is the way into Govern, fusion.*/v1 the way into Run, and the build fails if anything else crosses. elan1 is one write path in four layers: elan1 Work, elan1 Decide, elan1 Govern and elan1 Run. Four layers could easily become a web of private calls between them. We decided early that they would meet in exactly two places, and that the build would fail anywhere else. #### Crossing one: KernelPort [KernelPort](https://elan1.ai/resources/glossary/kernelport) v1 is the only door into Govern's kernel. It has six calls: define, assert, seal, verify, scope and refuse. Work reaches Govern through it. Decide reaches Govern through it. Third-party agents reach it over an MCP server (34 tools) or an HTTP API. Having one door means having one place to check. Every write intent from every layer climbs the same Right Path and ends in the same 16-field record. Nobody has a side entrance that skips a gate. #### Crossing two: fusion.*/v1 elan1 Run puts each part of the open-source AI stack behind a versioned [contract](https://elan1.ai/resources/glossary/contract): chat, gateway, inference, retrieval, vectors, trace, tools, run, memory and guard. A call names its contract in the `X-Fusion-Contract` header. Each contract has two licence-clean implementations and a conformance suite, K1–K7. The dependency runs one way. Run never depends on Govern. Infrastructure gets swapped; the write path must not. When Run substitutes a component, it asks Govern for a gate check at substitution step 7.3 and honours the answer — through the same door as everyone else. #### Modes follow the credential How each consumer connects: | Consumer | Mode | What we may say | | --- | --- | --- | | elan1 Work hosted (ERPNext) | A · SDK in-process | No write reaches the system of record without a gate decision and a proof record. | | elan1 Work Attach (your ERPNext) | B · MCP/HTTP | Evaluated against your rules and recorded. | | elan1 Decide | B · MCP/HTTP | Writes go to Govern as intents. | | elan1 Run tooling | B · MCP/HTTP | If elan1 is unreachable, the gate check fails closed. | | Third-party agents | B (A by agreement) | No claim to run on Govern until conformance tests C1–C14 pass. | The word "enforced" belongs to Mode A only, where Govern holds the write credential. Over MCP or HTTP, elan1 evaluates and records. We do not say it blocks, because it does not hold the key that makes the write. #### What builders get from the constraint - One integration surface to learn, with six calls whose names do not change: KernelPort v1 is frozen. - Typed refusals: when a write is turned down, your agent receives a code it can act on, not a string to parse. - Components you can replace without rebuilding the integration, with conformance you can run offline. KernelPort v1 and the record shape are frozen. elan1 Run is available. ### A model may produce a write intent, never an allow URL: https://elan1.ai/blog/a-model-may-produce-a-write-intent-never-an-allow Author: M. K. Elango · Published 2026-08-11 · Updated 2026-10-10 One sentence carries most of the architecture. Here is what it rules in, what it rules out, and why the allow path has no model on it. If you keep one sentence from elan1, keep this one: **a model may produce a write intent. It may never produce an allow.** Most of the architecture follows from it. #### Two different objects A [write intent](https://elan1.ai/resources/glossary/write-intent) is a typed proposal to change a record. It names the write type, the declaration it claims to fall under, the record it would change and a hash of the payload. An agent can produce one. elan1 Decide's router can produce one. A person in the console can produce one. An [allow](https://elan1.ai/resources/glossary/allow) is the decision that the write may happen. Only elan1 Govern produces one, at the end of a climb through rungs 0b to 6: stop, identity, write door, the nine pre-gates, `evaluate()`, the guardrail and the autonomy check. Illustrative specimen — the shape of a write intent. Not customer data. Exact field names are in the KernelPort v1 reference.: ``` write_intent write_id wr_specimen_7c2 write_type journal_entry.post declaration_id decl_month_end_close record_id je_specimen_5531 payload_hash sha256:51b0…7d9a proposed_by agt_specimen_ap01 (agent) ``` #### Why no model sits on the allow path The question Govern answers is "May this record change?" The answer has to be reproducible. Given the same intent, the same declaration version and the same policy version, the result must be the same today, next quarter and in front of an auditor. That is why every proof record carries F07 `declaration_version` and F08 `policy_version`: so the decision can be replayed against the rules that were in force. A model cannot make that promise, however good it is. So `evaluate()` runs versioned rules with no model in it. Earned autonomy — how much an agent may do alone — uses a deterministic score, with no model involved. A guard verdict from elan1 Run is an input, never the allow. #### What models are for This is not a position against models. They are good at the work that comes before the question: reading a document, drafting the journal entry, proposing which ledger a line belongs to. elan1 Decide gives a typed answer with a stated confidence and routes it by risk; below the threshold, a person decides. > Decide decides what the answer probably is. Govern decides whether any record changes. If they disagree, Govern wins. #### How we keep the rule true - Layers meet in two places only — KernelPort and `fusion.*/v1` — and CI fails the build anywhere else. - No product other than Govern builds a gate, an approval store, a seal, a meter or a verifier. - Where elan1 Work or elan1 Decide uses a model to draft, the product page names it in full. - An agent never approves its own change. Where a person must approve, the approver is named and is not the asker. elan1 Govern is available, with L1 Guarded and L2 Attested. ### Why a refusal costs 40% of a governed action URL: https://elan1.ai/blog/why-refusals-are-free Author: M. K. Elango · Published 2026-07-21 · Updated 2026-10-10 A refusal still runs the checks and writes a proof record, but nothing reaches your books. So it carries a reduced charge, never the full one. When we first priced elan1 Govern, a refusal was metered at ₹0. From 10 October 2026, a refusal costs 40% of one governed action at the same rate. This note explains why a refusal carries a charge at all, and why that charge is lower than for an allowed action. #### What a refusal still does A refusal is not thrown away. The checks run up to the rung that says no. The caller receives a typed code that names the reason. The record carries the same 16 fields as an allowed write, and it is sealed and chained like any other. That work is real, so it is charged. #### Why it costs less An allowed action does one thing a refusal never does: it changes your books. Rung 7 ACT commits the change, and that committed write is the unit we charge in full, a **governed action**. Rungs 0b to 6 of the [Right Path](https://elan1.ai/resources/glossary/right-path) can refuse, and a refused write stops before rung 7. Nothing is written to the system of record, so the charge is 40% of one governed action. #### The incentives we want Price a refusal like an allowed write, and a governance layer earns as much when it says no as when it says yes. Price it above an allowed write, and a team under budget pressure loosens a rule to save money. The rule was the point. At 40%, a refused write intent always costs less than the same intent allowed. Tightening a rule never makes a write intent cost more. Loosening one never makes it cost less. #### The line on the meter A refusal appears on the meter as its own line, at 0.4 of a governed action. That line matters more than it looks. It tells you how often your agents propose changes your rules do not allow, which rule said no, and at which rung. A rising refusal rate on one write type is an early signal: either the agent is drifting, or the rule no longer describes how the business works. Both are worth knowing. #### How a refusal is billed - Within your included allowance, each refusal uses 0.4 of an included governed action. - Beyond the allowance, a refusal costs ₹0.64 at L1 Guarded, ₹0.48 at L2 Attested, ₹0.36 at L3 Proven and ₹0.22 on a sovereign deployment: 40% of each per-action rate. - In elan1 Work, a change that Govern refuses uses 0.4 of a credit. The credit is the rendering of Govern's charge, so nobody pays twice. - In elan1 Decide, a write intent that Govern refuses is metered by Govern at 40% of a governed action. The decision itself is counted once, as a decision. - In elan1 Run, a call refused at the edge by Run's runtime controls returns a 409 before the first token, so no token is sent. It costs 40% of one governed action: ₹0.64 at the L1 rate. #### What this means for a budget - An allowed change costs one governed action; a refused one costs 0.4. There is no per-seat and no per-outcome pricing. - A stricter rule set never raises the cost of a write intent. - From L2, evidence is billed as its own line, so you can see what assurance costs separately from activity. Prices on this site are current list prices, exclusive of GST. The four meters, and the list prices behind them, are on the [pricing page](https://elan1.ai/pricing#compare). To see a refused write field by field, open [the refused-write specimen](https://elan1.ai/resources/specimens/refused-write). ## Platforms - [elan1 Govern](https://elan1.ai/platform/govern): AI agent governance; rule check, named human approver, 16-field hash-chained proof record; L1 Guarded, L2 Attested, L3 Proven. - [elan1 Work](https://elan1.ai/platform/work): governed AI agents on ERPNext (ERP, Revenue/CRM, Commerce, Voice); Tally to ERPNext migration; for Indian SMBs through their CA. - [elan1 Decide](https://elan1.ai/platform/decide): typed, calibrated AI decisions routed by risk (claims, AML, KYC, disputes). - [elan1 Run](https://elan1.ai/platform/run): contract layer and Day-2 operation for the open-source AI stack. - [elan1 Govern L1 Guarded](https://elan1.ai/platform/govern/l1): L1 Guarded gives every AI agent write the Right Path, a named approver, a single writer and a hash-chained, tamper-evident record you can read yourself. - [elan1 Govern L2 Attested](https://elan1.ai/platform/govern/l2): L2 Attested adds Ed25519 signatures, outside timestamps, an evidence bundle and a free offline verifier, so an auditor can check AI agent records alone. - [elan1 Govern L3 Proven](https://elan1.ai/platform/govern/l3): L3 Proven begins when an outside auditor accepts your L2 evidence bundle in writing. It has no date: what it means, what it costs and how a tenant gets there. - [elan1 Work ERP](https://elan1.ai/platform/work/erp): An AI agent drafts and applies changes in ERPNext, hosted or yours, with a rule check, a named approver and a proof record. Tally migration from ₹24,999. - [elan1 Work Revenue](https://elan1.ai/platform/work/revenue): elan1 Work Revenue lets an AI agent change your CRM with the same rule check, named approver and proof record as your books. Sits on an elan1 Work plan. - [elan1 Work Commerce](https://elan1.ai/platform/work/commerce): elan1 Work Commerce lets an AI agent propose prices, stock, refunds and order changes on your storefront, each checked, approved where needed and recorded. - [elan1 Work Voice](https://elan1.ai/platform/work/voice): elan1 Work Voice lets a named approver hear a pending AI agent change on the phone and say yes or no, with the same checks and proof record as the console. - [elan1 Decide Decision Studio](https://elan1.ai/platform/decide/decision-studio): Decision Studio in elan1 Decide writes the question before anyone answers it: typed Boolean, Choice and Score decisions, each with a fixed, checkable shape. - [elan1 Decide Router](https://elan1.ai/platform/decide/router): The elan1 Decide Router sends every AI answer one of four ways by risk tier: automatic, human review, a System-2 second pass, or hold for a person. - [elan1 Decide Calibration Lab](https://elan1.ai/platform/decide/calibration-lab): A confidence score means nothing until it is tested on your cases. Calibration Lab tests every decision first: no calibration, no automation. - [elan1 Decide Review Console](https://elan1.ai/platform/decide/review-console): The unsure cases go to a person. The elan1 Decide Review Console shows the case and the calibrated score side by side, and records what the reviewer decided. - [elan1 Decide Decision Ledger](https://elan1.ai/platform/decide/decision-ledger): The Decision Ledger keeps every elan1 Decide answer with its route and confidence. Its digest is bound into the proof record of the write that follows. - [elan1 Decide Decision Packs](https://elan1.ai/platform/decide/decision-packs): Decision Packs set up one kind of case once, such as claims triage, AML alert triage, KYC review or disputes, and compile it to elan1 Govern's declarations. - [elan1 Run Contracts](https://elan1.ai/platform/run/contracts): Write against the contract, never the component. elan1 Run defines ten fusion.*/v1 capability contracts, each with two licence-clean implementations. - [elan1 Run Conformance](https://elan1.ai/platform/run/conformance): elan1 Run Conformance is the K1–K7 suite: blocking-green, it runs offline, including on your auditor's machine, before any component claims a contract. - [elan1 Run Substitution](https://elan1.ai/platform/run/substitution): Replace a model or vector store without rebuilding the integration. elan1 Run Substitution takes nine steps with two human gates, never autonomous. - [elan1 Run Operate](https://elan1.ai/platform/run/operate): elan1 Run Operate runs the open-source AI stack after go-live and counts six runtime units, from tokens to GPU-seconds. Priced per node and GPU, not token. - [elan1 Run Runtime Controls](https://elan1.ai/platform/run/runtime-controls): elan1 Run Runtime Controls, with elan1 Govern built in: a budget hard-stop, cost attribution, a guard and tool authorisation for every model call. - [Agentic AI governance platform: four layers](https://elan1.ai/platform): One write path for every AI agent: elan1 Govern checks and records, Work runs agents on ERPNext, Decide routes decisions by risk, Run operates the stack. - [AI agent governance reference architecture](https://elan1.ai/platform/architecture): Nine planes from residency to packs, two seams and one write path: the reference architecture behind elan1, with the Right Path from rung 0b to rung 9. - [AI assurance levels: Guarded, Attested, Proven](https://elan1.ai/platform/assurance-levels): Three levels of claim about AI agent evidence: L1 Guarded is tamper-evident, L2 Attested is signed for auditors, L3 Proven begins on auditor acceptance. - [MCP governance and AI agent integrations](https://elan1.ai/platform/integrations): Connect AI agents through KernelPort, the elan1 MCP server or HTTP. Tools are split into read, stage and act classes, and every act goes through Govern. - [See a governed AI agent action: 5-minute demo](https://elan1.ai/see-it): Follow one AI agent write from request to record: the rule check, the hold for a named approver, the commit and the 16-field proof record. No sign-up. ## Guides - [AI agent governance guides: practical, sourced](https://elan1.ai/guides): Practical, sourced guides to governing AI agents that write: audit trails, human approval, MCP, EU AI Act, MCA audit trail, Tally to ERPNext and CA practice. - [AI agent governance: a practical guide for 2026](https://elan1.ai/guides/ai-agent-governance): How to govern AI agents that write to business systems: inventory, write paths, rules, human approval, audit trails and evidence, with a 30-day plan. - [Human-in-the-loop for AI agents that isn't theatre](https://elan1.ai/guides/human-in-the-loop-ai-agents): Human-in-the-loop for AI agents done properly: when to ask a person, who that person is, what they must see, maker-checker, risk thresholds and fatigue. - [AI agent audit trail: what to record, field by field](https://elan1.ai/guides/ai-agent-audit-trail): What an AI agent audit trail should record for each action, why the policy decision matters, and the difference between tamper-evident and immutable logs. - [EU AI Act and AI agents: logging and oversight](https://elan1.ai/guides/eu-ai-act-ai-agents): What the EU AI Act asks of AI agents that act: risk classes, Article 12 logs, Article 14 oversight, deployer duties under Article 26 and the timetable. - [MCA audit trail Rule 3(1) explained for AI-era books](https://elan1.ai/guides/mca-audit-trail-rule-3-1): India's MCA audit trail rule explained: what Rule 3(1) asks of accounting software, what auditors report under Rule 11(g), and what AI agents change. - [Tally to ERPNext migration: a step-by-step guide](https://elan1.ai/guides/tally-to-erpnext-migration): How to move from Tally to ERPNext without losing GST history or a clean trial balance: masters, opening balances, dry run, reconciliation and CA sign-off. - [MCP server security and governance for write tools](https://elan1.ai/guides/mcp-server-governance): How to secure and govern MCP servers whose tools can write: read, stage and act classes, least privilege, credentials, approvals and an audit trail per call. - [AI for chartered accountants in India: a guide](https://elan1.ai/guides/ai-for-chartered-accountants): How CA firms in India can use AI on client books safely: where AI helps, what must stay with the CA, GST and MCA audit trail duties, and practice economics. - [RBI FREE-AI and India's AI governance guidelines](https://elan1.ai/guides/india-ai-governance-rbi-free-ai): What RBI's FREE-AI framework and MeitY's India AI Governance Guidelines ask of banks, NBFCs and firms using AI agents, plus the DPDP Act and evidence to keep. - [AI for AML alert triage and KYC review](https://elan1.ai/guides/aml-kyc-ai-triage): How banks and NBFCs can use AI to triage AML alerts and KYC reviews safely: calibrated confidence, risk-based routing, maker-checker review and audit trail. ## Regulation - [EU AI Act Articles 12 and 14 for AI agents](https://elan1.ai/regulation/eu-ai-act): What the EU AI Act asks for logs (Article 12) and human oversight (Article 14) when AI agents act, and how elan1 proof records and named approvers help. - [ISO 42001 audit evidence for AI agents](https://elan1.ai/regulation/iso-42001): What an ISO/IEC 42001 auditor asks for when AI agents act, from Annex A event logs to human oversight, and how elan1 produces it one action at a time. - [NIST AI RMF for AI agents: Govern to Manage](https://elan1.ai/regulation/nist-ai-rmf): How the NIST AI RMF's Govern, Map, Measure and Manage functions apply to AI agents that act, and where elan1 turns written policy into per-action evidence. - [DPDP Act 2023 and AI agents: roles and residency](https://elan1.ai/regulation/india-dpdp): How India's DPDP Act, 2023 applies when AI agents touch personal data: elan1's role per deployment, data kept in India, and who handles legal action. ## Evidence and trust - [AI agent audit trail: the 16-field proof record](https://elan1.ai/platform/proof-record): Every AI agent action, allowed or refused, leaves a 16-field proof record, SHA-256 hash-chained. See each field, recompute a digest and check the chain. - [Trust and evidence: claims, security, verification](https://elan1.ai/trust): Everything elan1 claims and the level at which it becomes true: claims register, security and residency, disclosures, roadmap and how to verify a record. - [AI vendor claims register: what we say and don't](https://elan1.ai/trust/claims): elan1's claims register: what we say, what we don't, and the level at which each claim becomes true. Tamper-evident at L1, enforced only in Mode A. - [How to verify an AI agent proof record yourself](https://elan1.ai/trust/verify): Check an elan1 proof record without asking us: recompute the SHA-256 digest, walk the hash chain and, from L2, check the signature with the offline verifier. - [Security and data residency in India](https://elan1.ai/trust/security): How elan1 is secured and where your data lives: AWS Mumbai across three zones, one signing key per residency domain, and proof records that never leave it. - [Disclosures: launch status and product limits](https://elan1.ai/trust/disclosures): Launched, and plain about it: what elan1 makes available, what each platform does not do, and the limits you should plan around before you buy. - [elan1 roadmap: available today, improving in order](https://elan1.ai/trust/roadmap): What elan1 has available today and what improves next, in order, with no invented dates. L3 Proven is event-gated: it begins on auditor acceptance. - [AI agent governance pricing: pay per governed action](https://elan1.ai/pricing): List prices for elan1 Govern, Work, Decide and Run in INR, per governed action, credit, decision or node-year. A refusal costs 40% of one action. Excl. GST. ## Docs - [Docs overview](https://elan1.ai/docs): KernelPort's six calls, the MCP server and HTTP API, and the ten fusion.*/v1 contracts on one page. - [Quickstart](https://elan1.ai/docs/quickstart): From one process to a first governed write: choose a mode, declare the rules, assert a write intent, handle the outcome, verify the record. - [Core concepts](https://elan1.ai/docs/concepts): The model in one page: write intents and allows, four layers and two seams, declarations, the Right Path, the proof record and the meter. - [The Right Path](https://elan1.ai/docs/right-path): Every rung from 0b STOP to 9 METERED: what each checks, how it refuses, and where a person decides. - [Modes and assurance levels](https://elan1.ai/docs/modes-and-levels): Mode A and Mode B decide what elan1 can enforce; L1, L2 and L3 decide what a record can prove, and to whom. - [KernelPort v1](https://elan1.ai/docs/kernelport): The six calls into elan1 Govern — define, assert, seal, verify, scope, refuse — with illustrative requests and responses. - [MCP server](https://elan1.ai/docs/mcp-server): 34 tools in three classes — read, stage and act — for agents that already speak MCP, in Mode B. - [HTTP API](https://elan1.ai/docs/http-api): The /v1 endpoint families, tokens and scopes, idempotency by write_id, and the response envelope. - [Errors and refusals](https://elan1.ai/docs/errors-and-refusals): The typed refusal envelope, how it differs from a platform error, and how a caller should handle each. - [Declarations](https://elan1.ai/docs/declarations): A process's rules in seven versioned blocks, and how every record names the declaration and version it was checked against. - [Proof record](https://elan1.ai/docs/proof-record): The 16 Seal v6 fields, the length-prefixed SHA-256 preimage, chaining by prev_digest, and recomputing a chain at L1. - [fusion.*/v1 contracts](https://elan1.ai/docs/fusion-contracts): Ten capability contracts in elan1 Run, the X-Fusion-Contract header, and two licence-clean implementations each. - [Conformance](https://elan1.ai/docs/conformance): Suite K1–K7 for Run components and C1–C14 for third-party agents: what each proves and how to run it offline. - [Glossary](https://elan1.ai/docs/glossary-links): Every governed-action term, defined in one sentence and linked to its glossary entry and the docs pages that use it. - [Changelog](https://elan1.ai/docs/changelog): Versions of this documentation and what changed in each. ## Solutions - [AI agent governance by role, industry and regulation](https://elan1.ai/solutions): Start with the question your room asks first: operators, risk and audit, builders, banks, insurers and accounting firms, plus EU AI Act, ISO 42001 and DPDP. - [Human-in-the-loop AI agents for operations](https://elan1.ai/solutions/operators): The agent drafts it; a person you name commits it. elan1 gives operations teams AI agents that change records only with a rule check and a named approver. - [Audit evidence for every AI agent action](https://elan1.ai/solutions/assurance): For risk, audit, legal and CISOs: every AI agent action leaves a proof record you can read, sign from L2 and check offline, mapped to EU AI Act and ISO 42001. - [Safe AI agent write access to production systems](https://elan1.ai/solutions/builders): Your agents propose; one kernel allows. Give AI agents write access to ERP and production systems through KernelPort, MCP or HTTP, with typed refusals. - [Maker-checker AI for banks: AML, KYC, disputes](https://elan1.ai/solutions/bfsi): For banks and NBFCs: AI drafts AML alert triage, KYC review and dispute decisions with a stated confidence, and a named person checks anything below the line. - [AI claims triage with human review for insurers](https://elan1.ai/solutions/insurance): Routine claims work, with a person where it matters: AI triages claims with calibrated confidence, sends unsure cases to a reviewer, records each decision. - [AI for chartered accountants: governed client books](https://elan1.ai/solutions/accounting-firms): elan1 Work for small firms, through your CA: an AI agent changes your client's ERPNext books, and you read and approve every change. CA seats are always free. ## Resources - [AI agent governance resources: papers and glossary](https://elan1.ai/resources): Read it, check it, use the words: ungated papers, a 12-question AI agent readiness check, a glossary of 39 terms and illustrative proof records. - [AI agent governance papers and briefs, ungated](https://elan1.ai/resources/library): Four ungated papers: the governed write path architecture, evidence for auditors, an RFP question set for AI agents that write, and DPDP and append-only logs. - [The governed write path: an architecture paper](https://elan1.ai/resources/library/write-path-architecture): An architecture paper on the governed write path for AI agents: nine planes, two crossings, a single writer and the Right Path every write must climb. - [AI audit evidence: how auditors read a proof record](https://elan1.ai/resources/library/evidence-for-auditors): A paper for auditors: how to read an elan1 proof record field by field, recompute its digest, walk the chain and test the evidence for AI agent actions. - [RFP questions for AI agents that write](https://elan1.ai/resources/library/rfp-question-set): An RFP question set for buying AI agents that write to your systems: who may write, who approves, what is recorded and how you check it without the vendor. - [DPDP Act and append-only audit logs](https://elan1.ai/resources/library/dpdp-and-the-append-only-chain): How an append-only, hash-chained record of AI agent actions sits with the DPDP Act, 2023: erasure requests, retention, roles, and what the chain holds. - [AI agent readiness assessment: 12 questions](https://elan1.ai/resources/readiness-check): Are your AI agents ready to write to your records? Answer 12 questions about who may change what, who approves and what is recorded, and get a plain result. - [AI agent audit record examples: four proof records](https://elan1.ai/resources/specimens): What a proof record looks like: four illustrative AI agent writes, allowed, held for a named approver, refused at a pre-gate, and a small firm's journal. - [Example: an AI agent's month-end journal entry](https://elan1.ai/resources/specimens/allowed-write): An illustrative proof record for an allowed AI agent write, a month-end journal entry, with all 16 fields, the rules that ran, the approver and the chain. - [Example: an AI agent write held for human approval](https://elan1.ai/resources/specimens/held-for-approval): An illustrative proof record for an AI agent write held for a named approver: why it was held, who was asked, what they saw and what the record shows after. - [Example: an AI agent write refused at a pre-gate](https://elan1.ai/resources/specimens/refused-write): An illustrative proof record for a refused AI agent write: a purchase invoice stopped at rung 3, the typed refusal, the record it leaves and what it costs. - [Example: an AI journal entry, read by the firm's CA](https://elan1.ai/resources/specimens/small-firm-journal-entry): An illustrative proof record of a small firm's AI agent journal entry as its chartered accountant reads it in the CA console: what changed and who approved. - [AI agent governance glossary: 39 terms defined](https://elan1.ai/resources/glossary): The words elan1 uses, and exactly what they mean: 39 AI agent governance terms, from write intent and allow to proof record, assurance level and Mode A. ## Optional - [What is AI agent governance?](https://elan1.ai/resources/glossary/ai-agent-governance): The controls that decide what an AI agent may change, who must approve it and what evidence is kept. - [What is AI audit trail?](https://elan1.ai/resources/glossary/ai-audit-trail): A linked record of every action an AI system proposed, the rules checked, who approved it and the outcome. - [What is Allow?](https://elan1.ai/resources/glossary/allow): Govern's decision that a write may happen. Only elan1 Govern produces one; a model never does. - [What is Assurance level?](https://elan1.ai/resources/glossary/assurance-level): A level of claim about the evidence (L1, L2, L3), never a product tier. - [What is Autonomy level?](https://elan1.ai/resources/glossary/autonomy-level): How much an agent may do alone, A0 to A5; recorded on every proof record. - [What is Conformance?](https://elan1.ai/resources/glossary/conformance): Passing a published test suite before making a claim: K1–K7 for Run components, C1–C14 for third-party agents. - [What is Contract?](https://elan1.ai/resources/glossary/contract): One of ten versioned fusion.*/v1 capability contracts in elan1 Run, each with two licence-clean implementations. - [What is Declaration?](https://elan1.ai/resources/glossary/declaration): A process's rules in seven blocks: what may change, under which gates, who approves. Versioned. - [What is Design partner?](https://elan1.ai/resources/glossary/design-partner): An early-adopter organisation that puts one real process on the governed path with us and shapes what comes next. Ten places. - [What is Fail toward a human?](https://elan1.ai/resources/glossary/fail-toward-a-human): When anything is unclear or unavailable, elan1 stops and asks a person. - [What is Gate?](https://elan1.ai/resources/glossary/gate): A check a write must pass. Pre-gates G1–G9 run at rung 3; six can never be skipped. - [What is Governed action?](https://elan1.ai/resources/glossary/governed-action): One consequential write that passed the Right Path and was committed; Govern's meter unit. - [What is Governed write path?](https://elan1.ai/resources/glossary/write-path): The one route through which every AI agent change to a system of record must pass. The route is checked, approved and recorded. - [What is Guardian agent?](https://elan1.ai/resources/glossary/guardian-agent): Gartner's term for software that inspects agent actions and allows, blocks or holds them for a person. - [What is Hash chain?](https://elan1.ai/resources/glossary/hash-chain): Records where each one carries the digest of the one before, so altering one breaks every later link. - [What is Human-in-the-loop approval?](https://elan1.ai/resources/glossary/human-in-the-loop): A named person decides before a consequential change is made, with enough context to say no. - [What is Kernel?](https://elan1.ai/resources/glossary/kernel): elan1 Govern's core: one write function behind KernelPort. No other product builds gates, approvals, proof or a meter. - [What is KernelPort?](https://elan1.ai/resources/glossary/kernelport): The only door into the kernel: define, assert, seal, verify, scope, refuse. - [What is L1 Guarded?](https://elan1.ai/resources/glossary/l1-guarded): Records hash-chained so any change is evident to you. Available. - [What is L2 Attested?](https://elan1.ai/resources/glossary/l2-attested): Adds signatures, outside timestamps and a free offline verifier. Available. - [What is L3 Proven?](https://elan1.ai/resources/glossary/l3-proven): Evidence that survives the vendor. Starts when an outside auditor accepts an L2 bundle in writing; no date. - [What is Line?](https://elan1.ai/resources/glossary/line): A module of elan1 Work for one kind of work (ERP, Revenue, Voice, Commerce). Every line writes through elan1 Govern. - [What is Maker-checker?](https://elan1.ai/resources/glossary/maker-checker): One party prepares a change and a different, named party approves it. For AI, the model is the maker. - [What is MCA audit trail (edit log)?](https://elan1.ai/resources/glossary/mca-audit-trail): India's rule that a company's accounting software must keep an edit log of every change. The log cannot be disabled. - [What is Meter?](https://elan1.ai/resources/glossary/meter): The one unit each layer charges for: credit, decision, governed action, node-year. - [What is Mode A (Enforced)?](https://elan1.ai/resources/glossary/mode-a-enforced): elan1 in-process, holding the write credential. No write reaches the system of record without a gate decision and a proof record. - [What is Mode B (Attested advisory)?](https://elan1.ai/resources/glossary/mode-b-attested-advisory): elan1 over MCP or HTTP, without the credential. Every write intent is evaluated and recorded. - [What is Module?](https://elan1.ai/resources/glossary/module): A named part of one platform, always shown with its platform at first mention (elan1 Decide Router, then Router). Never a separate product or brand; each has a detail page under its platform. Work's modules are called lines; L1, L2 and L3 are levels of a claim, not modules. - [What is Pack?](https://elan1.ai/resources/glossary/pack): Configuration of Govern for a rule set — ledger1 (MCA), invoice1 (GST), collect1 (RBI). Never code, never a brand. - [What is Plane?](https://elan1.ai/resources/glossary/plane): One of nine architecture levels, P0 residency to P8 packs; the kernel is P3. - [What is Proof record?](https://elan1.ai/resources/glossary/proof-record): The 16-field record written for every action, allowed or refused; SHA-256, chained. "No seventeenth field, ever." - [What is Refusal?](https://elan1.ai/resources/glossary/refusal): A typed "no" from any rung. It still writes a proof record and costs 40% of one governed action. - [What is Residency domain?](https://elan1.ai/resources/glossary/residency-domain): A region with its own database and signing key. Today there is one: "in" (Mumbai). - [What is Right Path?](https://elan1.ai/resources/glossary/right-path): The fixed route every write takes, from rung 0b STOP to rung 9 METERED. - [What is Rung?](https://elan1.ai/resources/glossary/rung): One step on the Right Path: stop, identity, write door, pre-gates, evaluate, guardrail, autonomy, act, proof, metered. - [What is Seal?](https://elan1.ai/resources/glossary/seal): The method that turns a proof record into its digest: Seal v6, frozen. - [What is Single writer?](https://elan1.ai/resources/glossary/single-writer): Only one component writes to the system of record, with a 10-minute single-use credential. - [What is Tamper-evident?](https://elan1.ai/resources/glossary/tamper-evident): A record where any later change can be detected. It does not claim that a change is impossible. - [What is Write intent?](https://elan1.ai/resources/glossary/write-intent): A typed proposal to change a record. Agents and Decide may produce one; only Govern turns it into an allow. - [Fail toward a human](https://elan1.ai/blog/fail-toward-a-human): 2026-09-29 — Why elan1 fails toward a human, never toward an action: when a rule, approver or confident answer is missing, the agent's write stops and a person is asked. - [Designing the 16-field proof record](https://elan1.ai/blog/designing-the-16-field-proof-record): 2026-09-15 — How elan1 chose the 16 fields of its proof record for AI agent actions, why there will never be a seventeenth, and what each field lets an auditor check. - [What tamper-evident means at L1](https://elan1.ai/blog/what-tamper-evident-means-at-l1): 2026-09-01 — What tamper-evident means at L1, and why elan1 does not say tamper-proof or immutable: what a hash chain shows, what it cannot promise, and how to check it. - [Two crossings: why the layers meet in only two places](https://elan1.ai/blog/two-crossings): 2026-08-25 — Why elan1's four layers meet in only two places, KernelPort above and the fusion.*/v1 contracts below, and what that buys you in audit and substitution. - [A model may produce a write intent, never an allow](https://elan1.ai/blog/a-model-may-produce-a-write-intent-never-an-allow): 2026-08-11 — Why no AI model sits on elan1's allow path: a model may draft a write intent, but only elan1 Govern's checks and a named person can allow the change. - [Why a refusal costs 40% of a governed action](https://elan1.ai/blog/why-refusals-are-free): 2026-07-21 — Why elan1 charges a refused AI agent write 40% of a governed action: every check still runs and a proof record is written, but your books are untouched. - [elan1 Govern, Work, Decide and Run are available](https://elan1.ai/company/news/four-platforms-available): 2026-10-10 — elan1 Govern, Work, Decide and Run are now available: the governed write path for AI agents, with L1 Guarded and L2 Attested, launched from Chennai, India. - [elan1 opens its design partner programme](https://elan1.ai/company/news/design-partner-programme-opens): 2026-10-06 — elan1 opens its design partner programme: ten places to put one real process on the governed write path for AI agents and help shape what comes next. - [Brand architecture: one masterbrand, four layers](https://elan1.ai/company/news/one-masterbrand-four-layers): 2026-10-06 — Why elan1 uses one masterbrand and four layers, Govern, Work, Decide and Run, and how modules, lines and assurance levels are named under that brand. - [We publish our claims register and what comes next](https://elan1.ai/company/news/public-roadmap-and-claims-register): 2026-10-06 — elan1 publishes its claims register and roadmap: every claim with the assurance level at which it becomes true, and what improves next, in order. - [elan1 company: who builds the governed write path](https://elan1.ai/company): elan1 is built by ELAN1 AGENTIC TECHNOLOGIES PRIVATE LIMITED in Chennai, Tamil Nadu: one write path for AI agents, and a person answerable for every action. - [About elan1: AI agent governance from Chennai, India](https://elan1.ai/company/about): Why elan1 exists, what it will not claim, and who founded it: M. K. Elango, strategist, founder of StartNet Ventures and author of Milk Mountain Moonshot. - [AI governance design partner programme](https://elan1.ai/company/design-partners): Put one real process on the governed path and shape what comes next. Ten places, a 30-minute call every two weeks, and elan1 Work at ₹0 for 90 days. - [Careers at elan1: build the part that says no](https://elan1.ai/company/careers): Build the part that says no: careers at elan1, the governed write path for AI agents, in Chennai, Tamil Nadu. How we hire, what we value and how to apply. - [elan1 news: announcements, with their evidence](https://elan1.ai/company/news): Announcements from elan1, each with its evidence: all four platforms available, the design partner programme, the brand architecture and the claims register. - [AI agent governance blog: notes from the build](https://elan1.ai/blog): Short, dated notes from building elan1 by a named author: why a refusal costs less, why models never allow, tamper-evident records and failing toward a human. - [Contact elan1: talk to a person about AI agents](https://elan1.ai/contact): Talk to us; a person replies within two working days. Ask about elan1 Govern, Work, Decide or Run, a demo, pricing, partnerships, security or legal matters. - [Legal: privacy, terms, cookies and grievances](https://elan1.ai/legal): The rules for elan1.ai in plain words: privacy notice under the DPDP Act, website terms, cookie notice and grievance officer, effective 10 Oct 2026. - [Privacy notice under the DPDP Act, 2023](https://elan1.ai/legal/privacy): How elan1 collects and uses personal data under the DPDP Act, 2023: our role as Data Fiduciary or Processor, purposes, retention, your rights and grievances. - [Grievance officer for IT Act and DPDP Act matters](https://elan1.ai/legal/grievance-officer): elan1's grievance officer under the IT Act and DPDP Act, 2023 is Hariharan, who also handles legal notices and legal action. How to write, and the timeline. - [elan1 service status for Govern, Work, Decide and Run](https://elan1.ai/status): Current service status for elan1 Govern, Work, Decide and Run, with any incident shown in plain words and where to get help if something is not working.