Feanor LAW is designed not as a noisy “AI chat”, but as a structured legal command center: with guided scenarios, explainable outputs, careful routing, saved context, and a clear transition from result to next action.
The value of the service does not rest on the mere promise of “AI”. It rests on a coherent scenario: entry, issue description, calculation, explanation, document, action route, and return to the saved case.
This page explains how Feanor LAW works at the trust layer: what the service boundaries are, how outputs should be interpreted, where human review is important, and why the product should not be seen as an opaque black box.
Feanor LAW is a unified ecosystem that includes:
— the public website;
— the Telegram bot as a fast entry point;
— the Telegram Mini App as the action-oriented interface;
— calculators and legal navigation scenarios;
— document and calculation flows;
— trust layer, explainability, and preserved user context.
A result inside the service should be understood as a structured working output: it helps a user understand the scenario, the calculation, the possible document, the next steps, and the key points that require attention.
A user should not receive “just a number” or “just advice without context”. A strong result is one that can be explained, checked, and turned into action.
Feanor LAW may significantly speed up first-stage analysis, navigation, calculations, material preparation, and scenario structuring.
But in complex, disputed, urgent, or high-risk situations, the user should additionally review the output, compare it with documents and facts, and, where needed, escalate to a human specialist.
The service should include a visible transition from self-service mode to additional review, specialist handoff, escalation, or supported follow-up.
This is not a marketing statement but a real product principle: the user should understand when they are still in self-service mode and when a higher level of precision and responsibility is needed.
Output quality depends on completeness of source data, correctness of inputs, quality of attached documents, proper scenario qualification, and the relevance of the legal basis used.
If the input is incomplete, the wrong scenario is selected, or the legal situation requires separate qualification, the result may require further checking and refinement.
Trust is impossible without disciplined handling of data, documents, and communication channels. A user should provide only the information that is genuinely needed for the specific scenario.
The basic rules for data processing and protection are described separately on /en/privacy.
The website, bot, and Mini App should not duplicate one another. Trust is reinforced by predictable architecture:
— the site explains the product and creates trust;
— the bot removes entry friction and helps start quickly;
— the Mini App leads to action, calculation, document, and next step.
As the product grows, this page may be refined: for example, when new scenarios, document flows, human-review mechanics, premium functions, or archived workflows are introduced.
The current version is available at the permanent address: /en/trust.
The trust page exists to keep the public product layer transparent, not to carry pre-launch noise. It establishes that the site, bot, and Mini App are parts of one system rather than separate promises.
Exact operator details, formal notice channels, paid-mode disclosures, and human-review mechanics are published only where a confirmed legal and product contract exists. The site does not imitate those details with invented legal depth.
The trust layer already works as the public anchor of the product: it explains service boundaries, surface roles, and the honest transition into the working legal environment.