assurance · Level 3

AI governance and service accountability for telecoms providers

A Mickai / Trust Agent workbook for adult telecoms teams: accountable AI proposals with clear service and operational boundaries.

By Mickarle Sean Junior Wagstaff-Irons - Micky Irons

  • Level 3Building
  • 720 min
  • 8 chapters
  • Online course and PDF workbook
original illustrationassurance / 03

Read, practise and review

Your next step

Start this course online

Register your start, then work through the lessons and exercises at your own pace. You can download the PDF separately. Where a scored exam is available, you will find it after the lessons.

Register or resume your course

Mickai privately records this registration and sends its team a course-start notification. It records your intention to start, not proof of attendance or completion. Our course-start privacy notice explains the details and the 30-day resume cookie.

Follow the Mickai company page on LinkedIn

You can start learning without subscribing or following. Newsletter email confirmation and provider enrolment are recorded separately.

Start with the essentials

The short answer

Assign accountable service owners before proposing AI use. Separate analytical assistance from operational authority,identify affected customers and dependencies,and review actual provider,jurisdiction,data and supplier requirements. Record uncertainty and require independent challenge,explicit stop controls and accessible continuity. Lyra rehearses these decisions with invented cases; its role strings and proposal review grant no real network control or service approval.

What you will learn

  • Map six fictional telecoms AI uses to affected services,dependencies,consequences and accountable owners.
  • Distinguish analytical permission,assumed review and operational authority with explicit excluded uses.
  • Build a provider and jurisdiction applicability register separating current law,code,regulatory guidance and voluntary frameworks.
  • Execute and independently challenge a finite synthetic governance workflow with separate reviews and versioned stop controls.
  • Prepare a bounded carrier pilot proposal with unresolved data,safety,customer and service-release decisions visible.

Who it is for

Adult carrier executives,enterprise architects,compliance leads and service owners. Fictional regional-carrier context; no customer data,live topology,operational instruction or telecoms professional approval.

Before you start

  • Understand AI use inventories,service dependencies and the difference between a draft and an approved action.
  • Optional original lab needs Python3.10 or later and standard library only. No model,paid service,customer file or network access.

Jurisdiction and study scope

These are selected reference pathways. Choose the relevant pathway before applying the exercises. This does not determine applicable law or provide worldwide coverage.

All pathway limits
  • Actual provider or jurisdiction unresolved: Identify the actual entity,public/private service,provider classification,territories,dataflows,AI role and safety consequences. Fictional labels and review roles determine none of these.
  • Scoped UK telecoms worked context: Review actual provider classification and duties against current legislation and July2026 code,with June2026 resilience guidance and its dated references distinguished. Commercial tiers and the statutory micro test are different. ICO DUAA/PECR and service-specific review remain unresolved.
  • Another jurisdiction or cross-border service: Review actual provider and AI roles,current applicable law,customer obligations,data transfers and accessibility. A dated Commission July2026 announcement is not a verified consolidated amended law. UK guidance and GSMA/NIST do not confer another jurisdiction approval.

Run the synthetic exercise

Download the exercise source, tests and instructions (ZIP)

No real records, external service or model is used by this exercise. Read the README before running it.

Owner-commissioned original course prepared with AI assistance. Lyra cases,source permissions and review roles are fictional. No provider endorsement,legal classification,safety certification or live-service authority claimed.

Learn in your browser · Chapter 01 of 08

01

Six uses, service dependencies and accountable inventory

Describe the decision and its service consequences before assigning an AI label, owner or permission.

Lyra-Regional-Training is an invented carrier used by adult executives, architects, compliance leads and service owners. Its proposal has six different uses, rather than one telecoms AI system awaiting a single approval. The immediate task is to build a service inventory showing what each use could influence and who must answer for that influence. The workshop uses original fictional descriptors and finite analytical checks. No model is called, no customer data is processed and no device, address, credential or actual network is represented.

A use inventory begins with a decision. An outage briefing helps a service owner decide what further evidence is needed. A customer FAQ draft could influence what someone believes about service status and how they seek help. A capacity note supports a discussion about historical counts. None supplies authority to repair equipment, send a message or change a network. An apparently harmless text output can still cause harm if a reader mistakes it for an operational instruction or a settled service fact.

Scroll sideways to see every column.

Six uses, service dependencies and accountable inventory · Table 1
Case, source and assumed ownerDecision and dependencyInitial paper boundary
T-01 outage-brief; case-01.json; training-network-service-ownerInterpret a received fictional advisory; needs verified incident factsanalyse only; root cause UNESTABLISHED; repairAuthorised false
T-02 customer-faq; case-02.json; training-customer-service-ownerDraft status wording; needs service evidence and a usable support routeanalyse only; status unestablished; route proposed
T-03 capacity-note; case-03.json; training-network-service-ownerExplain historical intervals; needs exact counts and their meaninganalyse only; 60 busy of 200 total, 30 percent
T-04 fraud-review; case-04.json; training-customer-service-ownerPurpose and permission unresolved; no fraud inferenceAlways held before source read
T-05 network-write; case-05.json; training-network-service-ownerOperational action excluded; no command or topologyAlways held, including analyse
T-06 emergency-path; case-06.json; training-network-service-ownerActual safety and authority review absentAlways held before read; no routing advice

These rows describe governance questions, not six deployed products. The code-owned risk labels are synthetic-internal, synthetic-public, synthetic-internal, purpose-unresolved, operational-authority-excluded and safety-review-unresolved respectively. They identify the teaching distinction without determining real confidentiality or regulatory risk. Initially, six unique version-1 requests have a paper expectation of three ANALYTICAL_DRAFT results, three holds and three reads. That expectation is not an observed runtime result. Reading the contract's held descriptor does not mean the lab opens the corresponding held source.

Dependencies are the evidence and service arrangements needed for a decision to be reliable. T-02 depends on trustworthy status information and on a human support route that people can actually use. T-01 depends on separating an advisory from an established cause. T-03 depends on the interval definition and a faithful count. An inventory should show both the upstream evidence and the downstream decision. It should also explain what happens when either is missing. A proposed route, an owner name or a percentage cannot fill those gaps.

Accountability is more than the name of the person who requested the tool. Identify the service owner who understands the consequences, the data owner who can review the material and the governance decision maker who considers the proposal. Record escalation and challenge channels alongside them. A contractor may help draft or supply software without replacing the carrier's actual duties. In Lyra, role strings merely stand for these separate conversations; they are not identities, authentication, contracts or proof that anyone accepted responsibility in a real organisation.

  1. Name each use and the exact decision it could influence.
  2. Identify affected readers, customers or service teams without inventing actual people.
  3. Map necessary evidence, upstream dependencies and downstream consequences.
  4. Assign the appropriate assumed owner and a distinct real review question.
  5. Record permitted analysis, excluded actions and the missing-evidence response.
  6. Keep the inventory current when purpose, audience, sources or requested authority changes.

gsma-responsible-ai supports use-case registries and defined governance roles as voluntary industry practices. The review read substantial indexed primary text, while direct pages and the full roadmap were unavailable; detailed maturity scoring remains unreviewed. nist-ai-rmf likewise offers a voluntary lifecycle method, including inventories and clear responsibilities. Neither source supplies a licence to operate, a verified vendor outcome or a release decision. Here they help organise questions that actual service and legal reviewers must resolve.

An average worked inventory contains one row: Lyra assistant, low risk, IT owner, ready because it only writes text. It conceals that the FAQ can mislead a customer, the capacity note can be mistaken for a forecast and the network-write proposal requests a different kind of authority. An elite inventory keeps all six rows. It names service dependencies, assigns network and customer owners separately, and records a held decision for the three excluded cases. It accepts a useful draft without claiming that a useful draft establishes a working service.

The elite author also defines the receiving audience. A network-service owner may need an uncertainty list, while a customer-service owner needs wording that avoids unconfirmed status or recovery promises. The same source may therefore support different reviewed explanations, but a new audience can create another disclosure or access question. Keep that question visible instead of assuming that an internal briefing is suitable for public use. No customer-send operation exists in this teaching boundary, so approved-looking wording remains a draft.

Write an inventory so a reviewer can challenge it. Replace vague benefits such as faster support with the decision being supported and the evidence that would show whether it helps. Record what the assistant may not infer. For T-04, the useful answer is that source purpose and permission remain unresolved, not a fictional fraud judgement. For T-06, the useful answer is a safety-review gap, not an emergency workaround. This makes the inventory an accountable proposal rather than a collection of optimistic feature names.

text · 6 lines
ROLE: Adult Lyra service-inventory drafter.
CONSTRAINTS: Six fictional cases only; analytical assistance cannot send, restore, route or write to a network. No real service or legal approval.
PROCESS: Identify decision, affected audience, evidence dependency, assumed owner and excluded action for each case.
VERIFICATION: Check exact case/source mapping and preserve T-04/T-05/T-06 holds before reads. Label initial three-draft/three-hold/three-read split as a paper expectation.
OUTPUT SCHEMA: caseId; sourceId; decision; audience; dependency; assumedOwner; allowedScope; exclusion; unresolvedReview.
FAILURE MODES: Reject one-row approval, text-only equals harmless, owner string equals identity, or proposed route equals implemented access.

A service inventory connects use to consequence

Each use needs a decision, dependencies and accountable review; missing evidence goes to a hold.

Name the useDecision and audienceRequired evidenceAccountable reviewHold unresolved scope
Steps
  • Name the use: Keep six separate cases
  • Decision and audience: Who might rely on the output?
  • Required evidence: Sources and service arrangements
  • Accountable review: Data and affected service owners
  • Hold unresolved scope: No operational or real-release authority
Relationships and conditions
  1. Name the use to Decision and audience: Define effect
  2. Name the use to Required evidence: Identify prerequisite
  3. Decision and audience to Accountable review: Assign responsibility
  4. Required evidence to Accountable review: Bring evidence
  5. Accountable review to Hold unresolved scope: Missing evidence or excluded action

Text equivalent: name each use, identify its decision and audience, and list the evidence or service arrangements it depends on. Bring both to accountable review. Preserve a hold when evidence is missing or the requested action is excluded.

Try it yourself · Activity 01

45 minutes

Split the one-row carrier assistant inventory

An invented proposal describes all six Lyra cases as one low-risk text assistant owned by IT. Replace it with a decision inventory suitable for adult service-owner review.

  1. Create six separate entries with exact case/source/owner mappings.
  2. Explain one consequence and evidence dependency for each allowed analysis.
  3. Preserve three excluded cases and distinguish a draft from sending or operating.
  4. Success criteria: six accurate entries, distinct customer/network responsibilities, initial paper split, actionable gaps and no real approval or operational instructions.

Which decision or affected audience disappeared when the proposal used one assistant label? State the evidence that its actual owner would need.

Worked answer

T-01/case-01.json and T-03/case-03.json belong to the assumed network-service owner; T-02/case-02.json belongs to the assumed customer-service owner. Their analyses require incident facts, historical count meaning and usable customer support respectively. T-04/case-04.json is held for unresolved purpose/permission, T-05/case-05.json for excluded operational authority and T-06/case-06.json for absent safety/authority review. Keep their exact assumed owners from the inventory. Initially expect three drafts, three holds and three reads on paper. Request separate data and service review, retain root-cause/status uncertainty and keep sending, restoration and network changes excluded. No real carrier, customer or permission is established.

Scroll sideways to see every column.

Six uses, service dependencies and accountable inventory · Table 2
Chapter review questionAnswer after your attempt
Why inventory decisions rather than tool names?A tool name can conceal different audiences, dependencies, consequences and requested authority.
How can a text-only use affect a service?Readers may rely on an unsupported cause, status or forecast and make consequential decisions.
Why separate T-01 and T-02 ownership?Network-service evidence and customer communication/access require distinct service perspectives.
Does a proposed support route establish access?No. Its implementation and actual usability remain unresolved.
Why retain T-05 when analysis is requested?The case is excluded even for analyse; a different operation label cannot create authority.
What do GSMA and NIST contribute here?Voluntary methods for inventories and responsibility, with no real compliance or release approval.

Apply what you learned · Practice

An inventory says the customer FAQ is harmless because it only produces text. What essential review is missing?

Explanation and answer

The consequences of customers relying on status wording and the usability of the proposed support route. Text can change customer decisions. Status evidence and actual access remain service-owner questions.

Practice only. This does not count towards your exam or certificate.

Original fictional Lyra service exchange places three analytical cases between excluded control uses and stop/review requirements.
Analytical assistance and network authority have different owners. This original illustration depicts no actual carrier, customer or service approval.

Three fictional analytical cases retain uncertainty, proposed human support and the historical60/200 calculation. Excluded network-write, fraud and emergency uses remain held. Assumed data and distinct service-owner reviews support a pilot proposal only; stop invalidates drafts and real service release stays held.

Next chapter

Learn in your browser · Chapter 02 of 08

02

Outage uncertainty, customer impact and resilience

Keep observed fictional facts, interpretation, arithmetic and recovery uncertainty separate when drafting a service briefing.

An outage assistant is valuable only if its readers can tell what is known and what remains uncertain. Lyra's T-01 original is Invented Lyra incident L-01: service advisory received; root cause not established. It describes receipt of an invented advisory, not a diagnosis, confirmed outage extent or repair. The permitted analysis preserves rootCause UNESTABLISHED and repairAuthorised false. A polished paragraph that inserts a likely equipment fault would be less faithful than a short briefing that keeps the question open.

Distinguish a supplied observation from an explanation. An observation records what the approved source states. An interpretation connects it to a possible meaning, but needs evidence and a qualified decision route. A recovery prediction asserts what will happen later and requires additional support. The absence of a cause is not evidence that there was no cause, and a received advisory is not proof that service is restored. Record each gap at the point where a reader might otherwise infer certainty from fluent writing.

T-02's complete original is Invented Lyra FAQ: service status is not established; use the proposed human support route. The wording contains two important limits. Status remains unestablished, and the support route is proposed. It gives no actual contact or implemented channel. A customer draft must preserve those limits rather than promise restoration, tell people their service is working or imply that an accessible route exists. An internal analytical result is not a sent message, and the exercise permits no customer-send operation.

Scroll sideways to see every column.

Outage uncertainty, customer impact and resilience · Table 3
Statement in a draftWhat its evidence supportsWhat still needs review
T-01 advisory receivedOnly the supplied fictional statementCause, extent, recovery and actual actions
T-02 proposed support routeA training proposal for human supportImplementation, availability and usable access
T-03 60 busy intervals of 200Historical synthetic proportion equals 30 percentInterval definition, representativeness and future interpretation
T-06 emergency-pathDescriptor of an excluded teaching caseActual safety and authority; no routing advice

Customer impact concerns the decisions and experiences that bad information could change. Someone might wait for a repair that has not been confirmed, abandon a necessary enquiry or struggle to reach support. These are hypothetical consequences for proposal review, not observed Lyra events or facts about real customers. Ask what evidence a service owner would need before accepting the wording, how a person could challenge it and what happens if the chosen communication route fails. Do not invent customer counts, vulnerability labels or service entitlements.

ofcom-resilience-2026 addresses availability, performance and functionality, with outcome-based guidance and expectations under relevant UK security duties. Its current guidance was published on 16 June 2026 and replaced the 2022 resilience document. It is a practical reference, not a complete incident decision or the sole compliance route. ofcom-security-procedures separately concerns monitoring, enforcement and reporting. This course makes no real reporting-threshold judgement and gives no restoration or emergency-routing procedure. The relevant provider must use its actual authorised incident arrangements.

T-03 supplies totalIntervals 200, busyIntervals 60 and busyPercent 30. Check 60 multiplied by 100 equals 30 multiplied by 200: both sides are 6,000. Dividing 60 by 200 gives 0.30, or 30 percent. This is the proportion of the supplied historical synthetic intervals labelled busy. It is not 30 percent of customers, probability of an outage, spare capacity, duration of disruption or a forecast. Exact arithmetic answers a numerical question; it does not establish what an omitted sampling method would justify.

  1. Copy the approved fictional facts without adding a cause, affected population or recovery time.
  2. Label interpretations and future claims separately from supplied observations.
  3. Recalculate the exact aggregate, naming its unit and denominator.
  4. Identify potential customer consequences as hypothetical review questions.
  5. Keep status uncertainty and proposed-route wording visible in the draft.
  6. Request actual service, safety, data and access evidence through authorised reviewers; keep excluded cases held.

The numerical denominator matters because a percentage can sound more general than the evidence. If a colleague substitutes customers for intervals, the calculation may remain 30 while its meaning becomes false. If the source count changes, recomputing a new plausible percentage does not make it the original checked baseline. The lab requires the exact code-owned counts and original text; source drift produces a hold rather than a newly accepted incident. A real project needs a documented process for authentic new evidence, separate from this fixed exercise.

In an average worked briefing, a manager writes: heavy traffic caused the outage; 30 percent of customers are affected; normal service should return soon. Each clause moves beyond the supplied material. The elite briefing says that the fictional advisory was received, cause and service status remain unestablished, and the historical busy-interval proportion is 30 percent. It lists the incident evidence and customer-route validation still needed. It proposes no repair. This wording supports review by making uncertainty legible instead of making the output sound decisive.

An elite customer-service reviewer also examines the journey after the message. Can the reader understand the uncertainty, challenge an incorrect answer and use the proposed human support route? A phone number alone would not establish access for everyone, and Lyra provides none. wcag22-technical contains selected keyboard and programmatic status-message criteria, but this workshop conducts no browser, assistive-technology or user test. Actual service accessibility and applicable law remain review questions. Accuracy of the sentence and successful access are related but distinct outcomes.

Use explicit unresolved fields rather than an unsupported confidence score. Ask what service status was verified, when, by whom and for which service. Lyra supplies no real answers, but these questions give the next reviewer a practical evidence request.

text · 6 lines
ROLE: Adult Lyra uncertainty-briefing drafter.
CONSTRAINTS: Fictional approved originals only; no cause, recovery promise, customer count, repair or emergency instruction. Proposed support is not implemented access.
PROCESS: Separate supplied facts, interpretation, numerical checks, customer consequences and missing evidence.
VERIFICATION: Preserve T-01/T-02 full originals and UNESTABLISHED status; check 60*100=30*200 for historical intervals.
OUTPUT SCHEMA: caseId; suppliedFact; unit; arithmetic; unsupportedClaimRemoved; uncertainty; requiredEvidence; assumedReviewer; draftOnly.
FAILURE MODES: Hold changed baseline, intervals becoming customers, percentage becoming forecast, or human-support proposal becoming an actual route.

Evidence limits the outage briefing

Fictional observations and arithmetic support a bounded draft; missing cause, recovery and access evidence remain questions.

Exact source factsHistorical arithmeticBounded briefingService-owner questionsKeep action excluded
Steps
  • Exact source facts: Advisory and unestablished status
  • Historical arithmetic: 60 of 200 intervals equals 30 percent
  • Bounded briefing: Separate fact, interpretation and uncertainty
  • Service-owner questions: Cause, recovery and customer-route evidence
  • Keep action excluded: No repair, message sending or routing
Relationships and conditions
  1. Exact source facts to Bounded briefing: Preserve wording
  2. Historical arithmetic to Bounded briefing: Preserve denominator
  3. Bounded briefing to Service-owner questions: Expose missing evidence
  4. Service-owner questions to Keep action excluded: No implied operational authority

Text equivalent: bring exact fictional source statements and the historical interval calculation into a bounded briefing. Separate supported facts from interpretations and uncertainty. Ask service owners for missing cause, recovery and access evidence while retaining the excluded-action boundary.

Try it yourself · Activity 02

45 minutes

Repair the overconfident outage briefing

An invented Lyra briefing claims heavy traffic caused an outage, 30 percent of customers were affected and service will return soon. It calls the proposed human route accessible. Rewrite it using T-01, T-02 and T-03.

  1. Identify every unsupported cause, population, forecast and access claim.
  2. Show the exact historical interval arithmetic and name its denominator.
  3. Prepare separate network-owner and customer-owner evidence questions.
  4. Success criteria: faithful source meaning, correct 30 percent calculation, unresolved cause/status/recovery, proposed-route limitation and no operational advice.

Which rewritten clause lost apparent confidence but gained evidential accuracy? Explain the next review action it enables.

Worked answer

The fictional T-01 advisory was received; root cause remains UNESTABLISHED and repairAuthorised remains false. T-02 states that service status is not established and the human support route is proposed. It does not establish an implemented accessible channel. T-03 gives 60 busyIntervals/200 totalIntervals:60*100=30*200=6000, so 30 percent of the supplied historical synthetic intervals were busy. No customer-impact percentage, causal explanation or recovery forecast follows. Ask the actual network-service reviewer for verified incident/status evidence and the customer-service reviewer for message and support-route validation. T-06 remains held; do not offer routing or restoration instructions. This is an analytical draft, not a customer communication or real service finding.

Scroll sideways to see every column.

Outage uncertainty, customer impact and resilience · Table 4
Chapter review questionAnswer after your attempt
What observation does T-01 actually supply?Receipt of the fictional advisory, with root cause explicitly unestablished.
Why can a correct percentage mislead?Changing its unit or denominator meaning can turn exact arithmetic into a false population or forecast claim.
What does T-03 establish?Only 30 percent of its supplied historical synthetic intervals were labelled busy.
Why retain proposed in the support wording?No actual support route or successful access is implemented or tested here.
Does resilience mean only resistance to attacks?No. Availability, performance and functionality can be affected by other events as well.
What should replace an unsupported recovery promise?An explicit uncertainty and a named request for verified current service evidence.

Apply what you learned · Practice

The calculation 60/200*100=30 is correct. Which briefing statement is supported?

Explanation and answer

Thirty percent of the supplied historical synthetic intervals were busy. The source counts intervals. It supplies no actual customer, predictive or spare-capacity evidence.

Practice only. This does not count towards your exam or certificate.

Next chapter

Learn in your browser · Chapter 03 of 08

03

Provider roles, jurisdiction and dated evidence

Build an applicability register that identifies the actual entity and activity before using laws, codes or industry frameworks.

Lyra supplies no actual entity, operating territory or accounts. The applicability register identifies evidence and qualified interpretation needed for each proposed activity. Its fictional analytical cases do not select real duties. A well-prepared question is distinct from an approved legal classification.

Start with who provides what to whom. The selected Communications Act definitions in uk-telecom-security-law concern public networks and services by their public availability. A supplier of an assistant is not automatically the provider of the network or communications service it supports. A private network is not classified as public merely because an AI tool analyses a descriptor about it. Actual facts, contracts and service arrangements must be examined. Record unresolved roles explicitly instead of substituting the convenient words vendor, operator or carrier for a legal definition.

Scroll sideways to see every column.

Provider roles, jurisdiction and dated evidence · Table 5
Evidence layerReviewed status and currencyQuestion for actual local review
UK Act and RegulationsBinding provisions; Regulations commenced 1 October 2022Which actual entity/network/service and duties are in scope?
DSIT security codeFinal version 1.1 issued 14 July 2026Which tier, measures and explained alternative approaches apply?
Ofcom resilience guidancePublished 16 June 2026; replaces 2022 guidanceHow should this provider evidence relevant resilience duties?
EU AI materialsCurrent Commission update; amended text retrieval unresolvedWhich territory, AI role, intended use and current provisions apply?
GSMA and NISTVoluntary maturity/risk methodsWhich practices improve evidence without pretending legal approval?
ICO and WCAGRegulator data guidance; technical web criteriaWhich data/access laws and actual service reviews are needed?

The UK framework has different layers. Section 105A addresses appropriate and proportionate identification, reduction and preparation for security-compromise risks. The Regulations specify additional measures; Regulation 10 includes governance and board-level or equivalent supervision. The DSIT code guides the preferred approach to compliance. dsit-telecom-code-2026 is the final July 2026 version, distinct from the June parliamentary draft and superseded 2022 code. Its explanatory memorandum says the revision introduces no new statutory duties. Guidance is nevertheless material within its statutory framework, not equivalent to an unrelated voluntary pledge.

Commercial tier and micro-entity exemption are separate tests. The reviewed code places providers with relevant turnover of at least GBP 1 billion in Tier 1, at least GBP 50 million but below GBP 1 billion in Tier 2, and below GBP 50 million in Tier 3 excluding micro-entities. Relevant activity, period and sustained tier-change rules matter. Regulation 16 has a CompaniesAct-linked micro-entity qualification and exempts qualifying entities from regulations 3 to 15. Do not use outdated accounting thresholds or infer exemption from every Act duty. Lyra has no accounts, so none of these classifications is selected.

Tier 3 providers are not expected to follow the code's measures but retain their applicable Act and Regulations duties. Other public providers and private-network providers may choose appropriate aspects of its guidance. The code is not the sole compliance route; an actual provider may need to explain different approaches to the regulator. NCSC technical advice does not decide regulatory compliance. These distinctions make a useful review request: identify role and duties, establish the relevant tier if applicable, and ask how the chosen evidence demonstrates an appropriate approach.

  1. Identify the actual legal entity, service, affected audience and operating territories.
  2. Separate telecom-provider, AI-provider/deployer and data-processing role questions.
  3. Classify each cited publication as law, statutory code, regulatory guidance or voluntary method.
  4. Record exact version/date, retrieved passages and unreviewed amendments or access failures.
  5. List facts needed to apply the source, with a named qualified reviewer and unresolved decision.
  6. Revisit the register when territory, intended use, supplier role or source currency changes.

eu-ai-current-scope records the Commission's 27 July 2026 Omnibus announcement and updated overview. They report Annex III high-risk application from 2 December 2027 and Annex I product rules from 2 August 2028, while general/transparency application begins 2 August 2026. This does not mean every AI obligation was postponed. EUR-Lex did not return substantive amended text, and ServiceDesk Article 2/Annex III warn their displayed text is not updated. Treat these dates as attributed official explanatory evidence, not a complete legal verification. Do not repeat old Article 4 wording or classify every telecom assistant as high-risk.

EU applicability requires actual territorial connections, AI roles and intended-purpose analysis. Neither a UK address nor a telecom label settles these questions. Request current-law review of the system, its output and the organisation's actual activity; Lyra establishes no real EU nexus or risk class.

An average worked register says UK carrier, therefore Tier 2, compliant with GSMA, and all EU AI rules delayed. Every conclusion jumps over missing evidence or confuses source status. The elite register instead lists public-service/provider facts and actual relevant accounts as missing, separates code tier from the micro test, labels GSMA voluntary and records the dated Commission update with its retrieval gap. It requests UK telecom and EU AI legal review before applying a duty. The output is more decision-ready because its unknowns have owners and evidence requests.

gsma-responsible-ai and nist-ai-rmf offer voluntary inventory and risk methods, with GSMA detailed retrieval limited. ico-data-principles retains a DUAA review notice. wcag22-technical supplies selected technical criteria rather than every carrier's accessibility law. Record each limit alongside its applicability question.

Version the applicability register and name review triggers for changed purpose, market, supplier roles or source currency. Unresolved is a useful entry when it includes an evidence route and a held decision; a filled worksheet is not real release clearance.

text · 6 lines
ROLE: Adult Lyra applicability-register editor.
CONSTRAINTS: No real entity, tier, micro exemption, EU risk class or compliance decision may be invented. Use reviewed source IDs only.
PROCESS: Separate role/territory facts, source legal status, date, applicability question and responsible reviewer.
VERIFICATION: Preserve July 2026 finalcode, June 2026 Ofcomguidance, partial GSMA retrieval, DUAA notice and unverified amended EU text. Do not apply stale micro thresholds or old Article 4 wording.
OUTPUT SCHEMA: activity; entityEvidence; roleQuestion; territory; sourceId; legalStatus; versionDate; retrievalLimit; missingFact; qualifiedReviewer; heldDecision.
FAILURE MODES: Reject sector-name classification, voluntary-method compliance, code-tier equals micro exemption or universal EU postponement.

An applicability register needs facts and current sources

Role and territory facts combine with dated source status before qualified interpretation, with unresolved decisions held.

Entity and activity factsCurrent source statusApplicability questionsQualified interpretationKeep unresolved releaseheld
Steps
  • Entity and activity facts: Service, audience and territories
  • Current source status: Law, code, guidance or voluntary method
  • Applicability questions: Roles, tier, exemptions and intended use
  • Qualified interpretation: Resolve actual facts and amended law
  • Keep unresolved release held: A completed register is not clearance
Relationships and conditions
  1. Entity and activity facts to Applicability questions: Identify missing evidence
  2. Current source status to Applicability questions: Check scope and currency
  3. Applicability questions to Qualified interpretation: Request interpretation
  4. Qualified interpretation to Keep unresolved release held: Retain open decisions

Text equivalent: collect actual entity, activity and territory facts separately from dated sources and their legal status. Use both to form applicability questions for qualified review. Preserve a held release wherever the facts, current law or interpretation remain unresolved.

Try it yourself · Activity 03

45 minutes

Challenge the automatic Tier 2 and EU-delay register

An invented Lyra register declares Tier 2 because the carrier is regional, a micro exemption because it is small, GSMA compliance and universal EU postponement. Replace these findings with an evidence-led review register.

  1. Identify the different factual and legal questions concealed by each label.
  2. Record current finalcode/guidance versions and the EU retrieval limitation.
  3. Separate voluntary methods and data/access review from legal clearance.
  4. Success criteria: no actual classification, no stale micro thresholds, accurate source status, attributed current dates and named qualified review questions.

Which apparently complete entry depended on a missing fact? Name both the fact and the person qualified to interpret it.

Worked answer

Regional does not select a tier. Request actual legal-entity/public-network-or-service facts and relevant activity/accounts/period information for UK telecom review. Keep commercial tier separate from the CompaniesAct-linked micro-entity test and from overarching Act duties. Identify the final 14 July 2026 code and 16 June 2026 resilience guidance; ask how applicable duties would be evidenced. GSMA and NIST remain voluntary methods. Record the Commission 27 July 2026 update and distinct application dates, with amended EUR-Lex text unverified and ServiceDesk text warnings. Request current EU territorial/role/intended-use interpretation without assigning Lyra a risk class. Keep data-law and accessibility applicability open through qualified local review; the actual release remains held.

Scroll sideways to see every column.

Provider roles, jurisdiction and dated evidence · Table 6
Chapter review questionAnswer after your attempt
Why does regional not select a provider tier?Tiering depends on relevant turnover, period and change rules, not geographic branding.
How is the micro test different?It is a distinct statutory qualification; it is not simply the code Tier 3 boundary.
Can a private-network provider use code guidance?It may adopt appropriate aspects; this does not itself classify it as a public provider.
Is the July 2026 code a new set of statutory duties?The explanatory memorandum says no; it revises technical guidance within the statutory framework.
What limits the EU material here?Current official explanations were read, but amended legal text was unavailable and some displayed text warns it is outdated.
What makes unresolved a useful register entry?A specific missing fact, qualified reviewer, evidence request and held decision.

Apply what you learned · Practice

Lyra has no actual entity or accounts. Which register entry is defensible?

Explanation and answer

Provider-role, tier and micro questions remain unselected for qualified review using current evidence. Labels and a dated source list cannot replace actual classification facts or current legal interpretation.

Practice only. This does not count towards your exam or certificate.

Next chapter

Learn in your browser · Chapter 04 of 08

04

Separate approvals, analytical authority and stopping

Use distinct data and affected-service reviews, then explain what stopping and resuming a teaching proposal actually changes.

A carrier proposal needs more than a person willing to click approve. It needs a clear account of what the approval covers, which evidence supports it and which actions remain outside authority. Lyra separates source-scoped analytical permission from assumed data review, two affected-service reviews and a pilot-proposal review. Each is a limited teaching step. None authenticates a human, selects actual legal applicability, approves customer processing or releases a real service. There is no operation that writes to a network or sends a customer message.

The request boundary contains exactly carrierId, caseId, sourceId, operation, purpose and version. The carrier is Lyra-Regional-Training, purpose governance-teaching and only allowed operation analyse. Exact matching and current active analytical permission are checked before source access. T-04, T-05 and T-06 remain excluded, even if a caller describes them as analysis or claims supervisor approval. A permission to read T-01 does not permit T-05. An attractive result or a confident role statement cannot widen the operation or source boundary.

Scroll sideways to see every column.

Separate approvals, analytical authority and stopping · Table 7
Teaching layerRequired current evidenceWhat it cannot confer
Analytical permissionExact eligible case/source, operation and active versionFraud, emergency or network-write rights
review_data: training-data-ownerAll three current allowed draftsActual lawful processing or supplier approval
review_service: network ownerCurrent data review and T-01/T-03 draftsCustomer-owner review or operational control
review_service: customer ownerCurrent data review and T-02 draftNetwork-owner review or message sending
review_pilot: governance reviewerAll drafts, data review and both service reviewsReal release; decision remains HOLD_FOR_REAL_PROVIDER_REVIEW
export_proposalCurrent active complete pilot reviewPublication, durable revocation or deletion of copies

The separate service reviews prevent one perspective from standing in for another. The assumed network-service owner reviews the outage and capacity drafts because their evidence relates to network-service interpretation. The assumed customer-service owner reviews the FAQ because wording and support access concern customers. Both depend on current data review. A network owner saying the arithmetic is correct does not establish that a support route is usable; a customer owner accepting cautious wording does not establish the incident facts. This is a designed responsibility distinction, not a real appointment.

uk-telecom-security-law includes governance duties for actual in-scope providers, including board-level or equivalent responsibility under Regulation 10. That does not mean this workshop appoints its training coordinator to a real board or interprets every required decision. ncsc-ml-principles supports lifecycle security ownership and explicitly is not a complete assurance framework. Here the practical lesson is to define authority and evidence before reliance, then preserve a challenge route when an output or permission appears wrong. Actual provider arrangements need qualified review.

  1. Verify exact current eligible drafts before requesting any assumed review.
  2. Obtain data review, then separate network-service and customer-service reviews.
  3. Ask governance review to retain all exclusions and unresolved real decisions.
  4. Stop the teaching proposal when its assumed permission or evidence is no longer current.
  5. After resuming, renew only eligible analysis and recheck sources using the current version.
  6. Repeat every required review before a fresh proposal export; keep real release held.

Pilot review requires three current drafts, data review and both service reviews. It returns SYNTHETIC_PILOT_PROPOSAL_ONLY with actualReleaseDecision HOLD_FOR_REAL_PROVIDER_REVIEW. The three held cases remain excluded, and actual legal, safety, provider, customer, network, user and assistive-technology readiness remain unresolved. Export preserves these limits; a shorter executive summary must not remove them.

Stopping is a state change in this finite exercise. change_state with the coordinator, current exact version and false suspends activity, increments version and clears permissions, verified drafts, reviews and proposal. Resuming with true at the current version increments again; it does not restore permission or approval. Wrong roles, stale versions and wrong types cannot substitute valid inputs, and a same-state request returns NO_CHANGE. Role strings are teaching labels rather than authentication, so this exercise does not establish a real security boundary.

In a paper trace starting at active version 1, a valid stop moves to suspended version 2 and a valid resume to active version 3. No current permission or review survives. The coordinator must renew the three eligible analytical permissions, then current-version execute or batch requests must produce verified drafts. Data review comes before the two separate service reviews; governance review and export follow only when all requirements are met. These are contract expectations, not observed execution. Renewal never adds fraud, emergency, network-write or actual data-processing authority.

A recognised failed retry also matters. If a previously verified eligible case is retried with invalid current evidence, its verification and current reviews/proposal are invalidated. A team cannot preserve yesterday's approval by ignoring today's failed check. Source drift does not become an authentic new event through a plausible explanation. Returned nested records are copies, so altering a displayed result cannot legitimately change the internal permission. In a real service, equivalent principles need actual access controls, audit records and documented authority, not a string comparison alone.

An average approval note treats data review as approval of every use and exports old records after resumption. The elite note requires both service owners, renewed current permission and fresh source checks. It holds export until the new sequence is complete, then retains the synthetic scope and actual release hold.

Stopping leaves earlier copied exports and source files unchanged. A fresh process reloads original active version 1 without approvals, so no durable cross-process stop is established. The real governance pack must ask who can suspend reliance, notify downstream users and control access, copies and restart. Those actual controls remain unresolved.

text · 6 lines
ROLE: Adult Lyra approval-and-stop trace reviewer.
CONSTRAINTS: Fictional analysis only; role labels are not authentication. No real launch, customer sending, network change or emergency advice.
PROCESS: Trace current permission, three checked drafts, data review, both distinct service reviews, pilot review and bounded export.
VERIFICATION: Check current version after stop/resume and failed known retries; renewal restores only eligible analysis, never old reviews or excluded rights.
OUTPUT SCHEMA: version; active; eligiblePermission; verifiedDrafts; dataReview; networkReview; customerReview; pilotScope; excludedCases; actualReleaseHold; copyRestartLimit.
FAILURE MODES: Hold missing owner review, stale approval, resumed-state equals renewed permission, or in-memory stop equals recall of prior copies.

Separate review layers precede a bounded proposal

Data review and both service perspectives are necessary, while stop invalidates the sequence and real release remains held.

Three current draftsAssumed data reviewNetwork-service reviewCustomer-service reviewSynthetic pilot proposalStop or invalidatedevidence
Steps
  • Three current drafts: Only T-01/T-02/T-03 analysis
  • Assumed data review: Actual data-law questions remain open
  • Network-service review: T-01 and T-03
  • Customer-service review: T-02 and proposed support
  • Synthetic pilot proposal: Real release held; three cases excluded
  • Stop or invalidated evidence: Renew, recheck and repeat reviews
Relationships and conditions
  1. Three current drafts to Assumed data review: All current drafts
  2. Assumed data review to Network-service review: Separate perspective
  3. Assumed data review to Customer-service review: Separate perspective
  4. Network-service review to Synthetic pilot proposal: Required
  5. Customer-service review to Synthetic pilot proposal: Required
  6. Stop or invalidated evidence to Three current drafts: Earlier sequence cleared

Text equivalent: obtain three current eligible analytical drafts and assumed data review, then obtain separate network-service and customer-service reviews. Both are required for the synthetic pilot proposal, whose real release stays held. Stop or invalidated evidence clears the earlier sequence and requires renewal, rechecking and fresh reviews.

Try it yourself · Activity 04

50 minutes

Rebuild authority after stop and resume

An invented Lyra team has an old reviewed proposal, stops at version 1, resumes at version 2 and tries to export immediately. It argues data-owner approval covers both service owners. Write the corrected paper trace and explain its limits.

  1. Show the resulting versions and distinguish state from permission.
  2. Identify every source check and separate review required before a fresh export.
  3. Explain excluded rights, earlier-copy persistence and new-process limits.
  4. Success criteria: version 1 to 2 to 3 trace, renewed eligible analysis, three checked drafts, data plus both service reviews, real release held and no operational claim.

Which review did the team treat as interchangeable with another? State the consequence that requires the missing perspective.

Worked answer

A valid stop at active version 1 yields suspended version 2 and clears permissions/drafts/reviews/proposal. Valid resume at version 2 yields active version 3 without renewal or approval. At version 3 renew only T-01/T-02/T-03 analysis, recheck all three sources, obtain training-data-owner review, then training-network-service-owner review for T-01/T-03 and training-customer-service-owner review for T-02. Only then can training-governance-reviewer review_pilot and current export_proposal occur. The result remains a synthetic proposal/export with real release held; T-04/T-05/T-06 remain excluded. Old copies and source files persist, and a fresh process resets original state, so durable real stop/revocation and actual authentication remain unestablished. This is a paper trace, not a runtime observation.

Scroll sideways to see every column.

Separate approvals, analytical authority and stopping · Table 8
Chapter review questionAnswer after your attempt
Why is data review insufficient for pilot review?Both affected-service perspectives and current drafts are separately required.
Can the customer owner substitute for the network owner?No. They review distinct current cases and consequences.
What survives a valid stop and resume?No previous permission, draft verification or review; prior external copies and source files remain.
Does renewal approve the proposal?No. It restores only eligible analytical permissions and requires fresh checks and reviews.
Why invalidate approval after a failed known retry?Current failed evidence cannot be hidden behind an earlier verified draft.
What does the fresh-process reset prove about a real stop?It proves no durable cross-process revocation or authenticated authority; actual controls remain a review gap.

Apply what you learned · Practice

At resumed active version 3, which next action is consistent with the contract?

Explanation and answer

Renew eligible analysis, recheck all three sources and repeat data and both service reviews. Resumption restores activity state only. Current permissions, evidence and distinct reviews must be rebuilt.

Practice only. This does not count towards your exam or certificate.

Original Lyra schematic distinguishes analytical evidence, separate review layers, stop controls and a held operational release.
Current evidence and separate assumed reviews support a fictional proposal. They do not authorise network changes, fraud processing or emergency routing.

The analytical path uses permitted sources and current checks, then data review, separate network/customer owner reviews and a governance proposal review. Stop or changed upstream review invalidates downstream state. The real operational-release branch remains held; old copies survive and a new process resets assumed memory.

Next chapter

Learn in your browser · Chapter 05 of 08

05

Data, source and supplier boundaries

Bind analytical assistance to a permitted source and purpose. Examine supplier reuse, logs and exit separately from a correct service draft or a fictional permission label.

Lyra-Regional-Training is an invented carrier governance workshop for adults. Its outage briefing, customer FAQ and capacity note are analytical teaching cases; none reads a real network or customer record. The source problem is a useful-looking draft whose data access or supplier use has widened unnoticed. A service owner may want a quick answer, while a vendor may request logs, support access or reuse rights. Record those activities separately. A correct paragraph cannot establish that the information behind it was appropriate to process or that a supplier can retain it.

Start with a source-purpose register: case, exact source reference, data description, intended activity, recipient, owner, access decision, uncertainty and review version. The register should explain why a source is needed rather than merely mark it available. T-01's invented advisory supports a draft that preserves an unestablished root cause. T-02 supports a bounded FAQ without promising established status. T-03 supports historical arithmetic. T-04's fraud-input purpose and permission remain unresolved. Reading it to discover whether it is useful would bypass the very question the register is supposed to answer.

In the finite contract, source filenames and mappings are code-owned. A request has carrierId, caseId, sourceId, operation, purpose and version, with exact types and current separate source permission checked before input/output. Only analyse is eligible; T-04/T-05/T-06 always hold before reads. A caller cannot add a provider, approval claim or arbitrary path. A source note is passive text, never privileged and never exported. That boundary prevents the note from acting as an instruction in this finite exercise; it is not a general claim that every retrieval system defeats malicious content.

After an allowed read, validate the exact source fields, revision, risk label, original and aggregate against the teaching baseline. Synthetic-internal and synthetic-public are exercise labels, not conclusions about actual data protection or public availability. A missing or changed source must not be accepted because another document carries an approving sentence. A recognised failed retry clears its verification and current reviews/proposal. Preservation matters: the original remains traceable and a derivative is identified as a draft, rather than quietly rewriting the account to fit a preferred service story.

Work through a paper vendor request: the supplier offers to improve T-02's FAQ if the carrier sends complete conversations and lets it reuse them for product improvement. The fictional FAQ source grants neither real chat access nor that new purpose. Split drafting, support investigation, logs, retention, model training and onward access into separate rows. Ask what actual information exists, why each use is necessary and which participant/customer notice, legal ground, contract and security decisions support it. No real conversation, account identifier or fraud input belongs in this workbook.

Reviewed source ico-data-principles covers purpose limitation, minimisation, accuracy, retention, security and accountability. Its DUAA review notice remains visible; a March 2026 purpose-limitation update is not proof every related page is fully revised. No lawful basis, controller/processor role, PECR rule, transfer mechanism or automated-decision regime is selected here. Telecom service data and customer communications need focused local review. Calling an activity analysis, or choosing a familiar supplier name, cannot resolve those duties or authorise reuse.

An average request says Use every available record and the vendor's recommended settings to improve the answer. An elite paper prompt gives the role of carrier source-boundary drafter. Constraints: use only permitted fictional originals, preserve uncertainty, no real customer data, new purpose or operational action. Process: map each proposed recipient/activity, identify unsupported reuse and prepare review questions. Verification: compare claims with exact source/revision, permission and vendor evidence; inspect passive notes. Output schema: case, supported draft, source, recipient, purpose, uncertainty and required owner. Failure modes: hold unresolved fraud data, widened logging/training, caller approval or source drift. No model executes this instruction.

Supplier evidence should describe actual purposes and access, not rely on a badge. Ask where information is processed, who can see it, which subprocessors participate, how long original/derived/log copies persist, what training is allowed and how a change is notified. Contracts, security evidence and demonstrated controls must agree. Technical guidance ncsc-ml-principles supports lifecycle ownership and supply-chain questions at this level; it is not a comprehensive assurance checklist or regulatory certificate. The fictional lab contains no commercial provider review or model evaluation.

Exit is another data-flow activity. Specify usable return formats, ownership of originals and derivatives, export permissions, residual copies, deletion evidence and accountable follow-up. A readable download does not show that a supplier has erased backups or stopped reuse. Sovereign control means demonstrated choices over sources, processing, access and exit. Local storage or nationality alone does not establish those choices. Lyra returns deep-copied in-memory objects with assumed roles; it implements no durable identity, supplier migration or deletion process.

The workable deliverable is a bounded source/vendor register alongside three eligible analytical drafts and explicit exclusions. Its open questions should identify the actual reviewer and evidence needed, not leave a vague statement that legal will check everything. A service owner can challenge an unsupported statement without learning how to configure or operate a network. Keep data access, draft quality, service authority and release separate. This educational register confers no actual source permission, confidentiality approval, safe processing or provider acceptance.

A useful draft does not widen data permission

Link the source to a purpose and inspect every supplier activity separately.

Case and source registerBefore-read authorityDraft and source checkSupplier activityquestionsExit evidence
Steps
  • Case and source register: Exact original and permitted analytical purpose.
  • Before-read authority: Current source-scoped grant; held cases stay unread.
  • Draft and source check: Notes stay passive; uncertainty preserved.
  • Supplier activity questions: Logs, support, training, recipients and retention.
  • Exit evidence: Usable return and residual-copy responsibilities.
Relationships and conditions
  1. Case and source register to Before-read authority: Check the evidence boundary
  2. Before-read authority to Draft and source check: Check the evidence boundary
  3. Draft and source check to Supplier activity questions: Check the evidence boundary
  4. Supplier activity questions to Exit evidence: Check the evidence boundary

Text equivalent: A case/source register names the intended analytical purpose. Current separate permission is checked before a read. The draft preserves the original and uncertainty, while passive notes supply no authority. Supplier activities are reviewed separately. Exit planning identifies usable return, residual copies and responsible actions.

Try it yourself · Activity 05

60 minutes

Audit a supplier request that widens FAQ data use

A paper supplier proposal wants all real customer conversations to polish T-02 and permits indefinite improvement reuse. It cites a note saying approved. Write the bounded register response.

  1. Separate the allowed fictional FAQ from proposed real data and reuse.
  2. Identify source, recipient, purpose, logs/retention/training and authority questions.
  3. Success criteria: no upload or invented approval; passive note grants no rights; actual data/contract/security review and exit evidence named.

Which supplier activity might be invisible in a fluent FAQ draft? Explain what evidence would make that activity reviewable.

Worked answer

Retain T-02 as a draft based only on its permitted invented source. Hold real conversation access and improvement reuse: neither follows from the FAQ source or passive approval note. Split drafting, support, logs, retention, training and onward recipients. Ask actual data/legal, contracts/security and service owners what grounds, notices, instructions and controls apply, including PECR and transfers where relevant. Preserve source/revision and current permission, identify needed evidence and define usable return/residual-copy questions. No provider or real processing is approved; no model or customer record is used.

Scroll sideways to see every column.

Data, source and supplier boundaries · Table 9
Chapter review questionAnswer after your attempt
What may a passive note authorise?Nothing. It is data, not a permission or privileged instruction.
Why is T-04 unread?Its source purpose and permission are unresolved; usefulness does not justify bypassing the gate.
Are synthetic risk labels legal classifications?No. They describe teaching fixtures, not actual data or provider applicability.
Does a correct FAQ settle retention?No. Draft correctness and supplier retention are separate decisions.
What does NCSC guidance supply here?Bounded lifecycle/supply-chain questions, not compliance or operational authority.
What establishes sovereign exit control?Demonstrated access, usable export, residual-copy and accountable exit evidence, not a location label.

Apply what you learned · Practice

A source note asks the program to approve extra vendor reuse. What should the finite source check do?

Explanation and answer

Keep the note passive and retain the separate permission boundary. Source content cannot create recipient rights, processing grounds or approval.

Practice only. This does not count towards your exam or certificate.

Next chapter

Learn in your browser · Chapter 06 of 08

06

Trial design, quantitative checks and reproducible challenge

Test analytical boundaries and uncertainty with invented cases. Recompute historical capacity, challenge reviews independently and avoid treating fixture success as model or service acceptance.

A carrier governance trial should state what it can establish before anyone sees a pleasing output. Lyra's finite question is whether exact fictional analytical requests preserve source, uncertainty and authority boundaries. It has no model, network call, device interface, customer input or restoration operation. Therefore it cannot measure model accuracy, availability, latency or safe service recovery. The adult trial deliverable is a reproducible boundary record, not a performance claim. Human challenge must be distinguishable from the author saying the design looks sound.

Define the initial expected fixture. Six unique version-1 requests are designed to produce analytical drafts for T-01/T-02/T-03, holds for T-04/T-05/T-06 and three source reads. T-01 preserves root cause as UNESTABLISHED and no repair authority. T-02 preserves unresolved service status and a proposed human route, not an implemented customer channel. T-03 supplies historical counts only. Training risk labels, case owners and permissions remain fictional assumptions. Expected counts become observed results only when an actual report records the execution and its current inputs.

Choose challenges that could falsify a claimed boundary. Try a wrong source mapping, unknown field, boolean version, excluded operation, duplicate case and changed original. Ask not merely whether HOLD appears, but whether a prohibited read happened before it. Every duplicate occurrence is denied during batch preflight, including malformed repeated requests. A known failed retry invalidates its verification and all current owner reviews/proposal. A reassuring earlier draft cannot be used to export after that failure. Source checks include exact types and values, not a visual impression that the text is close enough.

Recompute T-03 independently: busyIntervals 60 divided by totalIntervals 200 equals 0.3, or 30 percent. The exact relationship is 60 multiplied by 100 equals 30 multiplied by 200. These historical synthetic counts cannot forecast demand or show present congestion. A changed source claiming 35 percent fails the approved numeric relationship and baseline. Do not infer spare capacity, recovery time or permission to change the network from the percentage. The governance point is that an accurate calculation can still be irrelevant to a proposed operational conclusion.

Worked paper outage challenge: a derivative of T-01 says the supplier fault caused the incident and restoration is authorised. The original says only that a service advisory was received and root cause is not established. A reviewer should separate observed source text, suspected cause and requested authority. Reject the unsupported cause and restoration sentence while keeping a useful uncertainty-preserving briefing. There is no real incident, root-cause investigation or network recovery here. The paper critique demonstrates a review method, not evidence that a model generated or detected the defect.

An average instruction says Run the sample and confirm it is ready for customers. An elite prompt defines the role of analytical boundary-test planner. Constraints: synthetic cases only, no network/customer action or model metrics, uncertainty retained. Process: record expectations, challenge sources/permissions, recompute capacity and test separate review ordering. Verification: inspect reads, exact current inputs, outputs, discrepancies and reset behaviour. Output schema: case, expected gate, observed result if executed, arithmetic, version, review layers and limitations. Failure modes: hold unexpected reads, unsupported cause, wrong numbers, stale export or a pass treated as release. No model executes the prompt.

The contract separates review_data, review_service and review_pilot. Data review requires all three current drafts under assumed training-data-owner. Network service review covers T-01/T-03, while customer service review covers T-02; both require current data review and relevant drafts. One service owner's review cannot substitute the other's. review_pilot requires all three drafts and all three current review layers. It returns a synthetic proposal whose actual release decision remains held for real provider review. These assumed roles are not authenticated professional sign-off.

Export needs the complete current pilot review and active state. It returns a deep copy of draft records, separate data/service layers, held cases and unresolved items. Editing a nested returned review to say approved changes the caller's copy, not stored authority. Conversely, a legitimate change_state operation invalidates actual teaching permissions and review. Test those different routes separately. A separate new process reloads initial active version 1 without approvals. That reset exposes the absence of durable stopping or identity control; it does not prove a deployed carrier can forget a real stop safely.

Reviewed source nist-ai-rmf offers the voluntary GOVERN, MAP, MEASURE and MANAGE method, with governance across the lifecycle. It can help organise challenge questions, responsibilities and evidence; adopting it selects no legal duties or release authority. Reviewed ofcom-resilience-2026 is June 2026 regulator guidance on availability, performance and functionality, including automation consequences. Selected sections were reviewed, not every infrastructure measure. Neither source makes a three-case analytical fixture a live resilience or safety test. No operational instructions belong in this workbook.

Record exact source/code/fixture versions, commands, actual failures/skips and the person or independent reviewer who challenged the results. Preserve discrepancies instead of adjusting expected outcomes to hide them. Repeat affected checks after a source or policy change and connect them to current review state. The trial is useful when it can explain what stayed unread, which claim remained uncertain and why a release is still held. Its conclusion should be a bounded evidence record for human governance, not a certificate of service readiness.

Trial evidence has several independent questions

Check reads, claims and arithmetic before separate review layers and bounded export.

Expected fixtureBoundary challengesUncertainty andarithmeticSeparate review layersCurrent pilot/export
Steps
  • Expected fixture: Three drafts, three holds and three reads.
  • Boundary challenges: Types, mappings, duplicates, operations and source drift.
  • Uncertainty and arithmetic: Root cause unresolved; historical 30 percent.
  • Separate review layers: Data, network service and customer service.
  • Current pilot/export: Training proposal; real release held.
Relationships and conditions
  1. Expected fixture to Boundary challenges: Check the evidence boundary
  2. Boundary challenges to Uncertainty and arithmetic: Check the evidence boundary
  3. Uncertainty and arithmetic to Separate review layers: Check the evidence boundary
  4. Separate review layers to Current pilot/export: Check the evidence boundary

Text equivalent: The trial starts with expected decisions and read counts. Challenges inspect types, mappings, duplicate requests, operations and source drift. Drafts preserve uncertainty and historical arithmetic. Separate data, network and customer reviews feed a current pilot/export. Real release stays held.

Try it yourself · Activity 06

60 minutes

Reject an accurate but unsupported service conclusion

A paper trial summary says T-03 proves 70 percent spare future capacity and T-01 authorises repair. Prepare a challenge record with the separate review sequence.

  1. Recompute 60/200 and identify inference beyond the source.
  2. Preserve root-cause and operational-authority limits.
  3. Success criteria: historical 30 percent only; no forecast/repair authority; expected versus observed separate; data and both service reviews before pilot/export.

Which precise evidence would the trial need before a forecast claim could even be assessed? Explain why this fixture does not contain it.

Worked answer

The synthetic historical busy proportion is 30 percent. Subtracting from 100 does not establish future usable capacity or permission to change a network. T-01 leaves root cause unestablished and repair unauthorised. Hold those unsupported conclusions and retain bounded drafts. After current permitted source checks, review_data precedes separate network T-01/T-03 and customer T-02 review_service calls; review_pilot requires all layers. Export still reports a training proposal with real release held. Record actual runs only when executed, including read counts and failures; no model or service performance was measured.

Scroll sideways to see every column.

Trial design, quantitative checks and reproducible challenge · Table 10
Chapter review questionAnswer after your attempt
What is the T-03 busy percentage?30 percent from synthetic historical 60/200, not a forecast.
What is T-01 root cause?UNESTABLISHED; the advisory alone supplies no cause.
Does an analytical pass permit repair?No. Operational action is excluded and no repair method exists.
Can network review replace customer review?No. Their relevant drafts and consequences are distinct.
What does a returned-copy approval edit do?It changes that copy, not stored permission or review.
What does a new process demonstrate?Initial teaching state reloads without approvals; durable stop/authentication is not established.

Apply what you learned · Practice

A capacity source changes busyPercent to 35 while counts stay 60/200. Which trial decision fits?

Explanation and answer

Hold the source mismatch; historical arithmetic gives 30 percent. Exact synthetic counts and the approved source must agree; no operational inference follows.

Practice only. This does not count towards your exam or certificate.

Next chapter

Learn in your browser · Chapter 07 of 08

07

Incident escalation, customer continuity and accountable monitoring

Plan who challenges and stops an analytical proposal. Preserve customer uncertainty, usable non-chat routes and evidence for actual service owners without issuing operational restoration advice.

Stopping a governance proposal and restoring a carrier service are different actions. Lyra teaches the first with invented analytical cases; it provides no network or emergency procedure. A misleading outage draft could affect a service team's judgement, while an inaccurate FAQ could obstruct a customer's next step. These are proposed consequence pathways, not observed incidents. A monitoring plan should identify those pathways, the evidence that triggers human challenge and the person who can suspend the draft workflow. It cannot infer live control authority from familiarity with the training interface.

An incident register needs a bounded account: draft/version, source, detected problem, potential recipient, decision owner, current hold and unresolved service questions. Preserve the original and rejected derivative so the reviewer can explain the difference. Avoid writing root cause when only a symptom or advisory exists. A proposed escalation should ask the authorised actual service owner to determine the next action under their process. No real reporting contact, legal notification threshold, configuration, attack step or emergency-routing instruction is supplied in this course.

Reviewed source uk-telecom-security-law includes regulation 10 policy review, incident arrangements, escalation, learning and board-level or equivalent supervision within its actual scope. Reviewed ofcom-security-procedures explains monitoring, enforcement and relevant security-compromise reporting, but only selected sections were read. Actual incident facts and applicable provider duties need qualified review; the fictional register cannot select a reporting threshold or make a report. Scope is not settled by Lyra being called regional. Its entity, public network/service role and jurisdiction remain unresolved.

Worked paper incident: a T-02 FAQ derivative promises the service is restored and directs customers to an unimplemented support route. Its approved original leaves status unestablished and calls the route proposed. Treat certainty and access as separate defects. Hold the derivative, retain the original, identify where copies went and ask the customer-service owner to review a corrected uncertain message and realistic route. Do not silently repair a central draft and assume every customer-facing copy changed. No real customer has received either text in this exercise.

The training coordinator can use change_state with current exact version and an exact boolean active state. A changed state advances version and clears all permissions, verified drafts, both service reviews and proposal. Same state gives NO_CHANGE. Resume is allowed under the current version while suspended, but restores no permission or approval. renew_permissions then reinstates only eligible analytical source grants. Fresh checks, review_data, both review_service calls and review_pilot are required before export. Knowing that sequence grants no authority to restore, transmit or touch a live carrier service.

An average instruction says Fix the FAQ and resume because the outage is urgent. An elite incident prompt defines the role of adult service-governance organiser. Constraints: no live action, false certainty, customer data or emergency advice; original uncertainty and held cases retained. Process: record the defect, suspend the draft workflow, locate dependent copies and route separate owner questions. Verification: check current version, source, eligible grants, review layers and proposed access route. Output schema: incident, hold, affected drafts/copies, owner actions, restart evidence and unresolved real-service gate. Failure modes: hold unsupported restoration, inaccessible escalation, stale review or resumed state mistaken for approval. No model executes the prompt.

Customer continuity must work when chat is unsuitable or unavailable. Plan appropriate human-assisted or non-digital routes with the actual provider and users; a phone alone is not usable for everyone and may share an affected dependency. A paper notice, suitable text channel or supported human route can be proposed, but none is implemented here. Describe status uncertainty honestly and avoid promising a resolution time without evidence. Record dependencies and how a user would know the next step. This is service-access planning, not emergency assistance.

Reviewed wcag22-technical provides selected keyboard-operation and programmatic-status-message criteria, with their levels and exceptions. Complete conformance concerns full pages and processes, not just a chatbot response. The teaching inference is to examine whether a person can reach and use the support route, not merely whether the answer is correct. Actual browser, assistive-technology and affected-user review remain open, as does the applicable legal regime. Do not impose public-sector website rules automatically on every private carrier or claim access success from clear prose alone.

Monitoring should distinguish source drift, draft uncertainty, review freshness and route availability. Ask what observations would trigger a hold, who examines them and what evidence is retained. A changed source original or a failed known retry invalidates the current proposal in the finite contract. A monitoring dashboard should not hide that behind an earlier success count. Logs and monitoring inputs themselves need purpose, access, retention and supplier review. No rate, latency, availability target or model-performance threshold has been validated by this course.

Post-incident review can improve ownership and handover without rewriting history. Identify which draft crossed a boundary, why the review missed it, which copies remain and what condition must be demonstrated before restart. Old exports are unchanged by the lab; a separate process reloads initial state without approvals. Mutable role strings and memory are not durable incident governance. The useful output is an accountable challenge and continuity plan with explicit limits. Actual restoration, safety, legal reporting, provider readiness and customer access require their own authorised evidence.

A stop holds the proposal, not a restoration command

Suspend and investigate analytical defects, then renew and review without claiming live service authority.

Detected draft defectVersioned stopOwner and copy follow-upUsable continuityproposalRenew and re-review
Steps
  • Detected draft defect: Source, uncertainty and access failure identified.
  • Versioned stop: Permissions and current reviews are cleared.
  • Owner and copy follow-up: Network/customer questions remain distinct.
  • Usable continuity proposal: Actual provider/user/access review required.
  • Renew and re-review: Fresh checks; real-service gate stays held.
Relationships and conditions
  1. Detected draft defect to Versioned stop: Check the evidence boundary
  2. Versioned stop to Owner and copy follow-up: Check the evidence boundary
  3. Owner and copy follow-up to Usable continuity proposal: Check the evidence boundary
  4. Usable continuity proposal to Renew and re-review: Check the evidence boundary

Text equivalent: A detected draft defect records source uncertainty and access problems. A versioned stop clears current permission and review. Separate owners investigate relevant drafts and copies. Suitable continuity routes require actual provider/user review. Renewal and fresh separate reviews can restore a training export while the real-service gate remains held.

Try it yourself · Activity 07

60 minutes

Rehearse a stopped FAQ workflow and bounded restart

A paper T-02 derivative claims restoration and an implemented phone-only route. The training proposal is suspended. Prepare the incident handover and restart requirements.

  1. Identify certainty and access defects separately.
  2. State current-version stop/resume/renewal and separate owner reviews.
  3. Success criteria: original uncertainty retained; no live restoration/contact instruction; suitable continuity and old-copy follow-up; real release held.

Which restart condition could be mistaken for real service recovery? Describe the evidence boundary that prevents that interpretation.

Worked answer

Hold the false restoration claim and unimplemented phone-only route, retain the original FAQ and record derivative/version/copy recipients. Ask the customer-service owner about accurate status and usable alternatives, with actual user/AT/provider review. The coordinator resumes under current exact version, but permissions remain absent. Renew eligible analytical grants, check all three current sources and complete data, network-service and customer-service reviews before pilot/export. Keep fraud/network-write/emergency cases excluded. Existing copies remain and no live service action or actual route implementation has occurred.

Scroll sideways to see every column.

Incident escalation, customer continuity and accountable monitoring · Table 11
Chapter review questionAnswer after your attempt
Does a training stop restore service?No. It changes proposal state and grants no operational authority.
What remains unknown in T-02?Actual service status and an implemented usable support route.
Does resume restore reviews?No. Explicit renewal, fresh checks and separate reviews are required.
Why is phone-only continuity insufficient as an assumption?Users and service dependencies differ; suitable routes require actual review.
Can the register select a real notification threshold?No. Incident facts, provider scope and applicable duties need qualified review.
What survives a training stop?Earlier copied exports and source disk; the lab does not erase distributed copies.

Apply what you learned · Practice

The coordinator resumes the training workflow. Which next claim is justified?

Explanation and answer

The resumed state still needs eligible renewal, fresh checks and separate reviews; real release remains held. Resume changes teaching state; it does not grant permission, approval or operational success.

Practice only. This does not count towards your exam or certificate.

Next chapter

Learn in your browser · Chapter 08 of 08

08

Complete carrier governance proposal and teach-back

Assemble six cases into a bounded governance pack, distinguish expected trial evidence from observations and defend the real-service hold.

The capstone is a complete paper governance proposal for Lyra-Regional-Training, an invented regional carrier. Its governance-teaching purpose involves no actual customer, service or infrastructure. The decision sought is permission to examine a bounded synthetic proposal, with real release held. The following register supplies all six use cases, including cases whose descriptors identify unresolved authority before a source read. Consequences and dependencies are proposed review questions. Cases cannot borrow approval.

Provider applicability remains unresolved: identify the actual legal entity, public communications network/service role, relevant turnover period, micro-enterprise qualification, locations, recipients and any EU nexus. Reviewed uk-telecom-security-law is binding law; dsit-telecom-code-2026 is the July 2026 statutory technical code, with a different function. Code tiers differ from the Regulations' micro-enterprise exception. A stale accounting threshold in an older guidance footnote must not classify Lyra. The Ofcom resilience guidance is June 2026; do not treat its older code references as the current code. Actual classification remains open.

Use complete invented originals for the eligible drafts. T-01: Invented Lyra incident L-01: service advisory received; root cause not established. T-02: Invented Lyra FAQ: service status is not established; use the proposed human support route. T-03: Invented Lyra capacity sample; historical counts only. Preserve each case/source/revision and uncertainty. T-03's 60 busy intervals out of 200 give 30 percent historically. This does not predict load, spare capacity or service quality. Held descriptors do not become permitted evidence because the proposal lists them.

Scroll sideways to see every column.

Complete carrier governance proposal and teach-back · Table 12
Use case and sourceCurrent teaching decisionConsequence and dependency questions
T-01 outage-brief / case-01.jsonSynthetic internal analytical draft; root cause UNESTABLISHED.Consequence: misleading internal decisions if uncertainty disappears. Dependencies: advisory provenance, network-service owner, current review.
T-02 customer-faq / case-02.jsonSynthetic public analytical draft; status unestablished, route only proposed.Consequence: unsupported customer reassurance or inaccessible support. Dependencies: customer owner, actual route/access evidence, data review.
T-03 capacity-note / case-03.jsonSynthetic internal historical arithmetic: 60/200 = 30%.Consequence: false forecasting or capacity authority. Dependencies: count provenance, period description, network owner and scope.
T-04 fraud-review / case-04.jsonHOLD before read: source purpose and permission unresolved.Consequence: unfair inference or inappropriate data use if admitted. Dependencies: actual purpose/source/privacy and customer-authority review, absent here.
T-05 network-write / case-05.jsonHOLD before read: operational action excluded.Consequence: service-affecting change if analysis acquires control. Dependencies: actual operational authority, safety/security and change process, absent here.
T-06 emergency-path / case-06.jsonHOLD before read: actual safety and authority review absent.Consequence: serious safety/access impact if unsupported advice is followed. Dependencies: qualified real service and safety review, absent here.

The paper data-flow proposal is synthetic source to local analytical draft to separate reviews to copied training export. For an actual supplier, require evidence for every additional flow: hosting jurisdiction, subcontractors, support access, logs, retention, backups, training reuse, onward transfers and return/deletion. Original authority and supplier contract review remain open. The ICO principles source carries a DUAA review caveat; it does not select actual processing grounds, communications rules or transfer arrangements. Partial GSMA maturity guidance can organise questions, while amended EU applicability needs qualified current-text review; neither supplies approval.

An average instruction says Approve the outage assistant and chatbot once the sample looks right. An elite paper prompt has six components. Role: synthetic carrier governance proposal drafter. Constraints: six registered cases only, permitted analysis only, no real service or model, all uncertainty preserved. Process: map consequences/dependencies, source and provider questions, independent reviewers and continuity. Verification: check originals/revisions, exact arithmetic and current review layers. Output schema: case, draft/hold, source, consequence, owner, unresolved evidence, version and release decision. Failure modes: hold missing authority, changed sources, substituted reviewers, stale permissions and unsupported restoration promises. The prompt is a teaching artefact, not a model result.

Recorded author-runtime-evidence.json reports three ANALYTICAL_DRAFT results, three HOLD results and three controlled source-read attempts in its initial demo. This author execution is not independent acceptance, a model test or evidence about an actual carrier. Fresh execute/batch checks establish current eligible drafts. review_data uses the assumed training-data-owner; review_service separately uses the network owner for T-01/T-03 and customer owner for T-02. review_pilot requires all those current layers. Its SYNTHETIC_PILOT_PROPOSAL_ONLY outcome keeps actualReleaseDecision at HOLD_FOR_REAL_PROVIDER_REVIEW. Strings identify assumed roles, not authenticated people or legal authority.

A defect triggers the paper incident register and the permitted teaching stop. change_state by the assumed coordinator at the current exact version clears permissions, drafts, reviews and proposal when state changes. Resume advances version again; renew_permissions explicitly renews only eligible grants. Fresh source checks, data review, both service reviews and pilot review are required before export_proposal. A failed known retry also invalidates dependent evidence. Copied prior exports remain; a fresh process starts from original active version 1 without reviews. This is not durable suspension, identity assurance or supplier erasure.

Continuity proposals must serve customers who cannot use the chat interface and people whose preferred alternative shares an affected dependency. Offer an appropriate human/non-digital route selected through actual service and affected-user review; phone alone may be unusable. Keep status uncertainty and contact availability separate. Selected WCAG criteria help frame keyboard and status-message checks, but this pack has no assistive-technology, full-process or user testing. No contact, response time, restoration, emergency path or customer remedy is implemented. Real service release remains held pending actual owner, legal, security, data, accessibility and service evidence.

Teach the proposal back in three minutes: why each draft is limited, why each held case stays excluded, who separately reviews it, and what would stop export. Challenge a removed customer review or changed source percentage and explain the hold. Capstone and written practice are ungraded. The twenty-question educational knowledge assessment requires strictly above 80 percent: 16/20 fails and 17/20 passes. Official assessment availability depends on the complete checked release. A named certificate records the knowledge assessment result, not professional qualification, identity assurance or provider acceptance.

Six cases, separate reviews, held real release

Eligible synthetic drafts pass distinct assumed review layers; three excluded cases remain held.

Six-case registerFresh source checksData reviewBoth service reviewsSynthetic proposal export
Steps
  • Six-case register: Three eligible analytical cases; three excluded descriptors.
  • Fresh source checks: Current grants, originals and historical arithmetic.
  • Data review: Assumed data owner; actual permissions unresolved.
  • Both service reviews: Network and customer owners remain separate.
  • Synthetic proposal export: Copied teaching export; actual release held.
Relationships and conditions
  1. Six-case register to Fresh source checks: Current evidence required
  2. Fresh source checks to Data review: Current evidence required
  3. Data review to Both service reviews: Current evidence required
  4. Both service reviews to Synthetic proposal export: Current evidence required

Text equivalent: List six cases, keeping three excluded cases held. Fresh eligible source checks precede an assumed data review. Separate network and customer reviews then support a synthetic pilot proposal. Export copies the teaching pack with real release held; a state change requires renewal and fresh evidence.

Try it yourself · Activity 08

60 minutes

Defend the six-case proposal at a paper review

A paper board asks for a live chatbot, access to T-04 and network-write rights because all three allowed drafts look correct. Present the supplied register and a bounded decision.

  1. Success criteria: retain all six cases and consequences/dependencies; three allowed drafts do not admit held cases.
  2. Name separate current data/network/customer reviews, supplier/jurisdiction/privacy gaps and stop/resume sequence.
  3. Provide accessible continuity questions and a held real-release decision without invented service or test evidence.

Which dependency would a customer-focused challenger question first, and why could accurate wording alone leave that person unsupported?

Worked answer

Accept only a synthetic analytical teaching proposal. Retain T-04/T-05/T-06 as before-read holds; useful drafts provide no fraud-data permission, network control or safety approval. Preserve T-01/T-02 uncertainty and T-03 historical 30 percent. Obtain current assumed data and separate network/customer reviews before pilot review/export; actual provider scope, source/vendor/privacy grounds, legal/security/service/user/access evidence remain unresolved. If evidence changes, stop, advance version, explicitly renew eligible grants and freshly check/review. Offer appropriate human/non-digital continuity for review, without assuming phone usability or a real route. Real release stays held.

Scroll sideways to see every column.

Complete carrier governance proposal and teach-back · Table 13
Chapter review questionAnswer after your attempt
Can the register admit T-04 simply to evaluate its usefulness?No. Its source purpose and permission are unresolved, so the initial boundary holds before reading.
What does 30 percent establish?Only the specified invented historical proportion, 60 of 200 intervals; no forecast or control authority.
Which review can substitute for customer-service review?None. Data and network reviews do not replace the distinct current customer-service review.
Does export_proposal authorise a carrier launch?No. It copies a synthetic training proposal while real release remains held.
What must follow resume before export?Explicit current renewal, fresh eligible source checks, data review, both service reviews and pilot review.
Does 16/20 pass the prospective knowledge draw?No. The threshold is strictly greater than 80 percent, so 17/20 passes; capstone performance is ungraded.

Apply what you learned · Practice

The synthetic proposal has every current assumed review. Which release statement follows?

Explanation and answer

A training export is available while real provider release remains held. The finite proposal/export never approves actual service release and excludes T-04/T-05/T-06.

Practice only. This does not count towards your exam or certificate.

Scroll sideways to see every column.

Complete carrier governance proposal and teach-back · Table 14
Further high-intent questionAnswer
Does sovereign control mean using a local server?Locality alone is insufficient. Demonstrated source, access, processing, contract, export and residual-copy choices matter. No live Mickai or supplier control is certified here.
Is the historical busy percentage a forecast?No. Sixty of two hundred invented historical intervals is 30 percent. The sample establishes no future load, spare capacity or actual network condition.
Can one service owner review all three drafts?The finite exercise requires distinct network and customer-service review roles in addition to data review. Assumed role strings are not authenticated authority.
Why record expected and observed trial results separately?A contract expectation is not execution evidence. Record actual fixture/version/source hashes and reported outcomes before claiming a measured result.
Does resuming Lyra restore old proposal approval?No. A changed state advances version and clears permissions and dependent evidence. Explicit renewal and fresh checks/reviews are needed. Prior copies are not erased.
Is a telephone route enough for every customer?No. Phone may be unusable or share the affected service dependency. Appropriate human/non-digital alternatives need actual service and affected-user review.
Is GSMA maturity guidance a regulatory approval?No. It is voluntary industry guidance, partially reviewed here. UK law/code and EU applicability have distinct status and require current qualified scope review.
Does passing the knowledge draw qualify someone to operate a network?No. Official educational assessment availability depends on the complete checked release. Strictly above 80 percent means 17/20 passes, but neither the knowledge result nor its certificate establishes professional qualification, operational authority or identity assurance; the capstone is ungraded.
text · 2 lines
python -B -m unittest -v test_lyra_lab.py
python -B lyra_lab.py

Scroll sideways to see every column.

Complete carrier governance proposal and teach-back · Table 15
Original exercise boundaryInterpretation
T-01 outage briefingInvented incident L-01; root cause UNESTABLISHED,repair not authorised. An analytical draft is not a live incident diagnosis.
T-02 customer FAQStatus unestablished and a proposed human route. No actual restoration,implemented support route or accessibility acceptance.
T-03 capacity noteHistorical synthetic sample:60 busy intervals out of200,30%. No forecast or measured carrier capacity.
T-04 fraud reviewSource purpose and permission unresolved; HOLD before reading.
T-05 network writeOperational authority excluded; HOLD before reading even when labelled analyse.
T-06 emergency pathActual safety and authority review absent; HOLD before reading. No routing or control instructions.
Distinct review layersAssumed data review precedes separate network/customer service-owner reviews and a fictional governance pilot review. Role strings do not authenticate people.
Stop and resumptionState changes invalidate permissions,drafts and all reviews. Resumption alone grants no permission; fresh checks and separate review required.
Bounded proposal exportReal-service release remains HOLD_FOR_REAL_PROVIDER_REVIEW. Export grants no operational authority and does not delete old copies.
New processOriginal version1 teaching state is restored in a new process; no durable revocation,account identity or security boundary.
text · 68 lines
# Lyra telecom governance teaching exercise

Lyra is an original offline Python standard-library exercise for adults. All six cases, carrier identifiers, service owners and source records are invented. It returns analytical text and aggregate drafts, followed by separate assumed review layers. It performs no AI inference, network change, customer processing, message transmission, emergency routing or real service release.

## Run the ten learner files

Keep `lyra_lab.py`, `test_lyra_lab.py`, `fixture.json`, this README and the six `sources/case-01.json` through `case-06.json` files together. With Python 3, run:

```text
python -B lyra_lab.py
python -B test_lyra_lab.py -v
```

No installation, provider account or connection is needed. The test suite uses the platform temporary directory and inherited subprocess environment. An optional `LYRA_TEST_TEMP` environment variable can select an existing test temporary directory. The creator sets TEMP and TMP to a directory on M externally; learners do not need that drive. Creator helpers, execution evidence and any later independent tests are outside the ten-file learner package. Other operating systems have not been actually exercised by the creator.

## Initial finite cases

| Case | Teaching input | Expected initial result |
| --- | --- | --- |
| T-01 | Invented outage advisory; root cause not established | ANALYTICAL_DRAFT |
| T-02 | Invented FAQ; status not established; proposed human support route | ANALYTICAL_DRAFT |
| T-03 | Invented historical capacity counts: 60 busy intervals out of 200 | ANALYTICAL_DRAFT; 30 percent |
| T-04 | Fraud descriptor with unresolved purpose and permission | HOLD before source read |
| T-05 | Network-change descriptor; operational action excluded | HOLD before source read |
| T-06 | Emergency descriptor; actual safety and authority review absent | HOLD before source read |

The initial demo attempts three controlled source reads. The counter measures attempted controlled reads, including a failed read in a modified test. It does not count a real network request. The capacity result describes these invented historical intervals; it is no forecast or instruction to add capacity.

## Keep review layers separate

The fixture contains the exact six-key envelopes. Only the three permitted `analyse` requests can produce drafts. Carrier, purpose, source mapping, current active version and a separate current permission are checked before source access. T-04, T-05 and T-06 remain excluded even when `analyse` is requested. Source identity, exact types, revision, original wording and arithmetic are checked after access. Notes are passive text, never commands or review authority, and are omitted from returned drafts.

The demo then executes the following order at version 1:

```python
from lyra_lab import Lyra, NETWORK_OWNER, CUSTOMER_OWNER
import json
from pathlib import Path

lab = Lyra()
requests = json.loads(Path("fixture.json").read_text(encoding="utf-8"))["requests"]
drafts = lab.batch(requests)
data = lab.review_data("training-data-owner", 1)
network = lab.review_service(NETWORK_OWNER, 1)   # T-01 and T-03
customer = lab.review_service(CUSTOMER_OWNER, 1) # T-02
pilot = lab.review_pilot("training-governance-reviewer", 1)
proposal = lab.export_proposal(1)
```

The data review needs all three fresh eligible drafts. Both service reviews need the current data review and their relevant drafts. Network and customer roles are different finite strings; the code does not authenticate people or establish independent human review. The governance review needs both current service reviews. Every export retains `HOLD_FOR_REAL_PROVIDER_REVIEW` for actual release, held cases and unresolved legal, data, safety, accessibility, service and supplier questions. Returning an export object writes no file and publishes nothing.

A valid repeated data review clears both service reviews and the pilot review, and advances its review sequence. Repeating one service review clears the pilot review. Every retry of a known case clears its stored verification and all review layers before its gates, including a held retry. Duplicate case IDs hold every occurrence before those repeated cases are read; other unique cases can still be checked. A permitted new check also requires fresh reviews.

## Stop, resume and current permissions

```python
lab.change_state("training-coordinator", 1, False) # version becomes 2
lab.change_state("training-coordinator", 2, True)  # version becomes 3
lab.renew_permissions("training-coordinator", 3)
```

Both state changes clear permissions, verification and reviews. Resume alone grants no permissions. Renewal restores only the original three analytical permissions; it grants no action rights or real approval. Rebuild envelopes with version 3, check the three eligible cases, then repeat every review layer with version 3. Wrong-role, malformed and stale mutators leave state unchanged. A same-state request reports NO_CHANGE.

Returned drafts, reviews and exports are deep copies. Changing a returned copy cannot change stored verification or original source files. Conversely, previously returned or saved copies are not revoked or deleted by a later stop. A fresh Python process starts again at the initial version and permissions: stop state is in memory and not durable. This is not an enforced secure store, provider control, operational safety system or authentication boundary.

## What remains outside this exercise

Every output explicitly keeps actual role authentication, independent human review, real legal applicability, repair authorisation, operational action, model calls, network activity, customer processing and real release approval false. No source establishes a root cause or authorises repair. A proposed FAQ route is not an implemented or user-tested support route. Actual provider scope, law, tier, data purpose, security, retention, dependencies, safety, restoration, customer communications, accessibility and release need qualified review for a real service. The finite review strings settle none of those questions.

json · 53 lines
{
  "syntheticOnly": true,
  "requests": [
    {
      "carrierId": "Lyra-Regional-Training",
      "caseId": "T-01",
      "sourceId": "case-01",
      "operation": "analyse",
      "purpose": "governance-teaching",
      "version": 1
    },
    {
      "carrierId": "Lyra-Regional-Training",
      "caseId": "T-02",
      "sourceId": "case-02",
      "operation": "analyse",
      "purpose": "governance-teaching",
      "version": 1
    },
    {
      "carrierId": "Lyra-Regional-Training",
      "caseId": "T-03",
      "sourceId": "case-03",
      "operation": "analyse",
      "purpose": "governance-teaching",
      "version": 1
    },
    {
      "carrierId": "Lyra-Regional-Training",
      "caseId": "T-04",
      "sourceId": "case-04",
      "operation": "analyse",
      "purpose": "governance-teaching",
      "version": 1
    },
    {
      "carrierId": "Lyra-Regional-Training",
      "caseId": "T-05",
      "sourceId": "case-05",
      "operation": "analyse",
      "purpose": "governance-teaching",
      "version": 1
    },
    {
      "carrierId": "Lyra-Regional-Training",
      "caseId": "T-06",
      "sourceId": "case-06",
      "operation": "analyse",
      "purpose": "governance-teaching",
      "version": 1
    }
  ]
}

python · 281 lines
"""Original Lyra analytical service-governance exercise; no live actions."""
import copy
import json
from pathlib import Path

CARRIER = "Lyra-Regional-Training"
PURPOSE = "governance-teaching"
NETWORK_OWNER = "training-network-service-owner"
CUSTOMER_OWNER = "training-customer-service-owner"
REQUEST_FIELDS = {"carrierId", "caseId", "sourceId", "operation", "purpose", "version"}
SOURCE_FIELDS = {"carrierId", "caseId", "sourceId", "revision", "risk", "original", "aggregate", "note"}
FLAGS = {"modelCalled": False, "networkTouched": False, "customerDataProcessed": False,
         "operationalActionAuthorised": False, "realServiceReleaseApproved": False,
         "repairAuthorised": False, "actualLegalApplicabilityApproved": False,
         "actualRoleAuthenticated": False, "independentHumanReviewVerified": False}
UNRESOLVED = [
    "Actual provider/entity/jurisdiction, public network/service role and applicable law",
    "Actual data purpose, customer rights, supplier use/logs/retention and data-law/PECR review",
    "Actual network dependencies, safety, service-owner authority and accountable stopping/restoration",
    "Actual customer messaging, support continuity, user/accessibility/AT verification",
    "Actual supplier/security evidence, pilot conditions and real service release decision",
]


def _source(number, risk, original, aggregate=None):
    return {"carrierId": CARRIER, "caseId": f"T-{number:02}", "sourceId": f"case-{number:02}",
            "revision": 1, "risk": risk, "original": original, "aggregate": aggregate,
            "note": "Invented analytical teaching source. No real service event."}


BASELINES = {
    "T-01": _source(1, "synthetic-internal", "Invented Lyra incident L-01: service advisory received; root cause not established."),
    "T-02": _source(2, "synthetic-public", "Invented Lyra FAQ: service status is not established; use the proposed human support route."),
    "T-03": _source(3, "synthetic-internal", "Invented Lyra capacity sample; historical counts only.",
                     {"totalIntervals": 200, "busyIntervals": 60, "busyPercent": 30}),
    "T-04": _source(4, "purpose-unresolved", "Invented Lyra fraud-input descriptor; source purpose and permission unresolved."),
    "T-05": _source(5, "operational-authority-excluded", "Invented Lyra network-change descriptor; operational action excluded."),
    "T-06": _source(6, "safety-review-unresolved", "Invented Lyra emergency-service descriptor; actual safety and authority review absent."),
}
CASE_OWNERS = {"T-01": NETWORK_OWNER, "T-02": CUSTOMER_OWNER, "T-03": NETWORK_OWNER,
               "T-04": CUSTOMER_OWNER, "T-05": NETWORK_OWNER, "T-06": NETWORK_OWNER}
REVIEW_CASES = {NETWORK_OWNER: ("T-01", "T-03"), CUSTOMER_OWNER: ("T-02",)}
ELIGIBLE = ("T-01", "T-02", "T-03")
EXCLUDED = ("T-04", "T-05", "T-06")
SOURCE_NAMES = {key: source["sourceId"] + ".json" for key, source in BASELINES.items()}


def exact(value, expected):
    return type(value) is type(expected) and value == expected


def hold(reason):
    return {"status": "HOLD", "reason": reason, "syntheticOnly": True, **FLAGS}


def unique_object(pairs):
    result = {}
    for key, value in pairs:
        if key in result:
            raise ValueError("Repeated JSON member")
        result[key] = value
    return result


class Lyra:
    """Separate assumed review layers in mutable teaching memory, not authority."""

    def __init__(self):
        self.version = 1
        self.active = True
        self.permissions = {}
        self.verified = {}
        self.data_review = None
        self.service_reviews = {}
        self.pilot_review = None
        self.data_review_sequence = 0
        self.source_reads = 0
        self.audit = []
        self._source_dir = Path(__file__).resolve().parent / "sources"
        self._issue_permissions()

    def _permission(self, key):
        return {"carrierId": CARRIER, "sourceId": BASELINES[key]["sourceId"],
                "operation": "analyse", "purpose": PURPOSE, "version": self.version}

    def _issue_permissions(self):
        self.permissions = {key: self._permission(key) for key in ELIGIBLE} if self.active else {}

    def _clear_reviews(self):
        self.data_review = None
        self.service_reviews.clear()
        self.pilot_review = None

    def _clear_retry(self, key):
        if type(key) is str and key in BASELINES:
            self.verified.pop(key, None)
            self._clear_reviews()

    def _current(self, version):
        return self.active and type(version) is int and version == self.version

    def _role(self, actor, expected, version):
        return type(actor) is str and actor == expected and self._current(version)

    def _drafts_current(self, keys):
        return all(key in self.verified and exact(self.verified[key]["version"], self.version) for key in keys)

    def _data_current(self):
        return self.data_review is not None and exact(self.data_review["version"], self.version)

    def _gate(self, request):
        if type(request) is not dict or set(request) != REQUEST_FIELDS:
            return "Exact analytical request fields required"
        if any(type(request[field]) is not str for field in REQUEST_FIELDS - {"version"}):
            return "Exact request string types required"
        key = request["caseId"]
        if key not in BASELINES:
            return "Unknown fictional service case"
        if not self._current(request["version"]):
            return "Active exact current policy version required"
        if request["operation"] != "analyse":
            return "Only analytical drafts permitted; operational and sending actions excluded"
        if key not in ELIGIBLE:
            return "Fraud, network-write and emergency cases excluded before reads"
        for field, expected in [("carrierId", CARRIER), ("purpose", PURPOSE), ("sourceId", BASELINES[key]["sourceId"])]:
            if request[field] != expected:
                return "Code-owned carrier/purpose/source binding required"
        permit = self.permissions.get(key)
        expected = self._permission(key)
        if type(permit) is not dict or set(permit) != set(expected):
            return "Separate exact source permission required"
        if any(not exact(permit[field], value) for field, value in expected.items()):
            return "Current separate source permission binding required"
        return None

    def _validate_source(self, key, source):
        if type(source) is not dict or set(source) != SOURCE_FIELDS:
            return False
        gold = BASELINES[key]
        if any(not exact(source[field], gold[field]) for field in SOURCE_FIELDS - {"aggregate", "note"}):
            return False
        if type(source["note"]) is not str or len(source["note"]) > 2000:
            return False
        if key != "T-03":
            return source["aggregate"] is None
        data = source["aggregate"]
        if type(data) is not dict or set(data) != {"totalIntervals", "busyIntervals", "busyPercent"}:
            return False
        if any(type(value) is not int for value in data.values()) or data != gold["aggregate"]:
            return False
        return data["totalIntervals"] > 0 and 0 <= data["busyIntervals"] <= data["totalIntervals"] and data["busyIntervals"] * 100 == data["busyPercent"] * data["totalIntervals"]

    def execute(self, request):
        key = request.get("caseId") if type(request) is dict else None
        self._clear_retry(key)
        reason = self._gate(request)
        if reason:
            return hold(reason)
        try:
            self.source_reads += 1
            source = json.loads((self._source_dir / SOURCE_NAMES[key]).read_text(encoding="utf-8"), object_pairs_hook=unique_object)
        except (OSError, UnicodeError, ValueError, RecursionError):
            return hold("Controlled teaching source could not be decoded as valid JSON")
        if not self._validate_source(key, source):
            return hold("Source shape/provenance/original or historical synthetic counts mismatch")
        result = {"status": "ANALYTICAL_DRAFT", "carrierId": CARRIER, "caseId": key,
                  "sourceId": source["sourceId"], "sourceRevision": source["revision"],
                  "risk": source["risk"], "owner": CASE_OWNERS[key], "version": self.version,
                  "purpose": PURPOSE, "operation": "analyse", "original": source["original"],
                  "aggregate": copy.deepcopy(source["aggregate"]), "syntheticOnly": True,
                  "rootCause": "UNESTABLISHED", **FLAGS}
        self.verified[key] = copy.deepcopy(result)
        self.audit.append({"action": "analytical-draft", "caseId": key, "version": self.version})
        return copy.deepcopy(result)

    def batch(self, requests):
        if type(requests) is not list:
            return [hold("Batch requires an exact list of request objects")]
        counts = {}
        for request in requests:
            key = request.get("caseId") if type(request) is dict else None
            if type(key) is str:
                counts[key] = counts.get(key, 0) + 1
        repeated = {key for key, count in counts.items() if count > 1}
        for key in repeated:
            self._clear_retry(key)
        return [hold("Every repeated case denied before source reads")
                if type(request) is dict and type(request.get("caseId")) is str and request["caseId"] in repeated
                else self.execute(request) for request in requests]

    def change_state(self, actor, version, active):
        if type(actor) is not str or actor != "training-coordinator" or type(version) is not int or version != self.version or type(active) is not bool:
            return hold("Current assumed coordinator and exact boolean state required")
        if active == self.active:
            return {"status": "NO_CHANGE", "version": self.version, "active": self.active, **FLAGS}
        self.active = active
        self.version += 1
        self.permissions.clear()
        self.verified.clear()
        self._clear_reviews()
        self.audit.append({"action": "change-state", "version": self.version, "active": active})
        return {"status": "TRAINING_STATE_CHANGED", "version": self.version, "active": active,
                "priorCopiesErased": False, "sourceDiskChanged": False, **FLAGS}

    def renew_permissions(self, actor, version):
        if not self._role(actor, "training-coordinator", version):
            return hold("Active current assumed coordinator required to renew")
        self._issue_permissions()
        self.audit.append({"action": "renew-analytical-permissions", "version": self.version})
        return {"status": "TRAINING_ANALYTICAL_PERMISSIONS_RENEWED", "version": self.version,
                "eligibleCaseIds": list(ELIGIBLE), "excludedCaseIds": list(EXCLUDED), **FLAGS}

    def review_data(self, actor, version):
        if not self._role(actor, "training-data-owner", version) or not self._drafts_current(ELIGIBLE):
            return hold("Assumed current data owner and all three current analytical drafts required")
        self.data_review_sequence += 1
        self.service_reviews.clear()
        self.pilot_review = None
        self.data_review = {"status": "ASSUMED_DATA_REVIEW_ONLY", "role": actor,
                            "version": self.version, "dataReviewSequence": self.data_review_sequence,
                            "caseIds": list(ELIGIBLE), "syntheticOnly": True,
                            "unresolvedItems": [UNRESOLVED[0], UNRESOLVED[1], UNRESOLVED[4]], **FLAGS}
        return copy.deepcopy(self.data_review)

    def review_service(self, actor, version):
        if type(actor) is not str or actor not in REVIEW_CASES or not self._current(version) or not self._data_current():
            return hold("Current distinct assumed service owner and prior current data review required")
        keys = REVIEW_CASES[actor]
        if not self._drafts_current(keys):
            return hold("All relevant current analytical drafts required for this service owner")
        self.pilot_review = None
        review = {"status": "ASSUMED_SERVICE_REVIEW_ONLY", "role": actor, "version": self.version,
                  "dataReviewSequence": self.data_review["dataReviewSequence"], "caseIds": list(keys),
                  "scope": "Analytical draft scope only; no network or customer action rights",
                  "syntheticOnly": True, "rootCause": "UNESTABLISHED",
                  "unresolvedItems": [UNRESOLVED[2] if actor == NETWORK_OWNER else UNRESOLVED[3], UNRESOLVED[4]], **FLAGS}
        self.service_reviews[actor] = copy.deepcopy(review)
        return copy.deepcopy(review)

    def review_pilot(self, actor, version):
        if not self._role(actor, "training-governance-reviewer", version) or not self._drafts_current(ELIGIBLE) or not self._data_current():
            return hold("Current assumed governance reviewer, all drafts and data review required")
        for owner in REVIEW_CASES:
            review = self.service_reviews.get(owner)
            if review is None or not exact(review["version"], self.version) or review["dataReviewSequence"] != self.data_review["dataReviewSequence"]:
                return hold("Both distinct current network and customer draft reviews required")
        self.pilot_review = {"status": "SYNTHETIC_PILOT_PROPOSAL_ONLY", "carrierId": CARRIER,
                             "version": self.version, "dataReviewSequence": self.data_review["dataReviewSequence"],
                             "reviewedCaseIds": list(ELIGIBLE), "excludedCaseIds": list(EXCLUDED),
                             "actualReleaseDecision": "HOLD_FOR_REAL_PROVIDER_REVIEW",
                             "unresolvedItems": list(UNRESOLVED), "syntheticOnly": True, **FLAGS}
        return copy.deepcopy(self.pilot_review)

    def export_proposal(self, version):
        if not self._current(version) or self.pilot_review is None or not exact(self.pilot_review["version"], self.version):
            return hold("Active exact current complete synthetic pilot review required before export")
        return copy.deepcopy({"status": "LYRA_TRAINING_EXPORT", "carrierId": CARRIER,
                              "version": self.version, "draftRecords": [self.verified[key] for key in ELIGIBLE],
                              "assumedDataReview": self.data_review,
                              "assumedServiceReviews": [self.service_reviews[owner] for owner in REVIEW_CASES],
                              "pilotReview": self.pilot_review, "heldCaseIds": list(EXCLUDED),
                              "unresolvedItems": list(UNRESOLVED), "syntheticOnly": True,
                              "actualReleaseDecision": "HOLD_FOR_REAL_PROVIDER_REVIEW", **FLAGS})


def demo():
    lab = Lyra()
    fixture = json.loads((Path(__file__).resolve().parent / "fixture.json").read_text(encoding="utf-8"))
    results = lab.batch(fixture["requests"])
    data = lab.review_data("training-data-owner", 1)
    network = lab.review_service(NETWORK_OWNER, 1)
    customer = lab.review_service(CUSTOMER_OWNER, 1)
    pilot = lab.review_pilot("training-governance-reviewer", 1)
    return {"cases": results, "sourceReads": lab.source_reads, "dataReview": data,
            "networkReview": network, "customerReview": customer, "pilotReview": pilot,
            "export": lab.export_proposal(1),
            "scope": "Synthetic analytical drafts and assumed separate review layers only; no model/network/customer action or real service release."}


if __name__ == "__main__":
    print(json.dumps(demo(), indent=2))

python · 383 lines
"""Original Lyra author-suite: analytical boundaries and separate review layers."""
import copy
import json
import os
from pathlib import Path
import shutil
import subprocess
import tempfile
import unittest
from collections import Counter
from lyra_lab import Lyra, BASELINES, SOURCE_NAMES, CARRIER, PURPOSE, NETWORK_OWNER, CUSTOMER_OWNER, demo

HERE = Path(__file__).resolve().parent
TEMP_ROOT = os.environ.get("LYRA_TEST_TEMP") or tempfile.gettempdir()


def request(key="T-01", version=1, **changes):
    value = {"carrierId": CARRIER, "caseId": key, "sourceId": BASELINES[key]["sourceId"],
             "operation": "analyse", "purpose": PURPOSE, "version": version}
    value.update(changes)
    return value


class LyraTests(unittest.TestCase):
    def setUp(self):
        self.temp = tempfile.TemporaryDirectory(prefix="lyra-author-", dir=TEMP_ROOT)
        self.sources = Path(self.temp.name) / "sources"
        shutil.copytree(HERE / "sources", self.sources)
        self.lab = Lyra()
        self.lab._source_dir = self.sources  # Private test-only substitution, never caller API.

    def tearDown(self):
        self.temp.cleanup()

    def write(self, key, value):
        (self.sources / SOURCE_NAMES[key]).write_text(json.dumps(value), encoding="utf-8")

    def drafts(self):
        return [self.lab.execute(request(key, self.lab.version)) for key in ["T-01", "T-02", "T-03"]]

    def data(self):
        self.drafts()
        result = self.lab.review_data("training-data-owner", self.lab.version)
        self.assertEqual(result["status"], "ASSUMED_DATA_REVIEW_ONLY")
        return result

    def reviewed(self):
        self.data()
        self.lab.review_service(NETWORK_OWNER, self.lab.version)
        self.lab.review_service(CUSTOMER_OWNER, self.lab.version)
        self.assertEqual(self.lab.review_pilot("training-governance-reviewer", self.lab.version)["status"], "SYNTHETIC_PILOT_PROPOSAL_ONLY")
        return self.lab.export_proposal(self.lab.version)

    def snapshot(self):
        return copy.deepcopy((self.lab.version, self.lab.active, self.lab.permissions,
                              self.lab.verified, self.lab.data_review, self.lab.service_reviews,
                              self.lab.pilot_review, self.lab.data_review_sequence, self.lab.audit))

    def test_initial_six_cases_three_drafts_three_holds_three_reads(self):
        result = self.lab.batch(json.loads((HERE / "fixture.json").read_text())["requests"])
        self.assertEqual(Counter(x["status"] for x in result), {"ANALYTICAL_DRAFT": 3, "HOLD": 3})
        self.assertEqual(self.lab.source_reads, 3)
        self.assertEqual([x["caseId"] for x in result if x["status"] == "ANALYTICAL_DRAFT"], ["T-01", "T-02", "T-03"])

    def test_original_uncertainty_and_historical_counts_preserved(self):
        results = self.drafts()
        self.assertEqual(results[0]["original"], "Invented Lyra incident L-01: service advisory received; root cause not established.")
        self.assertIn("service status is not established", results[1]["original"])
        self.assertEqual(results[2]["aggregate"], {"totalIntervals": 200, "busyIntervals": 60, "busyPercent": 30})
        self.assertEqual(60 * 100, 30 * 200)
        self.assertTrue(all(x["rootCause"] == "UNESTABLISHED" and x["repairAuthorised"] is False for x in results))

    def test_excluded_cases_hold_before_io_even_if_missing(self):
        for key in ["T-04", "T-05", "T-06"]:
            (self.sources / SOURCE_NAMES[key]).unlink()
            self.assertEqual(self.lab.execute(request(key))["status"], "HOLD")
        self.assertEqual(self.lab.source_reads, 0)

    def test_operational_send_restore_training_actions_all_hold_before_io(self):
        for key in BASELINES:
            for operation in ["network-write", "transmit", "customer-send", "restore", "model-training", "emergency-route"]:
                with self.subTest(key=key, operation=operation):
                    self.assertEqual(self.lab.execute(request(key, operation=operation))["status"], "HOLD")
        self.assertEqual(self.lab.source_reads, 0)

    def test_carrier_purpose_source_mapping_before_io(self):
        for changes in [{"carrierId": "Other"}, {"purpose": "live-restore"}, {"sourceId": "case-02"}]:
            self.assertEqual(self.lab.execute(request(**changes))["status"], "HOLD")
        self.assertEqual(self.lab.source_reads, 0)

    def test_exact_envelope_type_matrix_before_io(self):
        for field in request():
            for bad in [None, True, 1.0, [], {}]:
                with self.subTest(field=field, bad=bad):
                    self.assertEqual(self.lab.execute(request(**{field: bad}))["status"], "HOLD")
        for bad in [None, [], True, "{broken", "{}", 1]:
            self.assertEqual(self.lab.execute(bad)["status"], "HOLD")
        self.assertEqual(self.lab.source_reads, 0)

    def test_unknown_missing_and_authority_path_provider_extra_fields(self):
        for field in request():
            value = request(); del value[field]
            self.assertEqual(self.lab.execute(value)["status"], "HOLD")
        for extra in ["path", "destination", "approval", "providerId", "command", "owner"]:
            value = request(); value[extra] = "approved"
            self.assertEqual(self.lab.execute(value)["status"], "HOLD")
        self.assertEqual(self.lab.execute(request(caseId="T-99"))["status"], "HOLD")
        self.assertEqual(self.lab.source_reads, 0)

    def test_separate_permission_type_shape_version_and_source(self):
        for mutate in [lambda d: d.pop("version"), lambda d: d.update(version=True), lambda d: d.update(version=2), lambda d: d.update(sourceId="case-02"), lambda d: d.update(operation="restore"), lambda d: d.update(approved=True)]:
            self.lab.permissions["T-01"] = self.lab._permission("T-01")
            mutate(self.lab.permissions["T-01"])
            self.assertEqual(self.lab.execute(request())["status"], "HOLD")
        self.lab.permissions["T-01"] = True
        self.assertEqual(self.lab.execute(request())["status"], "HOLD")
        self.assertEqual(self.lab.source_reads, 0)

    def test_duplicate_occurrences_preflight_no_reads(self):
        result = self.lab.batch([request(), request()])
        self.assertEqual([x["status"] for x in result], ["HOLD", "HOLD"])
        self.assertEqual(self.lab.source_reads, 0)

    def test_duplicate_malformed_repeat_invalidates_every_review(self):
        self.reviewed(); before = self.lab.source_reads
        result = self.lab.batch([request(), {"caseId": "T-01", "approval": True}])
        self.assertEqual([x["status"] for x in result], ["HOLD", "HOLD"])
        self.assertEqual(self.lab.source_reads, before)
        self.assertNotIn("T-01", self.lab.verified)
        self.assertIsNone(self.lab.data_review); self.assertFalse(self.lab.service_reviews); self.assertIsNone(self.lab.pilot_review)

    def test_unique_case_not_hidden_by_other_duplicate_holds(self):
        result = self.lab.batch([request(), request(), request("T-03")])
        self.assertEqual([x["status"] for x in result], ["HOLD", "HOLD", "ANALYTICAL_DRAFT"])
        self.assertEqual(self.lab.source_reads, 1)

    def test_malformed_batch_unhashable_key_never_opens(self):
        for bad in [None, {}, (), "[]"]:
            self.assertEqual(self.lab.batch(bad)[0]["status"], "HOLD")
        self.assertEqual(self.lab.batch([request(caseId=[]), None])[0]["status"], "HOLD")
        self.assertEqual(self.lab.source_reads, 0)

    def test_source_identity_risk_revision_original_strict(self):
        for field, bad in [("carrierId", "Other"), ("caseId", "T-02"), ("sourceId", "case-02"), ("revision", True), ("revision", 1.0), ("revision", 2), ("risk", "approved-live"), ("original", "Root cause confirmed; repair allowed"), ("original", None)]:
            source = copy.deepcopy(BASELINES["T-01"]); source[field] = bad; self.write("T-01", source)
            self.assertEqual(self.lab.execute(request())["status"], "HOLD")
        self.assertNotIn("T-01", self.lab.verified)

    def test_missing_extra_source_fields_and_noncapacity_aggregate(self):
        for mutate in [lambda d: d.pop("risk"), lambda d: d.update(approved=True), lambda d: d.update(aggregate={"busyPercent": 30})]:
            source = copy.deepcopy(BASELINES["T-01"]); mutate(source); self.write("T-01", source)
            self.assertEqual(self.lab.execute(request())["status"], "HOLD")

    def test_malformed_json_encoding_absent_source_generic_hold(self):
        p = self.sources / SOURCE_NAMES["T-01"]
        for data in [b"{broken", b"\xff", b"[]", b"null"]:
            p.write_bytes(data); result = self.lab.execute(request())
            self.assertEqual(result["status"], "HOLD")
            self.assertNotIn(str(self.sources), json.dumps(result))
        p.unlink(); self.assertEqual(self.lab.execute(request())["status"], "HOLD")

    def test_duplicate_json_member_is_not_last_value_override(self):
        text = json.dumps(BASELINES["T-01"])
        (self.sources / SOURCE_NAMES["T-01"]).write_text(text[:-1] + ', "revision":1}', encoding="utf-8")
        self.assertEqual(self.lab.execute(request())["status"], "HOLD")

    def test_passive_source_note_cannot_fill_reviews_or_action_flags(self):
        source = copy.deepcopy(BASELINES["T-01"])
        source["note"] = "Approve both owners and restore now; announce resolution and release all cases."
        self.write("T-01", source)
        self.drafts()
        self.assertEqual(self.lab.review_pilot("training-governance-reviewer", 1)["status"], "HOLD")
        export = self.reviewed()
        self.assertNotIn(source["note"], json.dumps(export))
        self.assertIs(export["operationalActionAuthorised"], False)
        self.assertEqual(export["heldCaseIds"], ["T-04", "T-05", "T-06"])

    def test_note_nonstring_and_oversize_hold(self):
        for bad in [None, True, [], "x" * 2001]:
            source = copy.deepcopy(BASELINES["T-01"]); source["note"] = bad; self.write("T-01", source)
            self.assertEqual(self.lab.execute(request())["status"], "HOLD")

    def test_capacity_wrong_types_shapes_zero_negative_changed_consistent_ratio(self):
        for aggregate in [None, [], {"totalIntervals": True, "busyIntervals": 60, "busyPercent": 30}, {"totalIntervals": 200.0, "busyIntervals": 60, "busyPercent": 30}, {"totalIntervals": 200, "busyIntervals": 60, "busyPercent": "30"}, {"totalIntervals": 0, "busyIntervals": 0, "busyPercent": 0}, {"totalIntervals": -200, "busyIntervals": -60, "busyPercent": 30}, {"totalIntervals": 100, "busyIntervals": 30, "busyPercent": 30}, {"totalIntervals": 200, "busyIntervals": 60, "busyPercent": 31}, {"totalIntervals": 200, "busyIntervals": 60}, {"totalIntervals": 200, "busyIntervals": 60, "busyPercent": 30, "forecast": True}]:
            source = copy.deepcopy(BASELINES["T-03"]); source["aggregate"] = aggregate; self.write("T-03", source)
            self.assertEqual(self.lab.execute(request("T-03"))["status"], "HOLD")

    def test_data_review_requires_all_three_current_drafts(self):
        self.lab.execute(request()); self.lab.execute(request("T-02"))
        self.assertEqual(self.lab.review_data("training-data-owner", 1)["status"], "HOLD")
        self.lab.execute(request("T-03"))
        self.assertEqual(self.lab.review_data("training-data-owner", 1)["status"], "ASSUMED_DATA_REVIEW_ONLY")

    def test_data_wrong_role_stale_boolean_float_version_cannot_approve(self):
        self.drafts()
        for actor, version in [(NETWORK_OWNER, 1), (CUSTOMER_OWNER, 1), (True, 1), ("training-data-owner", True), ("training-data-owner", 1.0), ("training-data-owner", 0)]:
            self.assertEqual(self.lab.review_data(actor, version)["status"], "HOLD")
            self.assertIsNone(self.lab.data_review)

    def test_service_reviews_cannot_precede_data_review(self):
        self.drafts()
        for owner in [NETWORK_OWNER, CUSTOMER_OWNER]:
            self.assertEqual(self.lab.review_service(owner, 1)["status"], "HOLD")
        self.assertFalse(self.lab.service_reviews)

    def test_network_and_customer_cases_are_distinct_and_independent(self):
        self.data()
        network = self.lab.review_service(NETWORK_OWNER, 1)
        self.assertEqual(network["caseIds"], ["T-01", "T-03"])
        self.assertEqual(self.lab.review_pilot("training-governance-reviewer", 1)["status"], "HOLD")
        customer = self.lab.review_service(CUSTOMER_OWNER, 1)
        self.assertEqual(customer["caseIds"], ["T-02"])
        self.assertEqual(self.lab.review_pilot("training-governance-reviewer", 1)["status"], "SYNTHETIC_PILOT_PROPOSAL_ONLY")

    def test_customer_only_cannot_substitute_network_review(self):
        self.data(); self.lab.review_service(CUSTOMER_OWNER, 1)
        self.lab.review_service(CUSTOMER_OWNER, 1)
        self.assertEqual(self.lab.review_pilot("training-governance-reviewer", 1)["status"], "HOLD")
        self.assertNotIn(NETWORK_OWNER, self.lab.service_reviews)

    def test_service_unknown_data_governance_wrong_types_roles_cannot_fill_layer(self):
        self.data()
        for actor, version in [("training-data-owner", 1), ("training-governance-reviewer", 1), ("training-network-service-owner/customer", 1), ([], 1), (NETWORK_OWNER, True), (CUSTOMER_OWNER, 0)]:
            self.assertEqual(self.lab.review_service(actor, version)["status"], "HOLD")
            self.assertFalse(self.lab.service_reviews)

    def test_pilot_cannot_precede_or_substitute_owners(self):
        self.drafts()
        self.assertEqual(self.lab.review_pilot("training-governance-reviewer", 1)["status"], "HOLD")
        self.lab.review_data("training-data-owner", 1)
        self.assertEqual(self.lab.review_pilot("training-governance-reviewer", 1)["status"], "HOLD")
        self.lab.review_service(NETWORK_OWNER, 1); self.lab.review_service(CUSTOMER_OWNER, 1)
        for actor, version in [(NETWORK_OWNER, 1), (CUSTOMER_OWNER, 1), ("training-data-owner", 1), ("training-governance-reviewer", True), ("training-governance-reviewer", 0)]:
            self.assertEqual(self.lab.review_pilot(actor, version)["status"], "HOLD")
        self.assertIsNone(self.lab.pilot_review)

    def test_complete_pipeline_release_stays_held_no_real_actions(self):
        export = self.reviewed()
        self.assertEqual(export["actualReleaseDecision"], "HOLD_FOR_REAL_PROVIDER_REVIEW")
        self.assertEqual(len(export["assumedServiceReviews"]), 2)
        self.assertEqual(export["heldCaseIds"], ["T-04", "T-05", "T-06"])
        for value in [export, export["assumedDataReview"], *export["assumedServiceReviews"], export["pilotReview"], *export["draftRecords"]]:
            for field in ["modelCalled", "networkTouched", "customerDataProcessed", "operationalActionAuthorised", "realServiceReleaseApproved", "repairAuthorised", "actualLegalApplicabilityApproved", "actualRoleAuthenticated", "independentHumanReviewVerified"]:
                self.assertIs(value[field], False)

    def test_export_requires_current_complete_pilot_review(self):
        self.drafts(); self.assertEqual(self.lab.export_proposal(1)["status"], "HOLD")
        self.lab.review_data("training-data-owner", 1); self.assertEqual(self.lab.export_proposal(1)["status"], "HOLD")
        self.lab.review_service(NETWORK_OWNER, 1); self.lab.review_service(CUSTOMER_OWNER, 1)
        self.assertEqual(self.lab.export_proposal(1)["status"], "HOLD")
        self.lab.review_pilot("training-governance-reviewer", 1)
        for bad in [True, 1.0, "1", None, 0, 2]:
            self.assertEqual(self.lab.export_proposal(bad)["status"], "HOLD")

    def test_fresh_data_review_invalidates_both_owners_and_pilot(self):
        self.reviewed(); first = self.lab.data_review["dataReviewSequence"]
        self.lab.review_data("training-data-owner", 1)
        self.assertGreater(self.lab.data_review["dataReviewSequence"], first)
        self.assertFalse(self.lab.service_reviews); self.assertIsNone(self.lab.pilot_review)
        self.assertEqual(self.lab.export_proposal(1)["status"], "HOLD")

    def test_repeat_service_review_requires_new_pilot_without_erasing_other_owner(self):
        self.reviewed(); self.lab.review_service(NETWORK_OWNER, 1)
        self.assertIn(CUSTOMER_OWNER, self.lab.service_reviews)
        self.assertIsNone(self.lab.pilot_review)
        self.assertEqual(self.lab.export_proposal(1)["status"], "HOLD")
        self.assertEqual(self.lab.review_pilot("training-governance-reviewer", 1)["status"], "SYNTHETIC_PILOT_PROPOSAL_ONLY")

    def test_returned_preview_and_all_review_layers_are_nested_copies(self):
        self.drafts(); draft = self.lab.execute(request("T-03")); draft["aggregate"]["busyPercent"] = 90
        self.assertEqual(self.lab.verified["T-03"]["aggregate"]["busyPercent"], 30)
        data = self.lab.review_data("training-data-owner", 1); data["caseIds"].clear(); data["unresolvedItems"].clear()
        network = self.lab.review_service(NETWORK_OWNER, 1); network["caseIds"].append("T-05"); network["operationalActionAuthorised"] = True
        self.lab.review_service(CUSTOMER_OWNER, 1)
        pilot = self.lab.review_pilot("training-governance-reviewer", 1); pilot["actualReleaseDecision"] = "RELEASE"; pilot["excludedCaseIds"].clear()
        export = self.lab.export_proposal(1)
        self.assertEqual(export["assumedDataReview"]["caseIds"], ["T-01", "T-02", "T-03"])
        self.assertEqual(export["assumedServiceReviews"][0]["caseIds"], ["T-01", "T-03"])
        self.assertIs(export["operationalActionAuthorised"], False)
        self.assertEqual(export["actualReleaseDecision"], "HOLD_FOR_REAL_PROVIDER_REVIEW")

    def test_export_nested_mutations_do_not_change_store_or_next_export(self):
        export = self.reviewed()
        export["draftRecords"][2]["aggregate"]["busyIntervals"] = 200
        export["assumedServiceReviews"][0]["caseIds"].append("T-05")
        export["assumedDataReview"]["unresolvedItems"].clear(); export["heldCaseIds"].clear()
        new = self.lab.export_proposal(1)
        self.assertEqual(new["draftRecords"][2]["aggregate"]["busyIntervals"], 60)
        self.assertEqual(new["heldCaseIds"], ["T-04", "T-05", "T-06"])
        self.assertTrue(new["assumedDataReview"]["unresolvedItems"])

    def test_failed_known_retry_before_io_clears_all_layers(self):
        self.reviewed(); before = self.lab.source_reads
        self.assertEqual(self.lab.execute(request(purpose="restore"))["status"], "HOLD")
        self.assertNotIn("T-01", self.lab.verified); self.assertIsNone(self.lab.data_review)
        self.assertFalse(self.lab.service_reviews); self.assertIsNone(self.lab.pilot_review)
        self.assertEqual(self.lab.source_reads, before)

    def test_failed_known_source_retry_cannot_reuse_old_success(self):
        self.reviewed(); source = copy.deepcopy(BASELINES["T-03"]); source["revision"] = 2; self.write("T-03", source)
        self.assertEqual(self.lab.execute(request("T-03"))["status"], "HOLD")
        self.assertNotIn("T-03", self.lab.verified)
        self.assertEqual(self.lab.export_proposal(1)["status"], "HOLD")
        self.assertIsNone(self.lab.data_review); self.assertFalse(self.lab.service_reviews)

    def test_excluded_known_retry_cannot_retain_prior_proposal(self):
        self.reviewed(); before = self.lab.source_reads
        self.assertEqual(self.lab.execute(request("T-06"))["status"], "HOLD")
        self.assertIsNone(self.lab.data_review); self.assertFalse(self.lab.service_reviews); self.assertIsNone(self.lab.pilot_review)
        self.assertEqual(self.lab.source_reads, before)

    def test_stop_invalidates_permissions_drafts_every_review_disk_and_old_copy_remain(self):
        old = self.reviewed(); disk = (self.sources / SOURCE_NAMES["T-01"]).read_bytes()
        result = self.lab.change_state("training-coordinator", 1, False)
        self.assertEqual(result["status"], "TRAINING_STATE_CHANGED"); self.assertEqual(self.lab.version, 2)
        self.assertFalse(self.lab.permissions); self.assertFalse(self.lab.verified); self.assertIsNone(self.lab.data_review)
        self.assertFalse(self.lab.service_reviews); self.assertIsNone(self.lab.pilot_review)
        self.assertEqual(old["version"], 1); self.assertEqual(len(old["draftRecords"]), 3)
        self.assertEqual((self.sources / SOURCE_NAMES["T-01"]).read_bytes(), disk)
        before = self.lab.source_reads
        self.assertEqual(self.lab.execute(request(version=2))["status"], "HOLD")
        self.assertEqual(self.lab.export_proposal(2)["status"], "HOLD")
        self.assertEqual(self.lab.source_reads, before)

    def test_resume_requires_renewal_fresh_drafts_and_separate_review_chain(self):
        self.reviewed(); self.lab.change_state("training-coordinator", 1, False)
        self.assertEqual(self.lab.renew_permissions("training-coordinator", 2)["status"], "HOLD")
        self.lab.change_state("training-coordinator", 2, True)
        self.assertEqual(self.lab.version, 3); self.assertFalse(self.lab.permissions)
        before = self.lab.source_reads
        self.assertEqual(self.lab.execute(request(version=3))["status"], "HOLD")
        self.assertEqual(self.lab.source_reads, before)
        self.lab.renew_permissions("training-coordinator", 3)
        self.assertEqual(self.lab.review_data("training-data-owner", 3)["status"], "HOLD")
        self.assertEqual(self.lab.review_pilot("training-governance-reviewer", 3)["status"], "HOLD")
        self.assertEqual(self.reviewed()["status"], "LYRA_TRAINING_EXPORT")

    def test_wrong_state_role_stale_bool_version_and_nonbool_active_do_not_mutate(self):
        self.reviewed(); before = self.snapshot()
        for args in [(NETWORK_OWNER, 1, False), ("training-coordinator", True, False), ("training-coordinator", 0, False)] + [("training-coordinator", 1, bad) for bad in [0, 1, None, "false", []]]:
            self.assertEqual(self.lab.change_state(*args)["status"], "HOLD")
            self.assertEqual(self.snapshot(), before)

    def test_same_state_is_no_change_and_does_not_erase_review(self):
        self.reviewed(); before = self.snapshot()
        self.assertEqual(self.lab.change_state("training-coordinator", 1, True)["status"], "NO_CHANGE")
        self.assertEqual(self.snapshot(), before)

    def test_renewal_wrong_role_or_version_does_not_mutate(self):
        self.reviewed(); before = self.snapshot()
        for actor, version in [(NETWORK_OWNER, 1), ("training-data-owner", 1), ("training-coordinator", True), ("training-coordinator", 1.0), ("training-coordinator", 0)]:
            self.assertEqual(self.lab.renew_permissions(actor, version)["status"], "HOLD")
            self.assertEqual(self.snapshot(), before)

    def test_renewal_only_original_analytical_rights_no_owner_approval(self):
        self.lab.permissions["T-05"] = self.lab._permission("T-05")
        self.lab.permissions["T-01"]["operation"] = "restore"
        result = self.lab.renew_permissions("training-coordinator", 1)
        self.assertEqual(result["eligibleCaseIds"], ["T-01", "T-02", "T-03"])
        self.assertNotIn("T-05", self.lab.permissions)
        self.assertEqual(self.lab.permissions["T-01"]["operation"], "analyse")
        self.assertIsNone(self.lab.data_review); self.assertFalse(self.lab.service_reviews); self.assertIsNone(self.lab.pilot_review)
        self.assertEqual(self.lab.source_reads, 0)

    def test_actual_separate_process_resets_stop_and_has_no_reviews(self):
        self.reviewed(); self.lab.change_state("training-coordinator", 1, False)
        code = "import json; from lyra_lab import Lyra; x=Lyra(); print(json.dumps({'version':x.version,'active':x.active,'permissions':list(x.permissions),'drafts':x.verified,'data':x.data_review,'services':x.service_reviews,'pilot':x.pilot_review,'reads':x.source_reads}))"
        result = subprocess.run(["python", "-B", "-c", code], cwd=HERE, env=os.environ.copy(), capture_output=True, text=True)
        self.assertEqual(result.returncode, 0, result.stderr)
        self.assertEqual(json.loads(result.stdout), {"version": 1, "active": True, "permissions": ["T-01", "T-02", "T-03"], "drafts": {}, "data": None, "services": {}, "pilot": None, "reads": 0})

    def test_demo_separate_layers_no_real_release(self):
        output = demo()
        self.assertEqual(output["sourceReads"], 3)
        self.assertEqual(output["dataReview"]["status"], "ASSUMED_DATA_REVIEW_ONLY")
        self.assertEqual(output["networkReview"]["caseIds"], ["T-01", "T-03"])
        self.assertEqual(output["customerReview"]["caseIds"], ["T-02"])
        self.assertEqual(output["pilotReview"]["actualReleaseDecision"], "HOLD_FOR_REAL_PROVIDER_REVIEW")
        self.assertIs(output["export"]["realServiceReleaseApproved"], False)


if __name__ == "__main__":
    unittest.main()

json · 10 lines
{
  "carrierId": "Lyra-Regional-Training",
  "caseId": "T-01",
  "sourceId": "case-01",
  "revision": 1,
  "risk": "synthetic-internal",
  "original": "Invented Lyra incident L-01: service advisory received; root cause not established.",
  "aggregate": null,
  "note": "Invented analytical teaching source. No real service event."
}

json · 10 lines
{
  "carrierId": "Lyra-Regional-Training",
  "caseId": "T-02",
  "sourceId": "case-02",
  "revision": 1,
  "risk": "synthetic-public",
  "original": "Invented Lyra FAQ: service status is not established; use the proposed human support route.",
  "aggregate": null,
  "note": "Invented analytical teaching source. No real service event."
}

json · 14 lines
{
  "carrierId": "Lyra-Regional-Training",
  "caseId": "T-03",
  "sourceId": "case-03",
  "revision": 1,
  "risk": "synthetic-internal",
  "original": "Invented Lyra capacity sample; historical counts only.",
  "aggregate": {
    "totalIntervals": 200,
    "busyIntervals": 60,
    "busyPercent": 30
  },
  "note": "Invented analytical teaching source. No real service event."
}

json · 10 lines
{
  "carrierId": "Lyra-Regional-Training",
  "caseId": "T-04",
  "sourceId": "case-04",
  "revision": 1,
  "risk": "purpose-unresolved",
  "original": "Invented Lyra fraud-input descriptor; source purpose and permission unresolved.",
  "aggregate": null,
  "note": "Invented analytical teaching source. No real service event."
}

json · 10 lines
{
  "carrierId": "Lyra-Regional-Training",
  "caseId": "T-05",
  "sourceId": "case-05",
  "revision": 1,
  "risk": "operational-authority-excluded",
  "original": "Invented Lyra network-change descriptor; operational action excluded.",
  "aggregate": null,
  "note": "Invented analytical teaching source. No real service event."
}

json · 10 lines
{
  "carrierId": "Lyra-Regional-Training",
  "caseId": "T-06",
  "sourceId": "case-06",
  "revision": 1,
  "risk": "safety-review-unresolved",
  "original": "Invented Lyra emergency-service descriptor; actual safety and authority review absent.",
  "aggregate": null,
  "note": "Invented analytical teaching source. No real service event."
}

Assessment options

Keep learning

The complete workbook

Eight substantial chapters with original telecoms illustrations,eight accessible diagrams,worked cases,exercises,reflection and forty mapped questions. An original offline six-case lab preserves uncertainty,excludes network writes and separates data,service-owner and governance review. The capstone is a complete fictional governance proposal,not a live-service authorisation.

  1. 01
    Six uses, service dependencies and accountable inventory

    Describe the decision and its service consequences before assigning an AI label, owner or permission.

    Read here · 1 exercise
  2. 02
    Outage uncertainty, customer impact and resilience

    Keep observed fictional facts, interpretation, arithmetic and recovery uncertainty separate when drafting a service briefing.

    Read here · 1 exercise
  3. 03
    Provider roles, jurisdiction and dated evidence

    Build an applicability register that identifies the actual entity and activity before using laws, codes or industry frameworks.

    Read here · 1 exercise
  4. 04
    Separate approvals, analytical authority and stopping

    Use distinct data and affected-service reviews, then explain what stopping and resuming a teaching proposal actually changes.

    Read here · 1 exercise
  5. 05
    Data, source and supplier boundaries

    Bind analytical assistance to a permitted source and purpose. Examine supplier reuse, logs and exit separately from a correct service draft or a fictional permission label.

    Read here · 1 exercise
  6. 06
    Trial design, quantitative checks and reproducible challenge

    Test analytical boundaries and uncertainty with invented cases. Recompute historical capacity, challenge reviews independently and avoid treating fixture success as model or service acceptance.

    Read here · 1 exercise
  7. 07
    Incident escalation, customer continuity and accountable monitoring

    Plan who challenges and stops an analytical proposal. Preserve customer uncertainty, usable non-chat routes and evidence for actual service owners without issuing operational restoration advice.

    Read here · 1 exercise
  8. 08
    Complete carrier governance proposal and teach-back

    Assemble six cases into a bounded governance pack, distinguish expected trial evidence from observations and defend the real-service hold.

    Read here · 1 exercise

Also inside: a 10-point checklist, a glossary of 10 terms and 12 questions and answers to test yourself. 8 hands-on exercises, each with a worked answer at the back where the workbook gives one.

The PDF is free. We ask for your name and email before downloading. Read the privacy notice at the download form. Free to download and use for personal learning, study groups and inside your own team. Please do not resell the workbooks or republish them as your own. Link people to trust-agent.ai instead.

Get your free PDF workbook

Enter your name and email, then download the complete workbook. This form also works without JavaScript.

We privately record your name, email and request IP for this download. Read our privacy notice and retention policy.

Visit Mickai on LinkedIn

Newsletter confirmation does not affect your download. Following Mickai on LinkedIn is optional; this site does not verify followers.

Test yourself

Questions and answers

Why does Lyra need six inventory rows rather than one assistant entry?

Its uses influence different decisions, depend on different evidence and have different exclusions. Separate rows keep customer and network responsibilities visible.

Is a text-only use automatically low consequence?

No. A draft can mislead readers about cause, status, capacity or support. Assess how someone might rely on it, while keeping real risk classification open.

Does the initial three-draft split mean three services are approved?

No. It is the initial contract expectation for fictional analysis, alongside three holds and three reads. It establishes no deployed service, actual model result or legal approval.

What does the 30 percent capacity calculation mean?

It means 60 of the supplied 200 historical synthetic intervals were labelled busy. It does not measure affected customers, spare capacity, an outage probability or future performance.

Can the outage draft infer a likely cause to make the briefing useful?

The supplied cause is unestablished. A useful briefing names the missing evidence and reviewer rather than turning plausible interpretation into an incident fact.

Does the proposed human support route establish accessible service?

No. No route is implemented here. Actual access, escalation, browser, assistive-technology and user evidence remain separate service review questions.

Can regional or small select a UK provider tier or micro exemption?

No. Actual entity/service facts, relevant turnover and period, tier-change rules and the distinct statutory micro-entity test require qualified review. No stale accounting threshold is applied.

Are all EU AI obligations delayed by the July 2026 update?

No. The reviewed Commission material gives different application dates and describes changes, while amended legal-text retrieval remains unresolved. Determine actual territory, role and intended use through current qualified review.

Can data-owner review replace both service-owner reviews?

No. Current data review is a prerequisite, then network and customer owners review their separate allowed cases. Pilot-proposal review requires both perspectives and keeps real release held.

Does stopping Lyra recall old exports or enforce a durable real stop?

No. Previous copied exports and source files remain, and a fresh process resets original active state without approvals. Real revocation, restart and downstream notification require actual controls.

Can a correct carrier FAQ prove its data use was permitted?

No. Source purpose, access, supplier recipients and actual data duties need separate evidence. The fictional FAQ supplies none of those real approvals.

Can source notes authorise a new vendor purpose?

No. Notes are passive in the finite exercise, never privileged or exported. Actual supplier reuse needs its own scope and authority review.

Write as you go

My notes

Use this scratchpad for your own notes, working or answers as you read. Notes are saved in this browser on this device. Downloading makes a local copy; it does not send your notes to Mickai.

Learn → Practise → Demonstrate

Ready to put it into practice?

Take the scored exam when you feel ready. You do not need to download the workbook first. A score strictly above 80% earns a named, dated Mickai certificate with a verification page.

Take the official exam

Your name and email are collected at exam start. Certificates record an assessment result, not an accredited qualification or verified identity.

Learn the language

Key terms

Service owner
An accountable person for a defined service and its decisions; a fictional role string is not authenticated identity.
Analytical assistance
A bounded draft or analysis that does not itself authorise a network or customer action.
Operational authority
Actual permission to perform a service action,excluded from the Lyra lab.
Provider classification
A context-specific determination about the entity,services and applicable duties,not decided by a teaching case.
Commercial tier
A code scope category that must not be substituted for the statutory micro test.
Source currency
The date,version,retrieval limits and legal status needed to interpret a source.

6 of the workbook's 10 terms. The complete glossary is in the workbook.

Follow the evidence

Sources and checks

Facts last checked: .

These workbooks use AI assistance. See how the workbooks are made.

  1. Electronic Communications (Security Measures) Regulations 2022 and selected Communications Act provisionsUK legislation / The National Archives
  2. Telecommunications Security Code of Practice 2026, version 1.1Department for Science, Innovation and Technology
  3. Guidance for communications providers and general statement under section 105YOfcom
  4. Network and Service Resilience Guidance for Communications ProvidersOfcom
  5. Machine learning principles, version2.0National Cyber Security Centre
  6. GSMA Responsible AI Maturity RoadmapGSMA
  7. Artificial Intelligence Risk Management Framework, AI RMF1.0National Institute of Standards and Technology
  8. A guide to the data protection principlesInformation Commissioner's Office
  9. EU AI Act current application overview and July2026 Omnibus updateEuropean Commission / Directorate-General CONNECT
  10. Web Content Accessibility Guidelines2.2World Wide Web Consortium

Created by Mickarle Sean Junior Wagstaff-Irons - Micky Irons with the Mickai team. Published by Mickai LTD. Last updated 1 October 2026.

NextKeep going

Where to go next