Opening
Governing delegated AI action in Europe
PALO Framework
Technical discussion with the European AI Office
12 October 2026
- Fabrizio Degni
- Maria Cristina Paoletti
- Alessandro Simonetta
Explore PALO Frameworkwww.paloframework.orgExplore PALO Frameworkwww.paloframework.orgPresenters
Introducing the team
Fabrizio Degni
I am Chief of AI with over fifteen years of international experience in technology, digital transformation and governance.
I hold a Doctorate in Computer Science from the European Institute of Management & Technology and an Executive MBA from POLIMI Graduate School of Management. I am an ISO/IEC 42001 Lead Auditor and Implementer, with additional qualifications in quality management and data protection.
I serve as President of the Italy Chapter of the Global Council for Responsible AI and contribute to AI standardisation through UNINFO and IEEE working groups on ethics, privacy and trustworthy systems.
My research focuses on AI ethics, governance and human accountability, particularly in agentic and autonomous systems.
Maria Cristina Paoletti
I am a Coordinator at the Italian National Institute for Insurance against Accidents at Work and Occupational Diseases, working in the Pricing and Benefits Sector.
I am also a member of UNINFO, the Italian Standardisation Body for Information Technology and its Applications, where I participate in the ISO/IEC JTC 1/SC 7 Subcommittee on Software and Systems Engineering.
Since 2022, I have been a liaison officer with CEN-CENELEC JTC 21 and the UNI/CT 533 mirror committee for ISO/IEC JTC 42, supporting the implementation of European standards on Artificial Intelligence.
Alessandro Simonetta
I worked for 24 years at the Italian National Institute for Insurance against Accidents at Work and Occupational Diseases, and later I served as IT Director at the Italian Space Agency.
I have been teaching at Italian universities since 1999 as an adjunct professor. Currently, I hold the Chair of Computer Systems Architecture at the University of Rome Tor Vergata.
I have been an expert member of ISO/IEC SC 7 (Software and Systems Engineering) and SC 27 (Information Security), and I am currently active in SC 42 (Artificial Intelligence) and in CEN/CLC JTC 21.
Some of the papers I co-authored with Maria Cristina are cited in CEN/CLC TR 18115 and in ISO/IEC 5259-2.
I am also Chair of the Artificial Intelligence Committee at the Order of Engineers of Rome.
Presentation routes
Two routes through the evidence
Shared opening1–3 · Introductions and route selection
Full technical guide
49 slides · approx. 88 min
Start exploration: slide 4 → Finish: slide 49
- 4–10Problem, risk routes and legal baseline
- 11–31Enterprise integration, controls and code
- 32–40Oversight, bias profile, metrics and data quality
- 41–49Evaluation, institutional route and next steps
Assess implementation details, failure modes and evaluation design.
Executive route
23 slides · approx. 42 min
Start exploration: slide 4 → Finish: slide 49
- 4, 5, 8–10Decision brief, risk routes and gaps
- 14–16, 21, 23Enterprise integration and key controls
- 32, 33, 35, 36Oversight, bias and connected evidence
- 41, 44, 45, 47–49Evaluation, institutional route and next steps
Assess the contribution, evidence needs and follow-up decisions.
Executive overview
Executive decision brief
The problem
A valid organisational objective does not automatically authorise every tool call, subdelegation or cumulative effect.
The contribution
Apply proportionate governance across risk categories, connecting lifecycle decisions to bounded authority and observed effects.
The evidence position
Published controls and reference code, plus a new oversight, bias and data-quality research profile. Operational effectiveness requires separate evidence.
The immediate request
Agree one evaluation boundary, the evidence to provide and the appropriate technical interlocutor.
Executive overview
A synthetic procurement workflow
Scroll horizontally for the full diagram.
Read invoiceDocument may contain hostile instructions
→Delegate checksSeveral agents share one mandate
→Amend supplierRecipient and record can change
→Request paymentTimeout may conceal a committed effect
→Observe resultCheck the authoritative resource
Authority question
Who permitted this exact recipient, amount and purpose?
Composition question
Can individually permitted requests exceed the common budget?
Evidence question
Did the intended effect occur, and what remains unknown?
Legal baseline
System scope and accountable actors
Scroll horizontally for the full diagram.
Regulatory objects
- General-purpose model
- Downstream AI system and intended purpose
- Deployment in its operational context
Responsibility assessment
- Model provider and system provider can differ
- Deployer uses a system under its authority
- Modification can change the applicable role
- Article 3 accommodates varying autonomy. Agentic behaviour does not create an automatic high-risk category.
- Assess Article 6, Annexes I and III, prohibitions and transparency duties against the actual use.
- A technical mandate records operational authority. It does not determine legal agency or liability.
Legal baseline
The legal baseline on 10 October 2026
- 27 JUL 2026
AI Omnibus in force
Regulation (EU) 2026/1744 amends the AI Act.
- 2 AUG 2026
General application date
Specific exceptions and transitional provisions remain material.
- 2 DEC 2027
Article 6(2) and Annex III
Deferred Chapter III Sections 1–3, except Article 6(5).
- 2 AUG 2028
Article 6(1) and Annex I
Deferred Chapter III Sections 1–3, except Article 6(5).
The Omnibus also changes governance, literacy, testing and implementation provisions. Our proposal is assessed against the enacted instrument, not the November 2025 proposal.
Legal baseline
Existing duties and proposed implementation evidence
Scroll horizontally for the full table.
| Legal anchor | Engineering question | Evidence PALO proposes |
|---|---|---|
| Art. 9 | Foreseeable misuse and compound exposure | Action inventory, shared ceilings, adversarial cases |
| Art. 10 | Data quality, provenance and bias for intended use | Purpose-bound lineage, quality dimensions and bias studies |
| Arts. 11–12 and Annex IV | Can reviewers reconstruct the operation? | Linked claim, policy decision, receipt and observation |
| Arts. 13–14 and 26 | Can a person understand and intervene? | Intervention timing, reviewer capacity and safe-state evidence |
| Art. 15 | Can a compromised agent exceed its authority? | Scoped credentials, replay checks and connector tests |
| Arts. 17, 25–27, 72–73 | Who reassesses change, impact and incidents? | Responsible owner, review triggers and incident record |
Legal baseline and proportionality
PALO across the AI Act risk routes
Scroll horizontally for the full table.
| Risk route | Legal baseline | PALO governance application |
|---|---|---|
| Unacceptable risk | Art. 5: prohibited practices, subject to legal scope and exceptions. | Record a no-go decision for a prohibited use. Do not authorise deployment. |
| High risk | Art. 6 and Annexes I / III: apply the relevant high-risk duties. | Map obligations to risk and data controls, oversight and an evidence dossier. |
| Transparency / limited risk | Art. 50: specific disclosure and content-marking duties where applicable. | Assign disclosure responsibilities and check notices, labels and supporting evidence. |
| Minimal or no risk | No automatic high-risk duties. Art. 95 supports voluntary codes of conduct. | Keep a lean case record and accountable owner. Select safeguards for actual exposure. |
Article 50 can overlap high risk. GPAI rules form a separate layer. Other applicable law and application dates remain relevant.
Legal baseline
Three different gaps require different responses
Implementation gap
Translate existing objectives into an execution boundary, explicit failure semantics and repeatable tests.
Interoperability gap
Exchange meaningful authority and outcome evidence across different orchestrators, tools and verifiers.
Possible residual scope gap
Test whether material harm remains outside sufficiently effective existing duties and remedies.
GDPR, Regulation (EU) 2018/1725 where applicable, sector rules, product safety, contract and liability remain part of the deployment assessment.
Proposed profile
Control objectives for authority and action
Scroll horizontally for the full table.
| Control | Failure mechanism | Required observation in a test |
|---|---|---|
| DAG-01 · Owner and boundary | Responsibility or the controlled surface is undefined | Evaluation admission fails until the owner and boundary are recorded |
| DAG-02 · Identity and mandate | Expired or wrong-tenant authority remains usable | The controlled start rejects invalid current authority |
| DAG-03 · Subdelegation | A child gains authority absent from its ancestors | An added tool, purpose or higher limit is rejected |
| DAG-04 · Data purpose and egress | Stale fitness or an unapproved recipient persists | The action stops when the bound data conditions cease to hold |
| DAG-05 · Exact action | The target or payload changes after the decision | The execution boundary rejects the changed binding |
| DAG-06 · Prior approval | A consequential irreversible effect precedes review | Missing or invalid exact-action approval blocks dispatch |
Proposed profile
Control objectives for composition and assurance
Scroll horizontally for the full table.
| Control | Failure mechanism | Required observation in a test |
|---|---|---|
| DAG-07 · Shared exposure | Several valid requests exceed one common limit | Concurrent starts remain within the declared authority-domain ceiling |
| DAG-08 · Replay and uncertainty | Retry repeats an operation after an ambiguous result | Consumed authority is rejected and uncertain effects are reconciled |
| DAG-09 · Revocation | Queued or in-flight work outlives its authority | New starts stop and in-flight containment states remain explicit |
| DAG-10 · Effect observation | An acknowledgement conceals the wrong outcome | A trusted observation yields verified, mismatch or inconclusive |
| DAG-11 · Evidence and privacy | Evidence is tampered with, excessive or stale | Integrity, provenance, access and retention checks remain reviewable |
| DAG-12 · Change and incidents | A new tool or mismatch bypasses reassessment | A review trigger, resource hold and accountable decision are recorded |
Proposed profile
Relationship to existing technical practice
Scroll horizontally for the full table.
| Mechanism | Useful contribution | Question that still needs evaluation |
|---|---|---|
| Identity and OAuth/OIDC | Authenticate actors and constrain access | Does current organisational authority cover this exact operation? |
| OPA/Rego policy evaluation | Evaluate structured input against explicit policy | Is the decision enforced at every path to the resource? |
| MCP and tool protocols | Define transport, tool interaction and authorisation mechanisms | How do shared exposure, delegation and external-effect evidence compose? |
| Logs and signed records | Support reconstruction, integrity and provenance | Is the observation complete and trustworthy enough for the claim? |
PALO proposes an integrated lifecycle and evidence profile. NIST also pursues agent standards, protocols and identity research. Comparative evaluation should test the added value.
PALO architecture
Proportionate governance across the PALO lifecycle
Scroll horizontally for the full diagram.
FramePurpose and responsible owner
→ClassifyLegal route and actor roles
→AssessImpact, reversibility and exposure
→ControlSafeguards matched to the case
→MeasureOutcomes and burden
→Prove & ReviewEvidence and change decisions
PALO Framework
Risk screening, assessment and governance evidence across risk categories.
PALO-AM
Agentic governance: delegation, autonomy, oversight and assurance.
PALO-AI
Developer-preview reference runtime for selected controls.
Enterprise interoperability
Enterprise integration and compliance evidence
Scroll horizontally for the full diagram.
MCP / HTTPS and structured JSON connect enterprise adapters. n8n and Dify integrations remain previews.
PALO architecture
The execution and observation boundary
Scroll horizontally for the full diagram.
Agent / orchestrator
→Authoritative execution boundary
Mandate, policy and approval
→Controlled executor
→
External system / resource
Registered outcome verifier
→Linked evidence and incident record
Alternative credentials or direct connector paths must be excluded or declared
PALO architecture
The invariants behind the controls
Delegation
Allowed(child) ⊆ Allowed(parent)Expiry(child) ≤ Expiry(parent)Purpose(child) ⊆ Purpose(parent)
Shared exposure
Committed + reserved ≤ B
All competing starts must use the same authority domain. Unknown effects retain exposure.
MayStart(a,t) = valid identity ∧ current mandate ∧ allowed policy ∧ fresh evidence ∧ satisfied approval ∧ reserved exposure ∧ unspent capability ∧ admitted connector
PALO architecture
Mandates and bounded subdelegation
Scroll horizontally for the full diagram.
Accountable owner / root mandateApproved purpose, tools, recipients and expiryOne common exposure ceiling
↓
Invoice agent
Read the selected invoice
No independent budget creation↓
Supplier agent
Validate the specified supplier
Inherited ceiling and expiry↓
Execution agent
Request an exact approved operation
Common ledger reservationNarrower scope at each delegation · cumulative limits remain shared
- Resolve membership and current authority server-side. Removing metadata must not remove the control.
- A newly admitted member needs a versioned, auditable membership decision.
- The prototype does not prove general schema implication, trusted automatic spawning or multi-primary authority.
PALO architecture
The Action Claim as the binding record
Scroll horizontally for the full diagram.
Identity and authority
Human, workload, agent, tenant and delegation chainExact operation
Tool, target, arguments and argument-schema digestValidity and replay
Expiry, nonce, idempotency key and sequenceDeclared effects
Resource selector and Effect ContractData governance in v1.4
Purpose, fitness decision and disclosure digests→
Canonical bindingNormalised Action Claim
Hash of the complete authorised action
→
Approval / capabilityBound to the same action
Runtime detail
Code: approval for the exact claim
rego
Scroll horizontally for the full code excerpt.
1approval_valid if {2 approval := input.approval3 approval.status == "approved"4 approval.claimId == input.claim.claimId5 approval.claimDigest == input.claim_digest6 time.parse_rfc3339_ns(approval.expiresAt) > time.parse_rfc3339_ns(input.now)7}8 9requires_approval if {10 input.profile.delegation.requireHumanValidation11 not approval_valid12}- The approved claim ID and digest must match, and the approval must remain unexpired.
- The current trigger is the registered profile’s requireHumanValidation flag.
- The consequence and reversibility classification proposed in DAG-06 is a separate requirement.
Runtime detail
Prior approval and irreversible effects
Scroll horizontally for the full diagram.
Classify consequenceOwner-defined criteria
→Establish reversibilityEvidence, not an agent assertion
→Review exact actionAuthorised human and bounded expiry
→Recheck all conditionsApproval cannot override a denial
→Dispatch or holdNo review capacity means no start
A compensating operation is a new action. A requested stop is not evidence that information disclosure or another committed effect was reversed.
Runtime detail
Code: consumption at the execution boundary
sql
Scroll horizontally for the full code excerpt.
1UPDATE execution_capabilities2SET status = 'consumed',3 capability_json = ?,4 consumed_at = ?,5 updated_at = ?6WHERE capability_id = ?7 AND status = 'issued'8 9// Runtime rejects a competing consumption:10if (consumedUpdate.changes !== 1)11 throw new Error("Execution capability was consumed concurrently");- Current authority, data binding, expiry, signature and exact claim binding are checked before consumption.
- The same local SQLite transaction records execution intent and reserves swarm exposure.
- The external executor call occurs outside that transaction. Local atomicity does not establish external exactly-once execution.
Runtime detail
Three agents, one exposure ceiling
Scroll horizontally for the full diagram.
Shared limit 100
Charged exposure 80
Limit 100
Request 140ADMITTED
Charged exposure 40
Request 240ADMITTED
Charged exposure 80
Request 340ADMISSION DENIED
80 + 40 exceeds 100
The first two reservations consume 80 units. A third request would raise exposure to 120, so the shared authority must deny it.
Runtime detail
Code: one atomic budget reservation
sql
Scroll horizontally for the full code excerpt.
1UPDATE swarm_mandates2SET committed_units = committed_units + ?3WHERE swarm_id = ?4 AND status = 'active'5 AND committed_units <= ?6 7// The final bound is: mandate.budget.limitUnits - units8// The caller must already hold the execution transaction.9if (!this.db.inTransaction)10 throw new Error("Swarm reservation requires the execution transaction");- The guarded update succeeds only if the remaining ceiling covers the trusted charge.
- The reservation stores the claim digest, agent, execution ID and integer units.
- committed_units includes admitted reservations. Unknown results retain their charge.
Runtime detail
Effect Contracts describe observable predicates
json
Scroll horizontally for the full code excerpt.
1{2 "predicateId": "predicate-price-updated",3 "path": "/price",4 "operator": "changedTo",5 "value": 1206}Precondition
The relevant resource version must match before dispatch.
Expected effect
The price changes to the specified value within the observation window.
Forbidden effect
The contract defines an observable condition that must not occur.
Runtime detail
Code: verified, mismatch and inconclusive
javascript
Scroll horizontally for the full code excerpt.
1const status = checks.some((check) => check.status === "unknown")2 ? "inconclusive"3 : checks.some((check) => check.status === "fail")4 ? "mismatch"5 : "verified";6return { status, checks };Verified
The evaluated predicates pass within the declared observation scope.
Mismatch
Known observations fail a declared predicate.
Inconclusive
At least one check is unknown, or verification cannot support attribution.
Runtime detail
Timeout and recovery without blind retry
Scroll horizontally for the full diagram.
Runtime detail
Revocation and in-flight cancellation
Scroll horizontally for the full diagram.
Runtime detail
Prompt injection and alternative execution paths
Scroll horizontally for the full diagram.
Untrusted inputs
- Retrieved documents
- Tool output
- Peer-agent messages
Controlled decisions
- Versioned mandate
- Policy and approval
- Credential custody
External effect
- Admitted connector
- Resource-side permissions
- Authoritative observation
→ Treat retrieved instructions as data
→ Reject unauthorised target or egress changes
→ Test alternate credentials and direct resource access
Runtime detail
Context continuity across long agent workflows
Scroll horizontally for the full diagram.
Required, versioned records
- Purpose and constraints
- Mandate and policy versions
- Approvals and unresolved effects
Lossy conversational summary
- Conversation summary
- Compressed tool history
Resolve required records → Validate versions and freshness
RecoverRehydrate → validate → proceed
Cannot recoverBlock the action
Proposed extension; complete continuity guarantee not established
Runtime detail
Evidence, data purpose and privacy
Scroll horizontally for the full diagram.
Authority recordOwner, mandate and versions
→Decision recordClaim, policy and approval
→Execution recordCapability, intent and receipt
→Outcome recordObservation, checks and uncertainty
→Review recordIncident, remedy and accountable closure
Minimise and bind
Reference relevant evidence, restrict payloads and bind data purpose, recipients and disclosure conditions.
Protect and review
Define access, retention, signer trust and key custody. Preserve integrity without assuming the content is true.
Trustworthiness and future readiness
Three evidence tracks for agentic trustworthiness
Scroll horizontally for the full diagram.
Effective oversight
- Current: exact-action approval and escalation
- Extend: timing, capacity and safe-state tests
Bias across the workflow
- Current: fairness and subgroup controls
- Extend: routing, completion, remedy and feedback
Fit-for-purpose data
- Current: lineage, purpose and freshness
- Extend: separate measures and change propagation
Trustworthiness and future readiness
Oversight must act before the harm window closes
Scroll horizontally for the full diagram.
QueueAssignment and waiting
→NotifyPerceivable, usable alert
→UnderstandInterpret and decide
→ActuateMitigation takes effect
→Check marginWithin the reaction window
Qualify the whole loop under realistic load. Adding component p95 values does not establish an end-to-end p95.
Trustworthiness and future readiness
Verify the intervention and the safe state
Scroll horizontally for the full diagram.
Trustworthiness and future readiness
Measure bias across the agent’s complete trajectory
Scroll horizontally for the full diagram.
RetrieveCoverage and source quality
→Plan / routeAssumptions, model and tools
→ActSuccess and harmful effects
→EscalateWaiting, access and remedy
→LearnFeedback and memory drift
Use case-level denominators, intersectional analysis and uncertainty. Missing or small samples yield insufficient evidence.
Trustworthiness and future readiness
The bias profile connects four evidence levels
Scroll horizontally for the full diagram.
DataPopulation, provenance and quality
→ComponentsRetriever, planner, router and tools
→System outputsPlans, allocation and correctness
→OutcomesCompletion, harm, access and remedy
Trustworthiness and future readiness
Choose metrics for the task and the harm
Scroll horizontally for the full table.
| Question | Candidate measurement | Interpretation boundary |
|---|---|---|
| Who receives a tool or service? | Allocation / classification disparity | Positive class, labels and base rates |
| Who waits or bears a cost? | Mean and loss differences | Units, tails and absolute service quality |
| Who appears in ranked results? | Representation across chosen cutoffs | Reference shares; not measured attention |
| Who achieves the final outcome? | Outcome-rate differences / ratios | Downstream observation; no causal proof |
| What do representations reveal? | Group-information diagnostic probe | Sensitive evaluation; not a profiling service |
Trustworthiness and future readiness
Acceptance needs quality, precision and error control
Scroll horizontally for the full diagram.
Before measurement
- Register groups, endpoint and fixed sample plan
- Bind floors, disparity bands and error budget
During evaluation
- Keep every required group in the family
- Evaluate simultaneous bounds and precision
After findings
- Supported / adverse / inconclusive / invalid
- Risk review remains a separate accountable step
Trustworthiness and future readiness
Data fitness is a purpose-bound set of measures
Scroll horizontally for the full table.
| Dimension | Agentic evidence | Reopen when… |
|---|---|---|
| Accuracy / completeness | Verified labels, missing fields and retained constraints | Source, extraction or annotation changes |
| Representation / relevance | Task and cohort coverage, retrieval evaluation | Population, purpose or retrieval corpus changes |
| Freshness / consistency | Expiry, conflicting claims and temporal validity | A source changes, expires or contradicts another |
| Lineage / permissions | Origin, transformations, access and intended use | Data rights, recipients or tools change |
| Feedback integrity | Holdout results and generated-data provenance | Memory or optimisation policy changes |
Trustworthiness and future readiness
A research profile joins the evidence for review
javascript
Scroll horizontally for the full code excerpt.
1// Read-only research screen; expected context is supplied separately.2const result = evaluateProfile(profile, expectedContext, assessmentTime);3 4// Scope, current evidence, timing, workload, intervention,5// separate data dimensions and cohort uncertainty are checked.6// Result: eligible_for_review | hold | insufficient_evidence7 8// This result never authorises an action.9// Existing policy, exact approval and capability checks still apply.Evidence and evaluation
Implementation maturity and remaining work
Scroll horizontally for the full table.
| Component | Available evidence | Boundary |
|---|---|---|
| Method and control profile | Published lifecycle, DAG-01–12 and pilot protocol | Proposed profile, no EU standard or conformity finding |
| Action and effect contracts | Schemas and inspected binding logic | Structure and declared constraints, not factual truth |
| Approval, capability, observation | Reference code and synthetic test definitions | Prototype integration and deployment-dependent trust |
| Swarm budget, workers, membership | Unreleased working-tree code | Central authority, no replicated HA qualification |
| Oversight, bias and data-quality extension | Research profile and 31 synthetic checks | Shadow-mode proposal; no live integration or user study |
| Production and independent effectiveness | Admission criteria and evaluation protocol | Connector, key custody, isolation and effectiveness still require evidence |
Evidence and evaluation
Evidence available for technical review
Scroll horizontally for the full table.
| Evidence class | What we can show | What it establishes |
|---|---|---|
| Current source inspection · 8 Oct | Claim binding, Rego approval, local transactions, observation and recovery excerpts | Mechanisms present in the inspected working-tree files |
| Synthetic test definitions inspected | 8 assurance cases, 15 local swarm cases, 14 distributed cases | Intended coverage; not a fresh execution result |
| Recorded check · 30 Sep | 10 reviewer inventory / CSV tests passed | Review-tool behaviour only |
| Supplementary DAG-06 evaluation | Six cases marked NOT RUN | The stronger approval rule has not been validated |
| Fresh checks · 10 Oct | 7 current-fitness probes; 31 profile + 30 statistical checks | Synthetic behaviour only; full draft implementation and deployment qualification remain open |
Evidence and evaluation
Adversarial cases and residual failure modes
Scroll horizontally for the full table.
| Attack or failure | Control to exercise | Residual question |
|---|---|---|
| Payload changes after approval | Digest binding and current policy | Can another credential bypass the executor? |
| Concurrent spend and duplicate claims | Atomic reservation and consumption | Does the connector report the true charge? |
| Crash or partition after dispatch | Durable intent, unknown state and hold | Can authoritative evidence resolve the external effect? |
| Compromised or incomplete verifier | Observation trust and predicate review | Which effects remain outside the observed scope? |
| Revocation during execution | Start prevention and cancellation protocol | Is the effect still cancellable at the resource? |
| Reviewer overload, missing cohort or stale data | Capacity, uncertainty and dependency reassessment | Can a polished dossier still hide ineffective control? |
Evaluation proposal
A comparative pilot with a credible baseline
Scroll horizontally for the full diagram.
Matched baseline
- Existing required controls retained
- Fixed workflow, model, prompts and permissions
- Normal and adversarial cases
Profile implementation
- Baseline plus PALO reference integration
- Equivalent implementation B where available
- Same tasks, cohort design and outcome observation
Synthetic procurement, public-service and software-operations scenarios. No live funds, citizen decisions or production credentials.
Evaluation proposal
Measures and decision rules
Scroll horizontally for the full table.
| Measure | Denominator or observation | Proposed gate |
|---|---|---|
| Unauthorised effects | Confirmed forbidden effects / designed attack attempts | Any critical effect stops the affected scenario |
| False blocks and unknown outcomes | Legitimate attempts; dispatched actions | Report separately against baseline |
| Exposure and revocation | Peak charged exposure; starts after effective revocation | No tested overspend or unauthorised new controlled start |
| Reconstruction and interoperability | Sampled cases; agreed exchange fixtures | Critical cases reconstructable; exchange failures disclosed |
| Oversight and reviewer burden | Time to mitigation, error acceptance, load and access | Qualify the full operating envelope |
| Bias, data quality and rights | Per-case cohorts, uncertainty, dimensions and remedy | Hold critical failures; missing evidence remains unresolved |
Evaluation proposal
Readiness gate and twelve-week evaluation
- BEFORE START
Readiness confirmed
Owner, evaluator, roles, resources, baseline and isolated environment.
- WEEKS 1–4
Scope and integrate
Protocol, fixtures, observation boundary and frozen versions.
- WEEKS 5–9
Execute and review
Boundary tests, operator exercises and adversarial evaluation.
- WEEKS 10–12
Reproduce and decide
Failures, uncertainty, costs and proceed / revise / stop decision.
Resource assumption
24–36 person-weeks is an internal planning envelope, subject to role, scope and rate validation.
Unconfirmed dependencies
Sponsor, evaluator, second implementer, funding and institutional participation.
Policy options
Institutional routes supported by evidence
Scroll horizontally for the full diagram.
- 01
Technical scoping
Agree the question, owner and evidence boundary
Immediate request - 02
Comparative evaluation
Measure effectiveness, failure and burden
Proposed pilot - 03
Guidance / voluntary practice
Article 96 implementation and Article 95 pathways
Subject to the relevant process - 04
Standardisation
Equivalent controls and exchangeable evidence
Contribution through appropriate bodies - 05
Targeted legislation
Only for a demonstrated residual problem
Separate legal and impact assessment
Closing
A focused technical follow-up
One workflow. A declared boundary. Comparable evidence.
Scope
Which delegated-action problem is most useful to examine first?
Evidence
What would make a test result credible and relevant to your teams?
Route
Which technical group or existing initiative is the appropriate interlocutor?
PALO can contribute the discussion profile, provision mapping, reference contracts, code excerpts and proposed evaluation fixtures.
Proposed follow-up
Next steps
- 01
At this meeting
Confirm the scope
Choose a workflow, harm scenario, affected population and designated-person role.
OutputA short scoping note - 02
After the meeting
Share the evidence package
Challenge the 90 mappings, source ambiguities and research code. Confirm the clean enquiry edition.
OutputA versioned review package - 03
Subject to interest and readiness
Define a comparative evaluation
Agree timing, capacity, cohort and data-quality evidence, baseline and independent review.
OutputAn agreed protocol and readiness decision - 04
After evaluation
Review results and choose a route
Assess effectiveness and burden. Version the profile only after findings and compatibility review.
OutputFindings and an appropriate follow-up route