The LEXSAS operating standard

1Purpose and scope

1. 1.1This standard applies to every workflow LEXSAS designs, builds or pilots with a client.
2. 1.2It covers what software agents do inside a legal workflow, and the human steps around them.
3. 1.3It does not replace your own policies. Where your policy is stricter, your policy applies.
4. 1.4LEXSAS is not a law firm. It gives no legal advice and provides no legal representation. Your lawyers decide and sign.
5. 1.5Anyone may quote this document with the section number and the version.

2The named file

1. 2.1Work enters a workflow only as a named file: a matter with a type, an owner, a clock and a place in a queue.
2. 2.2Loose material, meaning mail, attachments, chat messages and notes, is bound to a file before an agent reads any of it.
3. 2.3A request that cannot be typed and owned is not started. It goes back to a person.
4. 2.4Every later entry in the record refers to the file identifier.
5. 2.5One file, one clock. A matter with two clocks is two files.

3The mandate

1. 3.1Before a run, the agent’s mandate is written down and agreed with the client. It has three parts: what the agent may read, what it may keep, what it may do.
2. 3.2May read. Sources are listed by name: systems, folders, databases, sites. Anything not on the list is out of scope, and the list is enforced in configuration rather than in an instruction.
3. 3.3May keep. What memory survives a run, for how long, and where it lives.
4. 3.4May do. The tools the agent holds, the actions it may take, and the actions reserved for a person.
5. 3.5A mandate is never wider than the matter needs, and it does not change during a run.
6. 3.6Capability sets are versioned. Every change carries a date, an author and a reason.
7. 3.7The three-capability limit. Within one run, an agent should hold at most two of these three: access to private client data, exposure to content nobody in your organisation wrote, and the ability to act or send something outside the workflow. Where a workflow appears to need all three, it is split into stages, or a person stands between them.
8. 3.8Filtering the input is a mitigation, not a control. The control is the capability set.
9. 3.9The mandate is written in language a lawyer can read without help. If it needs a diagram to be understood, it is too wide.

Mandate

MANDATEMATTER 2026-117v3

May read

The request and its attachments

granted

The matter-type list and the routing rules

granted

Any source not named in this list

not granted

May keep

The proposal and the rule behind it

granted

The reviewer’s correction, for the agreed period

granted

A copy of an attachment outside the file

not granted

May do

Propose a type, an urgency and an owner

granted

Draft the acknowledgement

granted

Send mail outside the company

not granted

Close a file

not granted

These are the fields of a mandate, not a real matter. No client work appears on this site.

4The reviewer

1. 4.1Every workflow names the person who signs, by role and by name, before the pilot starts.
2. 4.2Nothing leaves a workflow unsigned.
3. 4.3Review depth follows the impact of the output and how hard it is to reverse, not whether it happens to leave the team.
4. 4.4The reviewer can reject. A rejection is recorded as an outcome of the run, not as an error to be tidied away.
5. 4.5Where a compliance, privacy or conflicts gate applies, it sits on the same line as the reviewer, before anything is sent.
6. 4.6A reviewer who cannot see what the agent read cannot review it. Section 5 exists for that reason.

5The record

1. 5.1Each run writes one record. Its fields are: the file identifier and type; the owner; the mandate version in force; the sources actually read; the tools used; the outputs produced; each check run and its result; the reviewer’s name and decision; a timestamp for each of those; and any exception raised.
2. 5.2Entries are written when the step happens, by the workflow, not reconstructed afterwards by a person.
3. 5.3The record is append-only. A correction is a new entry that names the entry it corrects. Nothing is silently rewritten.
4. 5.4The record lives in the client’s own systems and belongs to the client.
5. 5.5Retention, access and deletion are set with the client under section 9.
6. 5.6The record exists to answer one question: what ran, on which sources, under which mandate, who signed, and when.

6The evaluation gate

1. 6.1The evaluation set, the golden set, is built from the client’s own matters. The right answer for each example is recorded by the lawyer who would otherwise be doing that work.
2. 6.2It starts small. Five to ten examples that exist beat a complete set that never ships. It grows with the failures that sampling finds.
3. 6.3Error classes are named before the pilot: critical, meaning it changes a legal outcome; material, meaning it needs real rework; formal, meaning it is cosmetic. The tolerance for critical errors is zero.
4. 6.4What is measured: the one measure the client set for the workflow, reviewer time per item, and the three error classes.
5. 6.5Pass or fail is decided against thresholds written before the run. A threshold set after the results are in is a description of the results.
6. 6.6Release gate. The set is re-run and must pass before any change to the model, the prompt, the retrieval sources or a connector reaches live use. A failing gate stops the change.
7. 6.7A named person approves each release. The evaluation set carries a version number.
8. 6.8A set that passes at 100 percent for three months running is treated as stale until the failures found by sampling have been added to it.
9. 6.9Sampling continues after go-live: a fixed number of live outputs, one named reviewer, every week.

7The supervised pilot

1. 7.1The scope call covers one workflow: the matter type, the volume, the systems it touches, the reviewer who will sign, and the timing.
2. 7.2The written scope comes before any build: stages, mandate, reviewer, record format, the one measure, the dates and the price.
3. 7.3One measure, agreed in advance, with a baseline taken from your own work before the workflow runs.
4. 7.4Nothing runs unattended during a pilot.
5. 7.5The pilot ends on a date that was fixed at the start, with a pass or a fail against 7.3 and section 6. The decision is written into a pilot decision record carrying the owner’s name and the evidence behind the call.
6. 7.6Exit terms are written into the pilot, not negotiated at the end.
7. 7.7What the client keeps, whatever the outcome: the workflow definition, the playbooks, the mandate register, the evaluation set, every run record, and the design brief. In an exportable format, from the first day.
8. 7.8A failed pilot ends. It does not quietly become a longer pilot.

8The register

1. 8.1Every live workflow has one entry: its purpose, its owner, its mandate version, its sources, its reviewer, its last evaluation, its last change and its incident history.
2. 8.2The register belongs to the client and is kept in the client’s systems.
3. 8.3It is the artefact an auditor, a board, a bar or a regulator asks for, and it is easier to keep than to reconstruct.

9Data handling

1. 9.1Workflows are designed to run inside the client’s own environment, or in a region the client chooses.
2. 9.2The client is the data controller and makes the compliance call. LEXSAS designs to that decision and records it.
3. 9.3Lawful basis, minimisation, retention and logging are settled in the design brief, with the workflow, not in a review afterwards.
4. 9.4The sources an agent may read are fixed in advance and logged on every run.
5. 9.5Model training. The design brief names the provider terms and the account settings that keep client content out of training, and the pilot does not start until they are in place.
6. 9.6Cross-border transfer, where it arises, is answered in writing before the pilot starts. The mechanism is named, the responsibility for any notification is allocated, and the period for making it is recorded.
7. 9.7Logs. What is logged, who may read it, how long it is kept and how it is deleted, all written down before the first run.
8. 9.8Subprocessors are named per engagement, in writing, before any data moves. There is no global list, because the stack differs by client.
9. 9.9Material that does not go into a system whose terms have not been read for that purpose: special-category personal data, evidence, enforcement file content, negotiation strategy and anything covered by professional secrecy.
10. 9.10“Every record kept” means kept for the period agreed with you, in your systems. It is not a promise to keep anything for ever. The full statement is on the security and data page.

10Incidents

1. 10.1Preserve first. The prompt, the output, the model version and the logs are captured before any rollback, session clearing or key rotation, because those three moves destroy the evidence.
2. 10.2Contain second.
3. 10.3The plan names who may switch a workflow off and who tells the business. Both names exist before the incident.
4. 10.4Notification duties sit with the client as controller. The record is what makes a notification possible within the period the law allows.
5. 10.5Every incident closes with an entry in the register and, where the failure can be tested, a new example in the evaluation set.

11What this standard does not claim

1. 11.1LEXSAS is a venture founded in Istanbul, Türkiye, in 2026, led by one founder. It holds no security certification and does not imply one.
2. 11.2LEXSAS resells no product and claims no certified connector to any system.
3. 11.3LEXSAS publishes no client names, no results and no testimonials. Turkish bar advertising rules restrict what lawyers may publish about clients and outcomes. A published method is the honest substitute for a logo wall.
4. 11.4No accuracy guarantee is given for any model output. The gate and the signature are the controls. A model that is right most of the time is still a model.
5. 11.5Availability is finite and is agreed for each engagement before it starts.

12Version

1. 12.1Version 1.0, published 5 September 2026. This is the first published version.
2. 12.2Later versions will list what changed, on what date, and why, in this section.