> For the complete documentation index, see [llms.txt](https://docs.solcis.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.solcis.ai/design-principles/accountable-by-design.md). # Accountable by design Every action your AI systems take traces to the human authority that permitted it, and every decision is evidence someone independent can check. When an AI system acts, a human still answers for it. An executive before a board, a director before a regulator, an engineer before their own team. Solcis is built so that person can answer with evidence rather than assertion. Every action your AI systems take through Solcis traces back to the authority that permitted it. Every decision is written to a record someone independent can check. ## Authority versus authorisation Authorisation answers a narrow question: was this agent permitted to call this tool? Most access systems stop there. Authority answers the question a board actually asks: who decided this agent may do this, under which control, and who signed off on that control?
Compliance Studio records authority, not just permission. When an action is allowed, the compliance receipt names the policy that allowed it and the version of that policy. It names the control the policy implements and the framework requirement behind the control. The policy lifecycle in Compliance Studio records who approved that version and who promoted it to enforced. Read together, they answer "who says this agent may do this?" with names, dates and identifiers. An agent acting on someone's behalf inherits the limits of that person's authority, and can't exceed them. ## The precedent is audit Audit is what made the financial system trustworthy at scale. It's an independent layer of verification that lets everyone rely on numbers they didn't produce. Independence is what gives it force: the auditor didn't prepare the accounts and doesn't run the business.
Solcis builds for the same independence. Every decision produces a compliance receipt: what was checked, what was found, what was done. Receipts are held in the evidence ledger, and the ledger is tamper-evident. A verifier can detect that a receipt was altered or removed after it was written. That's what lets people who didn't build the system and don't run it verify your AI governance. Internal audit, external assurance, a regulator. What audit is to financial reporting, the evidence ledger is meant to be for AI systems. ## Tamper-evident, said precisely We say tamper-evident, not tamper-proof or immutable. A receipt could in principle be altered by someone with enough access. What Solcis provides is detection. A verifier who holds the export and the integrity data can find the alteration without access to the running system. *How it works › Evidence and verification* names the mechanism and states exactly what a verifier can and can't conclude. Precision here is the point. A product that claimed its records couldn't be changed would be making a claim no auditor should accept. A product that shows how changes are detected is making one they can test. ## Demonstrated, not asserted Most governance is asserted. A policy document says what your AI systems may do. A vendor's attestation says the vendor's estate is secure. A report says the controls were operating at a point in time. None of it is checkable by the person relying on it. Solcis makes governance demonstrable. The controls are inspectable. The decisions are recorded. The record can be verified by a third party. A compliance manager can hand an auditor an export of the evidence ledger from Compliance Studio and the record format. The auditor can do the rest without asking anyone for help. ## The receipts are yours Compliance receipts produced in your environment belong to you. They never leave your deployment, and nothing in either licence or either product changes that. The Software Licence and the Decision Engine and AI Terms in the Legal Centre say so in the words that bind us. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.solcis.ai/design-principles/accountable-by-design.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.