Article 86 right to explanation: requirements and evidence

What Article 86 asks deployers to explain, and to whom

Article 86(1) gives a person who is affected by a decision a deployer makes based on the output of an Annex III high-risk AI system the right to a clear and meaningful explanation of the AI system's role in that decision and of the main elements of the decision. Consider a common case: your HR team uses a screening tool that ranks job applicants, your credit team uses a scoring model for consumer loans, or your insurer uses a pricing model for policies. When the output has legal effects or similarly significant adverse effects on a person's health, safety or fundamental rights, that person can ask you what the system did and why it mattered to the outcome. The provision targets opaque automated decisions that leave people unable to contest a result they cannot understand. Critical infrastructure systems are excluded from this right.

The trigger has three parts that must all be met: the system is an Annex III high-risk system, the decision is made by the deployer or relies on the system's output, and the effect on the person is legal or significantly adverse. Article 86(2) and (3) limit the right. It does not apply where Union or national law provides exceptions or restrictions, and it applies only to the extent that Union law does not already provide for the matter. Your legal team should map which national rules, such as sector regulation for lenders or insurers, already govern explanations before promising one. Separately, under Article 26(11), you must tell affected people that the system is being used, so the notice duty and the explanation duty should be designed together.

The duty is hard in practice for two reasons. Many models produce a score or a label with no built-in account of which inputs drove it, and some vendor systems expose only the final output. Explanations must also be tied to the individual decision rather than to the model in general, which means your logs must capture the inputs, output and any human review for each case. Ask your provider, under Article 13(3)(b)(iv), whether the instructions for use describe the system's capabilities to provide explanation-relevant information. Then test whether your team can produce a case-level explanation within a practical timeframe, and record what the explanation covers and what it does not.

Which systems, decisions and teams fall under the explanation duty

Article 86 applies only when several conditions line up: an Annex III system, a deployer decision, and an effect on the person that reaches the threshold in the text. Each card below is a scoping question to settle in writing before you build explanation material, because the answers decide how much work follows.

Annex III status of the system

Article 86 reaches only decisions based on the output of a system listed in Annex III. Check the system against each Annex III category and record why it is or is not caught, including whether it is a standalone use or a component of a product. A system outside Annex III falls outside this duty even if it looks similar to a covered tool. Ask your legal team to confirm the classification in writing, and keep the reasoning with the system inventory.

Critical infrastructure exclusion

Article 86 does not extend to Annex III systems used as critical infrastructure. Where a system supports the management or operation of critical infrastructure, the explanation right does not apply under this article, even though the system is otherwise high-risk. Document which operational role the system plays and where the boundary sits between an infrastructure function and a business function such as billing or customer service. Confirm the boundary with the competent authority or counsel before relying on it.

Legal or similarly significant effects

The right is triggered only when the deployer's decision has legal effects or similarly significant adverse effects on a person's health, safety or fundamental rights. Map each decision point to a concrete outcome, such as a refused credit application, a rejected job candidate or a changed insurance premium, and record whether the effect is adverse. Routine outputs that feed a human decision with no meaningful weight may fall below the threshold, but the reasoning must be documented and reviewed.

Deployer or provider supplies the explanation

The deployer makes the decision and must be able to explain it to the affected person, so it needs the explanation material. The provider's instructions for use must describe any capability the system has to provide information relevant to explaining its output. Agree in the contract who produces the case-level explanation, who maintains the model-level description, and who answers follow-up questions. Gaps here are where most explanation requests fail.

Two-date timing gap

Article 86 applies from 2 August 2026, while the Annex III classification rules in Chapter III Section 1 apply from 2 December 2027, as amended in 2026. A deployer may therefore face explanation requests before the classification rules that define which systems are covered are in force. Decide now whether you will apply the explanation process to systems you expect to be classified as high-risk, and record that as a policy choice rather than a legal conclusion.

Union and national law carve-outs

The right does not apply where Union or national law provides exceptions or restrictions, and it applies only to the extent Union law does not otherwise provide. Sector rules in credit, employment, insurance or public administration may already require reasons for decisions. Map each use case to the sector law that governs it, identify any overlap with existing notice or reason-giving duties, and avoid building parallel processes that give different answers to the same person.

How an assessor tests the explanation duty

This table sets out the steps an assessor would take to test whether a deployer meets the Article 86 explanation duty, what each step samples, the evidence requested and where deployers commonly fall short. Read it as a test plan to prepare against, since the scope decision, decision records and notices all need to line up before anyone asks to see them.

Test step	What the assessor samples	Evidence requested	Common findings
Scope decision	The inventory entries for AI systems the deployer uses, and the reasoning that places each one inside or outside Annex III	Dated classification memo, system inventory extract, and the list of decisions each system informs or makes	Systems used for employee or customer decisions are missing from the inventory, or classification reasoning is undated
Affected decision sample	A selection of individual decisions, such as credit, hiring or benefit outcomes, where the AI output had a legal or similarly significant effect	Decision log entries linked to the AI output, the human reviewer record and the outcome sent to the person	Decision logs record the final outcome but not the AI output or its role in reaching it
Explanation records	Whether each sampled person received an explanation of the AI's role and the main elements of the decision	Explanation templates, sent copies, dates of sending and the data fields used to generate each explanation	Explanations are generic and do not name the AI's role or the factors that drove the outcome
Notice under Article 26(11)	Whether people were told they are subject to the Annex III system, and when	Notice wording, placement in the application or contact flow, and proof of delivery or display	Notice appears only in a privacy policy that the person never sees at the point of decision
Instructions for use under Article 13(3)(b)(iv)	Whether the provider's instructions describe the system's capability to produce explainable output, and whether the deployer follows them	Instructions for use as received, the deployer's internal procedure that references them, and any gaps the deployer raised with the provider	Instructions are filed but not used to build explanation templates, or the deployer never asked the provider what the system can explain
Limits and documentation	Whether the explanation states the system's limits and whether the deployer keeps records that support explanations	Limit statements in templates, technical documentation extracts, and change records for the model or its inputs	Explanations claim certainty the system cannot support, or model changes are not reflected in updated explanations
Exceptions and restrictions	Any decision where the deployer withheld an explanation relying on a Union or national law exception or restriction	Written legal basis for each exception, the approval record and the reasoning recorded at the time	Exceptions are applied by default, or the legal basis cited is not identified in the file

Implementing the explanation duty in six steps

This sequence turns Article 86 from a legal reading into a working process, so that each Annex III decision can be traced to a clear explanation given to the affected person when it matters.

Confirm Annex III scope for each system
Start by listing every AI system the organization deploys and checking whether each one is an Annex III high-risk system used to make or assist decisions about people. Legal, compliance and the business owner of each system should sign off together, because the answer depends on the actual use and not only on the vendor's description. Note that Article 86 excludes Annex III critical infrastructure systems, so record that exception explicitly. The output is a scope register that marks each system as in scope or out of scope, with the reason written next to it.
Map decision types and affected people
For each in-scope system, document every decision it informs, such as an eligibility, pricing, screening or access outcome, and identify the people affected by each one. Record whether the decision has legal effects or similarly significant adverse effects on health, safety or fundamental rights, because only those decisions trigger the explanation right. The output is a decision map that links each system to its decision types, affected groups and significance assessment, reviewed by someone who can speak for the business process.
Define the explanation content template
Write one standard template that every explanation follows. It should cover the role the AI played in the decision, the main factors that shaped the outcome, the known limits of the system, and the route to request human review. Pull the role and limits from the instructions for use the provider supplied, which should describe the system's capabilities to explain its output under Article 13. Legal review should confirm that the template meets the clarity standard and does not depend on Union or national exceptions. The output is an approved template with a worked example labeled as illustrative.
Build the decision record
Configure logging so that each output from the system carries an identifier, the inputs and factors that drove it, the model or version used, and a timestamp. Link each recorded output to the explanation generated from the template, so that a complaint or request can be traced back to the exact decision. Observability tools can capture this trail, but the organization must confirm that the logs hold the factors needed for an explanation and that personal data in them is handled under its privacy obligations. The output is a decision record that answers, for any given decision, what was decided, why, and which explanation was sent.
Write the affected-person notice and documentation
Prepare the notice that Article 26(11) requires for Annex III systems that make or assist decisions about people, telling them that the system is involved. Connect that notice to the explanation process, so the person knows where to ask for an explanation and how to reach a human reviewer. Keep the explanation documents in a controlled repository with version history and access rules, so that the wording given to each person can be reproduced later. The output is the approved notice, the request and review procedure, and an archive of the explanations issued.
Review explanations and complaints periodically
Set a recurring review, with a frequency the organization chooses and documents, that samples issued explanations and reviews complaints and human-review outcomes for each system. Check whether explanations match the decision records, whether the stated limits still hold after model or data changes, and whether affected groups receive consistent explanations. Feed the findings back into the template, the decision map and the scope register. The output is a dated review log with findings, corrective actions and an updated template version, which an assessor can test against the decision records.

How self-hosted open-source tools support explanation evidence

Self-hosted open-source tools can produce much of the evidence a deployer needs to explain an Annex III decision after the fact, but each one covers a different part of the record and none of them writes the explanation. Langfuse is the most direct fit for the decision trail. Its traces capture each operation in a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. If the deployer's decision workflow runs through a traced application, a trace can tie a specific decision to the model inputs and retrieved context behind it. Confirm that the trace holds the fields the decision record needs, such as the applicant identifier, the version of the model and prompt, and the human reviewer's action, and set retention so traces survive as long as the complaint and review window requires.

XWiki and BookStack cover the documentation side. XWiki keeps every change to a page under version control, recording what changed, when and by whom, and lets reviewers compare any two versions and roll back. That suits the explanation template, the plain-language description of the system's role, and the instructions for use that Article 13(3)(b)(iv) asks the provider to supply, because a regulator or assessor can see which wording was in force on the date of a given decision. BookStack assigns abilities through roles and lets permissions be overridden per role at the shelf, book, chapter or page level, so the team can restrict who may view or edit the notices that go to affected people. Decide who owns each notice and confirm that edit rights are limited to that owner.

garak (Apache-2.0) probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. It writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. This supports the reliability of the outputs a deployer relies on, which matters when an explanation cites what the model produced. It does not, by itself, produce an explanation, and a clean garak run says nothing about whether a specific decision was explained clearly. Treat these tools as evidence sources that a compliance owner assembles, reviews and signs off. Confirm the license terms in the project repository before you rely on them in a procurement file, and confirm with your legal team whether the combined evidence meets the clarity standard that applies in your Member State.

Which evidence passes an assessment

An assessor testing Article 86 will look for a chain of records: which systems are in scope, what explanation a affected person receives, how each decision ties back to the system output, and how complaints are handled. The cards below are the artifacts that connect those links, and each needs a refresh routine so it still reflects the live system at audit time.

Scope register of Annex III systems

This register lists every AI system your organization deploys, marks which ones fall under Annex III, and records the decisions each system makes or assists about people. Article 86 only applies to Annex III systems other than critical infrastructure, so the register is the starting point for deciding who is owed an explanation. Between audits, review it when a system is added, changed in purpose, or moved to a new business unit, and confirm each entry against the current Annex III wording with counsel. Note that Annex III classification rules apply from 2 December 2027.

Explanation template and approval record

The explanation template sets out the standard structure for telling an affected person what role the AI played, the main factors behind the decision, and the limits of the system. The approval record shows who reviewed the template, when it was signed off, and which decision types it covers. Assessors check that explanations are clear and meaningful for a lay reader, not copied from technical documentation. Re-approve the template after each material change to the model, its inputs, or the decision process, and record the version used for each decision.

Decision-level trace linking output to explanation

A decision-level trace records the inputs, the system output, the human or automated step that followed, and the explanation sent to the person. Without this link, you cannot show that the explanation describes the decision actually made. Observability tooling such as Langfuse can capture timing, inputs, outputs and metadata for each request, though you must configure what is logged and confirm retention and access rules against your privacy obligations. Test sample decisions each quarter by tracing one back from explanation to output.

Affected-person notice and delivery record

Article 26(11) requires deployers of Annex III systems that make or assist decisions about people to inform those people that they are subject to the system. The notice is the first artifact a person sees, and the delivery record proves it reached them, with date, channel and recipient. Check that notices appear before or at the point of decision and that the wording matches what the system actually does. Review notice text whenever the use case changes and sample delivery records each month to catch gaps in automated workflows.

Instructions for use and explainability statement

Article 13(3)(b)(iv) asks providers to describe, where applicable, the system's capabilities to provide information relevant to explaining its output. Your deployment should keep the provider's instructions for use and a short statement of what the system can and cannot explain, such as whether it produces feature-level reasons or only a score. Assessors compare your explanations against this statement to see whether you claim more than the system delivers. Obtain updated instructions from the provider with each release and reconcile them with your templates before the next version goes live.

Complaint and review log

The complaint and review log records every request for an explanation, every challenge to a decision, the reviewer assigned, the outcome, and the time taken to respond. Versioned wiki or document tooling such as XWiki can keep procedure changes traceable, while the log itself should stay separate from the decision records. Assessors look for evidence that people can actually obtain explanations and that patterns in complaints feed back into the system. Review the log monthly, close open items, and report recurring themes to the governance owner.

What meeting Article 86 costs in money and effort

This table lists the cost components behind an Article 86 explanation process, who is paid for each, whether it is one-time or recurring, and what drives it. Use it to build a quote request and to see where open-source tooling removes license spend. No figures are given because none are supplied for this topic, so ask each provider to price every row from your written scope.

Cost component	One-time or recurring	What drives it	How to keep it down
Engineering time for decision logging	One-time build, then recurring upkeep	Number of Annex III decision flows, how many model outputs feed each decision, and how much of the reasoning the system can actually record	Log the model output, input references and human review step in one schema from the start; reuse the schema across systems
Legal and compliance review of explanation templates	One-time drafting, recurring review when the system or law changes	Number of decision types, sector-specific rules that may create exceptions under Article 86(2), and how often counsel must sign off	Write one template per decision type with fixed sections; limit legal review to the template, not every individual explanation
Notice design for affected people	One-time design, recurring where notices change	Number of touchpoints where people meet the system, languages required, and the Article 26(11) duty to inform people they are subject to the system	Build notices into existing application or customer flows and test them once per release
Evidence upkeep and version control	Recurring	Frequency of model, prompt or threshold changes, and how long records must be kept for each decision	Store templates and notices in a versioned wiki or document system so each change has an owner, date and approval
Tooling licenses	Recurring where commercial, often one-time setup for self-hosted tools	Choice of logging, documentation and access control products and how many users or traces they cover	Self-hosted open-source tools can remove license spend for this component; confirm each tool's license terms and support model before you rely on them
Hosting and storage for logs	Recurring	Volume of decisions logged, retention periods, and whether logs hold personal data that must be secured	Set retention per decision type, keep logs in your own infrastructure, and purge records on a defined schedule
External review or testing of explanations	Periodic, one-time for initial review	Whether explanations are checked for clarity and accuracy by a reviewer independent of the build team, and the scope of the review	Scope the review to a sample of decision types and explanation templates in a written statement of work
Auditor or regulator sampling	Periodic, driven by the audit or inquiry	How many decisions an assessor samples, how quickly you can retrieve the records, and whether the records are complete	Make decision records searchable by case reference so sampled cases can be produced quickly
Implementation partner fees	One-time for the build, optional recurring for support	Fixed scope, number of systems, integrations and documentation to be produced	Agree deliverables, exclusions and acceptance criteria in writing before work starts; ask for each row above as a separate line item

Who owns the explanation duty, who helps, and who certifies

The deployer owns the Article 86 duty. The organization that uses an Annex III high-risk system to make or support a decision about a person must decide whether the duty applies to that decision, who receives the notice, what the explanation covers, and how a person can ask for a human to review the outcome. These are management and legal decisions, and they cannot be delegated to a vendor or consultant.

Scope decision: Confirm which systems are Annex III uses, which decisions they feed, and whether any Union or national law provides an exception or restriction under Article 86(2) and (3).
Notice: Own the Article 26(11) notice that tells people they are subject to the system, and approve its wording and timing.
Explanation policy: Define what a "clear and meaningful" explanation contains for each decision type, who drafts it, and who signs it off.
Human review route: Name the owner, the queue, and the response expectations for challenges to a decision.
Legal interpretation: Obtain counsel's view on how Article 86 interacts with other EU and national law that applies to the same decisions.

Before relying on any of these elements, confirm the scope and ownership in writing with your legal and compliance leads.

Where deployers fall short on explanations and how to close each gap

Most deployers of Annex III systems have a notice, a policy or a vendor explanation somewhere, but few can show that a specific person received a specific explanation about a specific decision. The six gaps below share that root problem, and each closing action produces a record an assessor can sample.

Explanations written after the fact

A generic model description is often written once and then pasted into a complaint response. Article 86 asks for clear and meaningful explanations of the AI's role and the main elements of the decision that affected the person, so a template does not meet it. Check whether each explanation can be traced to the inputs, output and human step for that decision. Close the gap by generating the explanation from the decision record at the time the decision is made, and store the text beside the decision ID.

Missing notices under Article 26(11)

Article 26(11) requires deployers of Annex III systems that make or assist decisions about people to tell those people that they are subject to the system. Notices are often placed in a privacy policy that the affected person never sees at the point of decision. Check that the notice appears in the channel where the decision is communicated, such as the application form, the claim letter or the case file. Close the gap by adding a dated notice to each decision workflow and logging when it was shown.

No record of AI role in staff decisions

When a caseworker, underwriter or recruiter makes the final call, the AI's contribution often leaves no trace. Without it, the deployer cannot say what role the system played in the outcome, which is the first element an explanation must cover. Check whether the decision log records the model output, its score or recommendation, and whether the staff member accepted, changed or overrode it. Close the gap by capturing those three fields in a trace that links the system version, input reference and reviewer identity.

Exceptions applied without documented legal basis

Article 86(2) and (3) let Union or national law restrict the right, and the right applies only where Union law does not otherwise provide. Teams sometimes withhold explanations on a general assumption of confidentiality or fraud prevention. Check that each refusal cites the specific provision and that someone with authority has approved it for that case. Close the gap by adding a required legal-basis field to the case record and by having counsel confirm the applicable national or Union rules before the workflow goes live.

Instructions for use omit explainability

Article 13(3)(b)(iv) requires instructions for use to describe, where applicable, the system's capabilities to provide information relevant to explaining its output. Vendor documentation often covers accuracy and intended purpose but says nothing about explanation features. Check the instructions for whether they state which outputs can be explained, which cannot, and which fields are logged. Close the gap by requesting an explanation capability statement from the provider in writing, and by recording any gap as a risk with an owner.

No review route for disputed outcomes

A person who disputes an outcome needs a path to a human who can reconsider it and explain the result again. Many deployers route complaints to a general inbox that has no link to the original decision record. Check that a dispute reaches a reviewer with access to the explanation, the inputs and the model version used, and that the response time is tracked. Close the gap by assigning a named review owner for each Annex III workflow, creating a dispute ticket linked to the decision ID, and reviewing a sample of closed disputes each quarter.

Questions buyers ask about the Article 86 explanation duty

How much does it cost to meet the Article 86 explanation duty?

The duty carries no fee of its own, so cost comes from the work it creates: identifying which decisions rely on an Annex III system, writing explanation templates, adding logging so decisions can be reconstructed, and training staff who answer requests. Your own staff are paid for decision ownership and legal review, engineers for logging and retrieval, and outside specialists only if you buy them. Mapping and template work is mostly one-time, while handling requests and keeping documentation current recurs. Costs rise with the number of systems, decision types and integrations. Ask any quote for a written scope listing the systems covered, the decision flows, the logging changes, the documents to produce and the training included. DeployOpen does not publish prices, and a quote follows from that written scope. No researched cost figure applies here, so confirm budget assumptions with your legal team.

When does the Article 86 duty start, and how long does the work take?

Article 86 applies from 2 August 2026. The Annex III high-risk classification rules in Chapter III Section 1 apply from 2 December 2027, so the practical trigger is the point at which your deployment uses an Annex III system to make or assist decisions about people. Confirm with counsel how these dates interact for your specific system, especially if it was already in use before the classification rules applied. No researched duration applies to this work. The effort depends on how many systems are in scope, how many decision types each one supports, and whether the provider's documentation is complete enough to base explanations on. A fixed-scope engagement sets a timeline in writing before work starts, so ask for that schedule rather than relying on a general estimate.

What does the team need to supply for Article 86 explanations?

Your team needs an inventory of Annex III systems in use, the provider's instructions for use, and the description of the system's capabilities to provide information that explains its output, which Article 13(3)(b)(iv) requires providers to include where applicable. You also need records of each decision: the inputs, the output, the human step that followed and the final outcome. Beyond that, supply explanation templates written in plain language, a notice process that informs people they are subject to the system under Article 26(11), a documented list of any Union or national law exceptions you rely on, and a named contact who handles requests. Legal review of those exceptions should come from your own counsel, since the Act leaves that analysis to the organization and the authorities.

Can an in-house team meet the Article 86 duty without outside help?

Yes, an in-house team can do this if it combines legal, product, data and engineering skills and has clear ownership of each decision process. The duty sits with the deployer, so the organization must do the work regardless of who helps. Your team can use tools already in its stack. XWiki keeps version history of explanation templates, recording what changed, when and by whom, and lets reviewers compare and roll back versions. BookStack lets you assign roles and override permissions at the shelf, book, chapter or page level, so only approved staff publish templates. For systems built on language models, Langfuse traces record inputs, outputs, tool calls and metadata, which helps reconstruct a decision. Outside help is most useful for scoping, gap reviews and evidence preparation.

Can a consultant issue a compliance opinion on Article 86?

No. A consultant can prepare systems, documentation and evidence and can review them against the requirement, but no consultant can issue a compliance opinion. Compliance is determined by the competent national market surveillance authority, or by an independent assessor where an assessment applies. DeployOpen prepares systems and evidence for compliance assessments and does not issue audit reports, attestations or certifications. When you evaluate any firm, ask what it will deliver in writing, who signs it, and how that output will be used by your legal team and by any authority that asks about your processes. Clear roles from the start prevent a gap between what your advisers prepared and what a regulator will test.

Does Article 86 require a notified body for my system?

Generally, the explanation duty itself does not require a notified body, because it is an obligation on deployers of Annex III systems. Notified bodies are involved in some conformity assessments under Article 43, including certain biometric systems and Annex I products, and most Annex III systems use internal-control assessment under Annex VI. Whether a notified body is part of your overall route depends on the system's category and its provider's conformity path. Confirm this for each system with the provider, your counsel and the relevant national authority. Ask the provider in writing which conformity route applies, since that determines what documentation they must hand over to you.

Must every AI-assisted decision come with an explanation?

No. Article 86 applies to a decision by a deployer that is based on the output of an Annex III high-risk system, where the decision produces legal effects or similarly significant adverse effects on a person's health, safety or fundamental rights. It does not cover critical infrastructure systems, and it does not apply where Union or national law provides exceptions or restrictions. The right applies only to the extent that Union law does not otherwise provide for it. Map each automated or assisted decision against those conditions before you design the process. Decisions outside the scope may still fall under other duties, such as GDPR rules on automated decisions, so have counsel review the full set of obligations for each decision type.

How DeployOpen scopes and prepares explanation evidence

DeployOpen works on Article 86 by preparing the self-hosted systems that record how an Annex III decision was made and what the AI contributed to it. Your organization owns the decision, the explanation duty and the legal review, while DeployOpen builds and documents the technical evidence behind them.

How we scope

Engagements are fixed-scope, with the Annex III decisions, affected groups and systems agreed in writing before work starts.
The written scope lists which decision flows need explanation records, such as credit, hiring or benefits determinations, and which are out of scope.
Scope confirms who in your organization approves explanation templates and who reviews any Union or national law exceptions that may apply.

How we build

We configure tracing so each AI-assisted decision keeps its inputs, outputs, retrieval steps and tool calls in a linkable record.
We set up version-controlled documentation for system descriptions, decision logic summaries and known limits, so every revision is traceable.
We configure role-based access so only authorized staff can view individual decision records, and we test those permissions before handover.

How we hand over

Handover includes a written record of what was built, the test results for explanation outputs, and the configuration used to produce them.
We document the steps your staff follow to retrieve an explanation for a named individual and to record the notice given under Article 26(11).
Deliverables are prepared for your independent assessor or internal audit to review, and DeployOpen does not issue any attestation or certificate.

How we support

Ongoing support, upgrades and continuous testing of explanation tooling are available as retainers agreed separately from the fixed-scope work.
Retainers can cover updates when your Annex III use case changes or when the Article 86 guidance and harmonised standards evolve.
Before scoping, confirm with your legal team how Article 86 interacts with sector rules, since those rules determine which explanations you owe.