01
The version travels with the agreement
v3 is published. v1 and v2 are superseded — but the agreements built on them stay where they are.
avtal/uppdrag · slug + version
Product
Six parts. The same data throughout.
An agreement in Legarch is not a document with text in it. It is a template with a version number, clauses with pre-approved variants, and variables with a type. That is why you can ask the system what the agreement says without anyone opening it.
01
Versioned templates
A template's identity is its slug plus its version number. Publishing a new version never alters the previous one.
- Agreements already sent keep pointing at the exact text they were built from. No retroactive edit is possible, not even by accident.
- A version has three states: draft, published and superseded. Only one version is published at a time.
02
Clause variants
A template is an ordered list of clauses. Each clause owns one or more pre-approved variants.
- Negotiation means choosing a variant, not rewriting text. No new wording appears at the table.
- Who may choose is set per clause: system default, operator, case owner or counterparty.
02
A choice, not a rewrite
Per clause: which variants exist, and who may choose between them.
mall/uppdrag@v3 · klausuler3 clauses
ClauseMay choose
§4 Ersättningcase owner
A · Fixed monthly feeB · Variable per assignmentC · Share of revenue
§7 Exklusivitetoperator
§9 Uppsägningcounterparty
03
Typed variables
Every variable in a template is registered with a type, a source and a validation.
- Types: text, integer, numeric, sek, percent, list and date. An amount is never a text string.
- Sources: intake, case config, set by the operator at send time, or generated by the system.
- This is why agreements can be queried without being read.
03
The register behind the text
Key, type and source for every variable. The query below runs against the register, not a PDF.
variabelregister6
beloppsekoperator
andelpercentintake
startdateintake
uppsagningstidintegercase config
leveranssattlistvariant
referenstextsystem
agreements where uppsagningstid > 3 and andel >= 10
Norden Studio ABNORDEN-0142 · 6 · 12 %
Almtra Bygg ABALMTRA-0007 · 4 · 10 %
04
Intake
The counterparty gets a single-use link to a form — not a file.
- Every field has a destination: a variable, a party detail, a protected personal detail, or a variant choice. Nothing lands in free text.
- Some fields appear only when an earlier choice puts them in scope.
04
Fields with a destination
The form on the left, the destination on the right. The greyed field appears only in one case.
form → destination
05
Signing and authority
Anyone with access can initiate an agreement. Only a registered signatory can conclude one.
- Authority rests either on statutory signing rights or on a power of attorney. That power of attorney is itself an agreement in the system, so the register points at its own evidence.
- Required signers are named roles, not a count: counterparty, statutory signatory, attorney, board member, chair, minute-taker, adjuster.
05
The chain points at its evidence
Signatory → power of attorney → the agreement that granted it.
SignatoryElvira Sandström
evidence_instance_id
Power of attorneyVESTRA-0031
evidence_instance_id
Granting agreementALMTRA-0104
counterparty · signedsignatory · signedattorney · pendingadjuster · pending
06
Obligations
What each side undertook is registered separately from the agreement text and carries its own state.
- States: waiting, pending, fulfilled, waived, breached.
- Fulfilment is always asserted by a person. The system never infers it. Every assertion lands in an append-only log.
06
Five states, one log
The system never moves an obligation to fulfilled on its own.
Asserted by
actor=oskar.lindqvist · origin=app · 2026-04-18 09:12