Taliara

Mark the contract finalised — agreed and ready to send for signature. Comes AFTER the customer has accepted your changes (blocked while their acceptance is pending). Signing itself is initiated from the Taliara dashboard.

finalise

Complete a direct upload after the curl PUT from request_file_upload succeeds: verifies the staged bytes, then files the file onto the matter — into the Documents register by default, or (when the slot was created with a folder_path) versioned and audited into the data room. Requires the slot_id returned by request_file_upload.

finalise_file_upload

Produce the marked-up Word document (track changes) from the redlines you've recorded as accepted/edited on this contract. This is the version the customer reviews. Run it after record_redlines. DOCX contracts only — PDF contracts are signed from the original PDF directly.

generate_output_document

Read the solicitor's bookable diary: the working windows behind it, and the free slots a client (or propose_booking) could actually take over the next two weeks. Slot starts are ISO 8601 UTC and are what propose_booking expects verbatim.

get_availability

Get the cross-type boilerplate keep/cut reference: for each common boilerplate clause, whether it earns its place, what the default law gives if it's absent, and where Scots law diverges. Use it when judging whether a MISSING clause is a real gap (a weak default that costs our client a right) or a clause can be trimmed. Heavy — fetch only when you need that depth; the per-type playbook from get_contract governs the substantive view.

get_boilerplate_reference

Pull the business’s house standards and preferences — how THIS business likes things done (payment terms, contract standards, pricing, tone, process). Call this BEFORE producing invoices, contracts, client emails or any output, and apply it so everything is consistent and on-brand. Returns entries grouped by category.

get_business_memory

Pull EVERYTHING Taliara knows about a client in one call: their standing commercial posture (profile), their confirmed negotiation-position playbook (per clause category), their freeform background notes (the knowledge file — relationship context, quirks, strategy), and anything the client has stated directly through their own AI (client_stated — delivery preferences and unratified assertions). Use it before redlining so your suggestions match how THIS client does business, not just the house view. Identify the client by customer_id, or by any one of their contract_review_ids. (get_contract already embeds this as client_context.)

get_client_context

Pull everything needed to redline a contract: its metadata, the FULL TEXT of the latest version, the house playbook for its type (review checklist + standard positions), THE CLIENT'S OWN CONTEXT (their profile, confirmed position playbook and freeform background notes — apply these on top of the house view), and — for amendments — the parent agreement's text + type. Use this, draft redlines with the user, then call record_redlines to write them back.

get_contract

Read the current fee estimate for a client request — the range, how confident the model is, and the factor-by-factor breakdown behind it. Use this before proposing, so a correction is an informed one.

get_fee_estimate

Get one invoice in full — header, client and line items. Amounts are in minor units (pence).

get_invoice

Get the house playbook (review checklist + standard positions) for a contract type. get_contract already bundles this, but you can fetch it standalone (e.g. to study the BAA house view before reviewing).

get_knowledge

Get the house reference for the small-claims / debt-recovery track (England & Wales): the reserved-act invariant and when to escalate, CPR 27 procedure (allocation, N180, automatic mediation, directions, the hearing, costs, appeals), and County Court mechanics (where to issue, MCOL/OCMC, service, default judgment, transfer to the defendant's home court). Read this BEFORE advising on or progressing any small-claims matter. Omit `topic` to load everything.

get_litigation_knowledge

Pull a matter's full picture: metadata, the documents on file (the register), the ratified timeline, and any pending candidates awaiting ratification. Use this to orient before drafting or proposing. Returns what EXISTS, not document bytes — read the underlying files yourself, then propose_matter_event / save_matter_document. Candidates and timeline entries are the matter's RECORD: a ratified entry is not a decision and authorises no action (see pending_candidates_scope).

get_matter

Pull a support ticket in full: the request, the whole message thread (including any proposed agent drafts not yet sent), and any linked product-fix items. Use this before drafting a reply.

get_support_request

Read one client question in full — what they asked, the context they gave, the jurisdiction, and any answer already drafted for it. Use before proposing so the draft is an informed one.

get_validation_request

Bring an EXISTING / in-flight small-claims or low-value litigation matter into Taliara and reconstruct its history — for picking up a case mid-stream (you were served a claim; you're at the defence/counterclaim stage; or you're taking over an existing matter). Opens the matter on the right side (claimant or defendant), records the posture (court, claim number, parties), computes the key dates (deemed service -> the 14/28-day response/defence clock, limitation, hearing), marks the phases already completed, backfills a dated timeline, and flags whether a solicitor must take over (missed deadline, limitation, or a defence/counterclaim needed). CONTENTIOUS WORK ONLY — it requires a side (claimant/defendant) and computes court clocks, so do NOT use it for advisory, licensing, contract or company work: open those with open_matter, which takes any matter type and assumes no posture. The client (customer) must already exist — pass its customer_id (list_clients / create_client). Performs NO regulated act: the user still files, serves and signs every step.

intake_matter

List all invoices for one client (any status). Returns id, number, status, total, issued date.

list_client_invoices

List the firm's clients so you can find one and its customer_id — the id every client-scoped tool needs (open_matter, get_client_context, record_client_profile, draft_invoice). Optionally filter by name. Check here BEFORE create_client so you don't open a duplicate record for a client the firm already has.

list_clients

List the matter types this firm can open, with the key open_matter expects. Call it when you're unsure which type fits the work (advisory, licensing, a contract, company management, property, litigation…) rather than guessing a key. Types marked has_seed_template come with a step template; the rest open with an empty workflow.

list_matter_types

List the firm's matters so you can find the one to work on (by client name or reference). Returns id, title, reference, client, type and status. NOTE: this is separate from list_review_queue, which is for CONTRACTS — litigation and other matters live here. Then call get_matter for full detail, or propose_matter_event / save_matter_document to act.

list_matters

List product-fix items distilled from support (open by default — excludes shipped/wont_fix). Returns id, title, status, priority and origin ticket. Pass status to filter.

list_product_fix_queue

List consultations staged by propose_booking and still waiting on a human to confirm or decline. A booking that has dropped off this list has been decided one way or the other; a confirmed one then shows up as busy time in get_availability.

list_proposed_bookings

List client emails you have drafted that are awaiting a human to approve and send. Each one reports the address it would ACTUALLY send to (resolved_to) and where that came from (recipient_source): "explicit" is the address you gave, "client-contact"/"client-login" mean you gave none and it fell back to the client — which is wrong if you meant the email for a third party. Also returns recently_declined: drafts a human turned down WITH THEIR REASON. Read those before re-proposing; they are the correction, not a rejection.

list_proposed_emails

List fee estimates awaiting a human to ratify or decline.

list_proposed_estimates

List the org’s recurring-invoice schedules (retainers) — who is billed, how much, how often, the next run date, and whether it auto-sends. Amounts are in minor units (pence). Read-only.

list_recurring_invoices

List the contracts currently awaiting your legal review — in scope and not held behind a customer's internal approval gate. Returns each contract's id, title, type, customer, counterparty, position, status and when it was submitted. Pick one and call get_contract to pull its full context for redlining.

list_review_queue

List open support tickets awaiting triage (urgent first, oldest first). Returns each ticket id, subject, status, priority and when it came in. Pick one and call get_support_request for the full thread, then propose_support_reply to draft an answer for a human to approve. Pass status to filter (open|new|triaging|awaiting_customer|resolved|closed).

list_support_queue

List the support tickets linked to a product-fix item — the people to follow up when the fix ships. Use after set_product_fix_status(shipped) to close the loop: call get_support_request on each, then propose_support_reply to tell them, then a human approves.

list_tickets_for_fix

List the org’s issued (unpaid) invoices, oldest first — who owes you. Returns each invoice id, number, client, total and when it was issued. Amounts are in minor units (pence). Use mark_invoice_paid when one is settled.

list_unpaid_invoices

List the client questions waiting for a legal answer — the answer-validation queue behind /solicitor/validations. These are questions a client has submitted that nobody at the firm has answered yet. Use this to see what is outstanding before drafting. Distinct from list_review_queue (contracts awaiting review) and list_review_requests (pre-action approvals).

list_validation_queue

SIGN-OFF ACT. Record an invoice as paid — stamps the payment time and stops the chase engine. Only a sign-off connection can call this.

mark_invoice_paid

Open a NEW matter of any type for an existing client — advisory, licensing, a contract, company management, property, a consulting project, a retainer. Takes the matter type from the catalogue (list_matter_types) and instantiates its step template; it asserts NOTHING about litigation posture, so use this for all non-contentious work. For an in-flight court claim use intake_matter instead — that one opens on a side (claimant/defendant) and computes the service/defence/limitation clocks. The client must already exist: find it with list_clients or open one with create_client. Then attach work with assign_request_to_matter, file letters with save_matter_document and record history with upsert_timeline_entry.

open_matter

Stage a consultation with a client for the solicitor to confirm. The time must be one of the free slots from get_availability — a proposal for an unbookable time is rejected. Saved as PROPOSED: no calendar event is created, no invitation or confirmation is sent, and the slot is NOT held, until a human confirms it at /solicitor/consultations. Use get_availability first.

propose_booking

Draft an email to a client (project update, follow-up, reminder, proposal note, etc.). Saved as PROPOSED — NOT sent. A human releases it with send_client_email, and it goes from the org’s own mailbox. Give the full subject + body you would send. Provide client_id (preferred) or to_email.

propose_client_email

Propose the fee estimate for a client request. Saved as PROPOSED — the client does NOT see it and it is not the firm’s quote until a human ratifies it at /solicitor/estimates/:id. Amounts are in PENCE (e.g. 240000 = £2,400). Omit the amounts to put forward the system’s own indicative range unchanged; give low_pence and high_pence to correct it, with a note saying why — that correction is recorded and is how the estimator improves.

propose_fee_estimate

Record a TIMELINE FACT against a matter from your own agent — e.g. after reading and classifying a document: 'Defence & Counterclaim received', a deadline that arises, the recommended next step. It lands as an INFERRED candidate the solicitor ratifies onto the matter's record (never auto-applied). Put the human-readable detail (including any deadline and next action) in `summary`. SCOPE — ratifying a candidate confirms ONLY that the entry belongs on the matter's timeline. It is never approval to send, file, sign, pay, publish or otherwise act, and must never be treated as authority for anything outside Taliara. If you need a DECISION from the solicitor, use request_legal_review: it is the only lane that carries one, and it returns an explicit verdict with the approved text verbatim.

propose_matter_event

Propose a dated obligation on a contract (a renewal, notice-to-terminate cut-off, term expiry, price-review, DPA-review date…) as a CANDIDATE the solicitor confirms before any reminder is armed. Use it when you've read a date in the contract but want it ratified. (To record one directly as the accountable solicitor, use record_obligation.) Identify the contract by its contract_review_id.

propose_obligation

Propose a negotiation position for a client as an INFERRED candidate the solicitor confirms with one tap (never auto-applied to the playbook). Use it when you've inferred a stance from the work but want it ratified before it counts. For a settled stance you're sure of, use record_position.

propose_position

Distil a support ticket into a product-fix item on the fix queue (status proposed). Link it to the originating ticket so the loop can close when the fix ships. Use this when a ticket reveals a bug or a product gap rather than a one-off answer.

propose_product_fix

Propose property details extracted from a document (e.g. the HMLR title register PDF read via read_document, a mortgage statement, an insurance schedule). Recorded as an INFERRED candidate — matter_data is NOT touched until the solicitor applies + confirms it with one tap on the property panel. Include source_document_id in the relevant section so the fact traces to its evidence, and say what you read in `basis`.

propose_property_details