Context Engineering: The Missing Layer That Makes Legal AI Useful

In law, context is not decoration. Context is the case.

A prompt is only as good as the legal context it can safely access. Two lawyers can ask the same question, in the same words, on the same day, and reasonably expect different answers, because their files, their clients, their jurisdictions, and their prior work are different. The legal answer depends on the legal context. Always.

For most of the last two years, the public conversation about legal AI has been about prompts. Better prompts. Prompt libraries. Prompt engineering. That conversation is not wrong, but it is incomplete. The harder problem is not the prompt. It is what the model can see when it reads the prompt.

That problem has a name. Context engineering. It is the discipline of choosing, structuring, retrieving, and governing the information a legal AI needs in order to answer a specific question well. It is, increasingly, what separates serious legal AI deployments from impressive demos.

This article explains what context engineering is, why legal work is unusually demanding for it, and what a Moroccan legal team should look for.

Prompt engineering versus context engineering

Prompt engineering is about how you ask. Context engineering is about what the model has access to when it answers.

The two are related but not the same. A perfectly phrased prompt sent to a model with no relevant context produces fluent generic legal text. A modest prompt sent to a model that has access to the right matter file, the right clauses, the right prior work, and the right authoritative sources produces something that has a chance of being useful.

The shift in emphasis is recent, and it is the right shift. Public attention has caught up with what legal AI engineers and practitioners have known for some time. In legal work, the bottleneck is rarely how the question is worded. The bottleneck is the model's blindness to the file.

Context engineering is what removes that blindness, carefully.

The six layers of legal context

It helps to think of legal context as a stack of six layers. Each layer answers a different question, and each layer has different rules about what should and should not be exposed to an AI system.

1. Matter context. Who are the parties? What is the dispute or the transaction? What is the status, the timeline, the jurisdiction, the practice area? This is the minimum any legal AI needs to know to give an answer that is not generic.

2. Client context. Who is the client? What are their prior matters? What internal policies, templates, or red lines apply? What did the partner say in the last engagement letter? A client without context is a client receiving generic advice.

3. Document context. What documents are attached to this matter? Which are authoritative (signed, filed), which are drafts, which are external (received from the counterparty), which are internal (the firm's own work)? Without document-level clarity, the AI can quote a draft as if it were a signed contract.

4. Normative context. Which statutes, regulations, judicial decisions, and administrative texts apply? In Morocco, this includes the Code des obligations et des contrats, the Code de commerce, sectoral regulations, BAM circulars, CNDP rulings, OMPIC practice, and judicial decisions of varying availability. Normative context is hard, because in many areas of Moroccan law the authoritative sources are not centrally indexed.

5. Procedural context. Where is the matter in its procedural life? Pre-litigation, mise en demeure sent, summons issued, first hearing scheduled, judgment rendered, appeal lodged, enforcement underway. The same legal question receives different answers depending on the procedural posture. An AI blind to procedure is dangerous.

6. Governance context. Who is allowed to see what? Who must validate before something is sent? Who logs the action? Governance is not "extra." It is part of the legal context, because legal work is bound by professional duties.

A legal AI that operates with two or three of these layers but ignores the others is fundamentally limited. The architecture that makes all six layers available, safely, is what context engineering is for.

Why a prompt without context produces dangerous law

Consider a deceptively simple question. "Can my client terminate this contract without notice?"

Asked of a public general-purpose AI, the answer will be a confident essay on termination clauses, breach, force majeure, and good faith, drawn from a generic training corpus that may or may not reflect Moroccan law and certainly does not reflect this contract.

Asked of a legal AI with proper context, the question becomes a different question entirely.

• Matter context: this is a commercial supply contract between a Moroccan distributor and a foreign manufacturer.
• Client context: the firm has terminated five similar contracts for this client over four years, with a consistent strategy.
• Document context: the contract has an Article 17 on termination, an Article 19 on dispute resolution, and a signed amendment that modifies notice periods.
• Normative context: the applicable law is Moroccan, the courts are Moroccan, and the relevant provisions of the Code des obligations et des contrats are known.
• Procedural context: no mise en demeure has yet been sent, and no breach has been formally noted.
• Governance context: any termination memo must be reviewed by the partner before going to the client.

With these layers available, the AI does not hallucinate a generic answer. It produces a structured analysis pointing to Article 17 and the amendment, references the client's past practice, recommends the procedural step before termination, and routes the draft for partner review.

Same question. Different infrastructure. Different result.

Source-awareness as a non-negotiable

A consequence of taking context seriously is that every claim in a legal AI's output should be traceable to a source. Not as a stylistic preference. As a working requirement.

Source-awareness means three things in practice.

Every retrieved passage is identified. When the AI quotes from a contract, the user can click and see the original clause in the original document.

Every normative claim is anchored. When the AI refers to a statute or a regulation, the reference is real, current, and visible. No invented article numbers. No imagined decisions.

Every output carries its provenance. A memo produced by a Legal OS should be readable as both a legal analysis and a chain of citations the lawyer can verify in minutes.

This is how international platforms in the enterprise legal AI category have positioned themselves. Harvey on contract analysis, Legora on collaborative review, LexisNexis on regulatory and case-law research, all converge on the same idea. Source-awareness is the baseline. Anything less is research-grade marketing, not practice-grade work.

Context as a governance problem

There is one more layer to context engineering that is often underestimated. Context is not only about retrieval. It is about permission.

A legal AI that can retrieve everything in the firm is dangerous. A legal AI that retrieves only what the user is authorised to see, scoped to the matter the user is currently working on, with logs of what was retrieved, is something else entirely.

Context engineering and access control are not separate problems. They are the same problem viewed from two angles. This is why the trust layer described in Article 2 is not a side concern of legal AI. It is the precondition that makes context engineering safe.

In Morocco and francophone practice

Three Moroccan characteristics shape what context engineering must do locally.

Bilingual context. A matter often contains French and Arabic documents that refer to each other. A French-language SPA with an Arabic-language regulatory notification. A French contract with an Arabic procès-verbal. Context engineering for Morocco must treat both languages as first-class, with retrieval and citation working symmetrically.

Plural sources, dispersed access. Moroccan legal practitioners rely on a combination of codified law, sectoral regulation, administrative practice, and judicial decisions that are not always centrally available. A legal AI that pretends to "know Moroccan law" without acknowledging this is overclaiming. A legal AI that retrieves from the firm's own corpus first, supplemented by published primary sources and curated regional references such as LexisNexis Middle East, is being realistic.

Procedural texture. Whether before the Tribunal de commerce, the social courts, the administrative courts, OMPIC, the CNDP, or sectoral regulators, Moroccan procedure has texture. Deadlines, formal acts, languages of filing, registered notifications. The procedural context layer is not optional in Morocco. It is, in many matters, what decides the answer.

A Legal OS that does context engineering well in Morocco is therefore one that is bilingual at the retrieval level, conservative about normative claims it cannot source, and explicit about where the matter sits in its procedural life.

Practical example

A general counsel at a Moroccan industrial group receives a one-line email from the CEO. "Can we terminate the distribution agreement with X?"

Without context engineering, she has three options. Ask the legal AI in a generic way and receive a generic essay. Spend two hours building the context manually (pulling the contract, the amendments, the prior correspondence, the past internal positions). Or escalate the question to external counsel before she even knows what is at stake.

With context engineering inside a Legal OS, she opens the matter for the distribution agreement. The system already has the signed contract, the two amendments, the recent correspondence, and the prior memo prepared by external counsel two years ago when this question almost came up. She asks the AI to assess termination options based on the matter file. The AI produces a structured note that cites Article 12 of the contract, references the amendment dated two years ago, identifies a procedural risk linked to the notice period, points to the prior memo for continuity, and flags one open question that requires partner judgment.

She forwards a refined version to the CEO with her own recommendation and routes the question to external counsel only for the residual open issue. The total elapsed time is forty minutes instead of two days. And, more importantly, the analysis is grounded in this contract, this client's history, and this procedural moment.

This example is illustrative. Any specific legal output must be reviewed by qualified Moroccan counsel.

What this changes for Burhan

Context engineering is, in many ways, the central design discipline of Burhan.

Concretely, that means the matter is the unit of context, retrieval is scoped to the matter and the user's permissions, every AI answer carries its sources, the bilingual layer treats French and Arabic symmetrically, and the procedural and governance dimensions are part of the file rather than parallel to it.

This is what is meant by saying Burhan is a Legal Operating System rather than a legal chatbot. A chatbot has prompts and answers. A Legal OS has matters, documents, parties, timelines, sources, permissions, logs, and an AI layer that operates inside that structure rather than around it.

The lawyer does not disappear in this picture. The lawyer moves higher in the workflow. Out of the retrieval, into the judgment.

Key points

• A prompt is only as good as the context the model can safely access.
• Legal context has six layers: matter, client, document, normative, procedural, and governance.
• Generic answers from context-blind AI are not productivity. They are risk.
• Source-awareness is a baseline expectation for serious legal AI, not a premium feature.
• For Moroccan legal teams, bilingual retrieval, dispersed normative sources, and procedural texture make context engineering especially demanding, and especially valuable.