How is a prompt written?

Three sample texts for the same fictional task were authored editorially; they are neither provider responses nor a comparative model experiment. The table compares only features present in these texts. Marks select review points without claiming to identify every error or omission.

• Error or invention
• To fill in or verify

Outputs are written as examples; they are not the actual response of an AI model.

Write me a statement of defence. Our client is the defendant, the claimant filed a debt claim, and we say we paid it.

You are a lawyer's assistant. A goods-price claim of TRY 250,000 was filed against our client (the defendant). The client says it paid TRY 150,000 on 12.03.2026 and has the receipt. Write a statement of defence in a formal register.

ROLE: You are a drafting assistant for Turkish law; you give no final conclusions and mark unknowns with [ ].FACTS: Claimant [CLAIMANT] sued our client [DEFENDANT] for a TRY 250,000 goods-price claim. The client wired TRY 150,000 on 12.03.2026 (receipt available). The client says it reported a delivery defect for the rest; we hold the notice. Date of service of the statement of claim: [SERVICE DATE].FRAMEWORK: HMK arts. 127, 128, 129. Cite no other provision or decision; leave [Article] if needed.FORMAT: court and file details, parties, answers to the facts (numbered), evidence, legal grounds, conclusion and prayer.TONE: Calm, formal, short sentences.CONSTRAINTS: Do not write dates, amounts, courts, file numbers or decisions absent from the input; mark gaps with [ ].

These examples establish no increase in model honesty, accuracy or safety. A detailed prompt may organise information to check; review actual output separately. Even with a deadline calculator, verify the start, procedure and exceptions for the matter.

AI can be considered a drafting aid. Generated text does not replace document-preparation authority, representation, confidentiality, strategy, signing or submission decisions. This guide derives no automatic legal outcome for every matter or person from a statutory provision.

A model may produce fluent but incorrect, incomplete or unsourced text. Compare summaries, outlines and language suggestions with file records and current rules separately. Case records and document versions are supporting resources; AI output does not automatically create a document version or legal verification.

These six headings are an illustrative prompt briefing, not mandatory product fields or a measured accuracy formula. Separate known facts, desired format and unknowns. Giving an instruction does not prove that the model follows it.

1. 01/06

   Role

   State the task and limits. A role description supplies neither knowledge, professional authority nor accuracy; the response still needs review.

   Example line

   ROLE: You are a drafting assistant for Turkish law; you give no final conclusions and mark unknowns with [ ].

   Common mistake: Treating an exaggerated role description as proof of accuracy.

2. 02/06

   Fact summary

   Give the facts without identities, in order and tied to documents: date, amount, document name. State what is unknown too, so the model does not fill the gap with its own invention.

   Example line

   FACTS: On 12.03.2026 the client wired TRY 150,000 (receipt available). The client reported a delivery defect for the rest.

   Common mistake: Pasting the whole file with identity details. It creates both a confidentiality risk and noise.

3. 03/06

   Legal framework

   Identify sources and scope you have reviewed as appropriate. Including source text does not prove that false citations or misapplication are prevented.

   Example line

   FRAMEWORK: HMK arts. 127, 128, 129. Cite no other provision or decision; leave [Article] if needed.

   Common mistake: Asking “add relevant case law too”. The model may satisfy that request by inventing decisions.

4. 04/06

   Format and structure

   Describe headings and structure, then verify the form required for the transaction separately. The sequence below is illustrative, not an approved complete procedural checklist.

   Example line

   FORMAT: court, parties, facts (numbered), evidence, legal grounds, conclusion and prayer.

   Common mistake: Treating fluent text as having passed form and procedural review.

5. 05/06

   Tone

   Name the reader and the register: calm and formal for the judge, firm but measured for the opposing party, clear and warm for the client. A length limit is part of tone as well.

   Example line

   TONE: Calm, formal, short sentences; no exaggeration or stacked adjectives.

   Common mistake: Not checking whether the actual output follows the requested tone.

6. 06/06

   Constraints

   Ask for no invented dates, amounts, courts, files or decisions and for unknowns to use placeholders. These requests do not guarantee compliance in actual output.

   Example line

   CONSTRAINTS: Do not write dates, amounts, courts, file numbers or decisions absent from the input; mark gaps with [ ].

   Common mistake: Assuming written constraints prevent every invention.

You do not rewrite the six parts every time. Build a prompt template for the firm and change only the fact summary and the framework per file.

Prompts and outputs for four tasks were authored without running a provider. Placeholders and review notes are illustrative; they do not establish removal of all personal information, detection of every error or suitability for dispatch.

• Error or invention
• To fill in or verify

ROLE: You are a drafting assistant for Turkish law.TASK: An outline for a statement of defence in a [CLAIM TYPE] case. Do not write the text; under each heading put a note on what belongs there.FACTS: Claimant [CLAIMANT] alleges [ALLEGATION SUMMARY]. Our client [DEFENDANT]: [DEFENCE SUMMARY].FRAMEWORK: HMK arts. 127, 128, 129. Add no other provision; [Article] if needed.FORMAT: Numbered headings.CONSTRAINTS: Do not invent dates, amounts, court names or decisions.

ROLE: You are a drafting assistant for Turkish law; you mark unknowns with [ ].TASK: A payment notice draft for a [RECEIVABLE TYPE] receivable.FACTS: Between client [CLIENT] and [ADDRESSEE] there is a [CONTRACT] dated [DATE]. The amount [AMOUNT] was not paid on [DUE DATE].FRAMEWORK: Cite no provision or decision; leave the legal basis as [Article].FORMAT: Sender, addressee, facts, demand, time limit, conclusion.TONE: Firm, measured; no threats or insults.CONSTRAINTS: Do not invent interest rate, time limit or IBAN; leave [ ].

ROLE: You are a communication assistant for a law firm.TASK: A client update message after [STAGE].FACTS: At the [STAGE] on [DATE]: [SUMMARY]. Next stage: [STAGE 2], date: [DATE 2]. Requested from the client: [DOCUMENT].FORMAT: At most 120 words, three short paragraphs; explain legal terms in one sentence.TONE: Calm, warm, clear.CONSTRAINTS: Promise no outcome (nothing like “we will win”); invent no date or document; leave [ ] where unknown.

ROLE: You are a file-summarising assistant.TASK: Build a chronology from the masked notes below.INPUT: [NOTES: Exhibit 1 contract, Exhibit 2 receipt, Exhibit 3 notice; identities masked].FRAMEWORK: Rely only on the notes given; make no comments or legal assessment.FORMAT: Date | Event | Source | Uncertainty.TONE: Neutral.CONSTRAINTS: Do not correct conflicting dates; show them in the Uncertainty column; point out missing periods.

Assess input text, inputs/results retained in history and provider-bound data separately. The table is an office preparation example, not legal transfer approval, a mandatory platform policy or proof that every personal detail has been removed.

First reduce unnecessary data. Automatic masking can replace certain identifier/contact patterns and labelled fields with markers; detection of every person or sensitive detail in free text is not guaranteed. Markers can be restored in the response and analysis inputs/results can remain in history. The privacy guide and document security guide provide separate review topics.

Illustrative office input-preparation checklist

Data minimisation in five steps

1. 01Define the purpose and choose necessary facts; this list is not automated data classification or legal approval.
2. 02Mask: replace identities and distinguishing details with bracketed placeholders and keep the mapping list in your own environment.
3. 03Summarise: write your own fact summary instead of pasting the document.
4. 04Fill back: replace the placeholders in the output with real data only in your own environment.
5. 05Record: note in the file which tool was used, for what purpose and on which file.

Person matching and erasure policy for historical analysis free text has not been determined. Case/document source references do not identify every person. This guide establishes no automatic historical person matching or new erasure/retention rule.

This is an illustrative error taxonomy, not a frequency measurement or exhaustive risk control. Review actual output against your own sources and records.

Example: verifying a deadline claim

Error or invention

Fictional sentence: “The period is X days from service.” The start, procedure and governing rule are not established.

Assess separately

Review step: determine applicable procedure, trigger, period type and exceptions against actual records and current sources. Do not carry an example’s article or period into every matter; check calculator output separately too.

Verification list

1. 01Check current source texts and their relevance to the matter separately.
2. 02Compare decision citations with sources; do not use unverified claims.
3. 03Compare dates with source records; separately verify trigger, procedure and exceptions.
4. 04Recalculate amounts and totals against actual records.
5. 05Match facts to inputs and records; separate unsupported sentences.
6. 06Assess placeholder scope and necessary identity/file information in your own environment.
7. 07Review requested relief against facts, strategy and applicable rules separately.
8. 08Check language, tone and length, then separately complete the authorised office reviewer’s final assessment.

These five topics illustrate an office’s human-review responsibilities. They are not automatically completed product gates, a list of assigned reviewers or acceptance of exhaustive checks.

1. Gate 01/05

   Input

   Responsible: Whoever prepares the prompt

   Check the masking table before sending. Give a summary instead of a document and remove identities and distinguishing detail.

2. Gate 02/05

   Citation

   Responsible: Whoever prepares the draft

   Read every provision and decision citation from the official source. A citation that cannot be verified is deleted and an “[Article]” placeholder is left.

3. Gate 03/05

   Fact

   Responsible: Whoever prepares the draft

   Match facts, dates and amounts to the file documents. Close the review marks one by one.

4. Gate 04/05

   Prayer

   Responsible: Responsible lawyer

   The lawyer writes or fully rereads the legal grounds, strategy and prayer for relief. These decisions are not delegated to the model.

5. Gate 05/05

   Signature

   Responsible: Responsible lawyer

   The office’s authorised person separately assesses final review, signing and dispatch requirements for the matter; this illustration executes none of them.

Determine office records for tools, purpose, sources and reviewers separately; this guide establishes neither automatic review logs nor legal evidentiary approval. Document versions are separate operations; AI generation creates neither an automatic version nor a signature.

Vekilaw AI draft generation and manual analysis creation are separate operations. Successful generation is stored in analysis history before returning the result; the illustration is neither an actual provider response nor an exact product screen.

AI · Pleading draft

File2026/118 E. · Client AExample inputs

Prompt

ROLE: You are a drafting assistant for Turkish law; you give no final conclusions and mark unknowns with [ ].FACTS: On 12.03.2026 the client wired TRY 150,000 (receipt available). The client reported a delivery defect for the rest.

This text is not a legal opinion; it needs lawyer review.

Fictional draft example

[COURT NAME]

FILE NO: [File No] DEFENDANT: [Defendant name], represented by Av. [Name] CLAIMANT: [Claimant name]

1. The claimant seeks TRY 250,000 as a goods price.

2. On 12.03.2026 the client wired TRY 150,000 (Exhibit 1: receipt).

3. For the remainder, a delivery defect was notified on [Date] (Exhibit 2: notice).

Deadline review: [Applicable period and rule require separate verification]; service date [SERVICE DATE].

Legal grounds: [Article].

CONCLUSION AND PRAYER: [Dismissal / acceptance only for the part left after setting off the TRY 150,000 paid]; costs and attorney fees to be borne by the claimant.

Illustrative marks for separate review00

1. 01/06
   Prepare inputsEnter document type, factual/context text and optional instructions. Linking a case is optional; a selected case requires current access and branch scope.
2. 02/06
   Assess prerequisitesGeneration permission, plan entitlement, a configured provider and current company AI approval are required. Missing approval or model configuration is not available generation.
3. 03/06
   Quota consumptionThe server consumes company quota for the UTC calendar month before calling the provider. Limits are managed in the platform panel; failure or cancellation promises no automatic refund.
4. 04/06
   Generation and historySuccessful content is stored as an analysis after fresh reference/branch checks, then returned. Inputs and results may remain in history; do not assume device-only storage.
5. 05/06
   Review the resultThe result surface displays text; opening history additionally requires analysis-history read permission. The illustrated warning and marks are editorial examples, not automatic legal verification by the product.
6. 06/06
   Separate edits and decisionsEditing a stored analysis requires separate analysis-edit authority and record scope. Creating a manual analysis makes no model call. Review, document versions, signing and court submission are not completed here.

‹›

01/06

Prepare inputs

Fictional flow and authored sample text; not proof of actual model output, quota, history or completed review. Marks are not closed automatically.

Available plan/AI entitlement, price and quota values come from the live platform catalog; this guide sets no fixed package, price or quota number. Review current pricing scope. Cancelling a request does not prove generation/history creation never occurred; check the outcome before resubmitting.

AI service and model setup must be completed separately; a product setting alone proves neither actual hosting country, absence of transfers nor training/retention terms. Verify those through provider contracts and operational evidence. Prediction output is neither a guaranteed success probability nor legal advice. Review security scope separately.

These headings are examples for office review, not an implemented Vekilaw policy or a decision made on your behalf. Platform AI approval and office data/transaction policy are different. Historical analysis person matching/erasure decisions remain open.

Draft topics for office review

1. 01/10

   Purpose and scope

   States which staff, which tools and which tasks (drafts, summaries, translation) the policy covers.

2. 02/10

   Approved tools

   Only tools the firm has reviewed, with provider terms assessed, may be used.

3. 03/10

   Prohibited data

   Determine rules to reduce unnecessary identity, contact and sensitive details through qualified review; this example implements no new platform prohibited-data policy.

4. 04/10

   Masking

   Distinguish input preparation from server pattern masking; assume neither full anonymisation nor person matching of historical records.

5. 05/10

   Verification

   No text is used until citations, dates, amounts and deadlines are verified against the source.

6. 06/10

   Responsibility and signature

   The responsible lawyer reviews every draft; the document is filed under the lawyer's responsibility.

7. 07/10

   Record

   Use is recorded in the file note with the date, tool, purpose and reviewer.

8. 08/10

   Client information

   Tool use and data transfers are stated in the privacy notice and, where appropriate, in the engagement agreement.

9. 09/10

   Incidents and breaches

   Data sent by mistake or a security incident is reported immediately to the responsible person; notification duties are assessed.

10. 10/10

    Review

    The policy is reviewed whenever tools and legislation change and at least once a year.

Roles and permissions enforce actual operation and record scope; they do not automatically execute every clause in this sample policy.