We are the evidence layer, not the gateway

We classify, cite, and store compliance evidence: risk posture, Article 50 transparency artefacts, and records you can show a customer, auditor, or counsel. Outputs link to the primary text — including Article 50 transparency duties that apply from the date stamped above.

That evidence layer is the product. The CLI, MCP, API, and WordPress disclosure helpers all feed the same idea: a record you can defend, not a choke point on production traffic.

• No request-path enforcement. We do not sit in front of your LLM calls to allow or deny them.
• No runtime blocking. A missing disclosure string or a stale record does not become a 403 from Legalithm in production.
• No traffic interception. We do not terminate TLS, mirror prompts, or proxy model providers.

That is a product refusal with a rationale, not an apology. Gateways optimise for in-line control. Evidence layers optimise for after-the-fact and before-the-deal proof. Mixing them muddies both jobs.

If you already run a guardrail gateway, keep it. Legalithm’s stance is that guardrail verdicts from gateways will be consumable as evidence in the Legalithm record — inputs to the evidence layer, not a replacement for the gateway’s job.

We refuse to become your runtime gate. We accept the obligation to make gateway outcomes auditable next to Article-cited classifications when you choose to attach them.

• We do not stop a non-compliant release from reaching users. Build-time gates (see guard) and your own CI do that.
• A Legalithm record is evidence and guidance, not a certificate from a notified body and not legal advice.
• Article citations (including Article 50) track the AI Act as amended by the Omnibus instrument stamped above; always verify against EUR-Lex for your facts.