PALO taxonomy and controlled dictionaries for agentic governance

Subsequent source maintenance: the six-source review of 12 October 2026 updates the live source registry and clarifies two control packs. The catalogue and PDF remain the inspected earlier snapshot.

Taxonomy and dictionaries · Ontologies and operational grounding · Searchable technical catalogues · Complete PDF

Technical deep dive for the follow-up discussion with the European Commission

Fabrizio Degni · PALO Framework · Evidence snapshot 12 October 2026

PALO provides a versioned vocabulary for connecting lifecycle governance, delegated authority, controls, evidence and accountable decisions. Its semantic implementation comprises a released foundation, structured agentic contracts and a draft extension for dependencies and policy impact. These layers have different purposes and maturity. The central contribution is the explicit separation of what a system is, what an agent is authorised to attempt, what actually happened, what evidence supports that account and who accepts the resulting decision.

The two sections below explain taxonomy and controlled dictionaries, followed by ontologies and their operational grounding. The accompanying catalogues expose every schema entry and enumeration in the inspected schema set, together with the actual RDF classes, properties and shapes. They make the analysis inspectable beyond the narrative.

The scope is semantic design and evidence contracts. PALO-AI remains a developer-preview reference runtime. A coherent vocabulary, a valid record or a passing fixture does not establish legal conformity, deployment admission or operating effectiveness in an adopting organisation. The positive meeting response reported by the author is not used as evidence of institutional endorsement.

Sintesi italiana#

PALO dispone di una base semantica concreta: un registro di concetti e relazioni, definizioni versionate del ciclo di vita, schemi per le evidenze e le decisioni, un’ontologia RDF/OWL e vincoli SHACL. La governance agentica aggiunge contratti operativi per identità, autorità delegata, richieste di azione, approvazioni, capacità esecutive, effetti attesi, ricevute, verifica degli esiti, idoneità dei dati e divulgazione delle informazioni.

Il punto da presentare alla Commissione è la continuità tra significato, decisione e prova: una regola di governance è collegata al caso concreto, alla versione applicabile, alle evidenze e all’autorità che decide. Occorre però distinguere ciò che è già rappresentato in OWL da ciò che oggi è formalizzato soprattutto in JSON Schema e nel runtime. L’estensione del grafo dello stack è dichiarata draft e non va presentata come una seconda ontologia già stabilizzata.

Le verifiche su questo snapshot hanno confermato 65 schemi leggibili, 61 fixture JSON con esito atteso, 40 corrispondenze su 40 tra file e digest del manifest, una fixture RDF valida e una invalida correttamente respinta. Sono controlli dei contratti acquisiti, non una nuova qualificazione dell’intero runtime. La riconciliazione aggiunge una corrispondenza esplicita fra le cinque attività storiche e le sei fasi canoniche, distingue i due significati precedentemente associati a CECR e uniforma l’esito di routing a “Redesign required”. Tre ulteriori schemi PolicyWatcher completano il corpus. Le proposte di estensione ontologica restano separate dalle modifiche editoriali effettive.

Reading the implementation status#

Verified inventory#

Sources: [P01], [P02], [P03], [P04], [P05], [P06], [P07], [P08], [P09], [P10], [V01].

1.1 What PALO classifies and why#

For this deep dive, taxonomy means the organised classification of governance concepts; a controlled dictionary specifies the permitted terms, identifiers, values and intended meanings; an ontology states formal classes and relationships; a schema constrains a record’s structure; and an executable policy evaluates an action against current rules and inputs. These are complementary mechanisms. An allowed value has a defined lexical meaning, but only a valid decision process can give that value authority for a particular action.

PALO’s taxonomy is best described as a set of connected facets. The lifecycle answers when governance work occurs. The agentic modality asks who acts, under whose authority, on which resources and with what autonomy. The evidence model asks which assertion is being made, what supports it and how it was evaluated. The stack extension adds technical dependency and policy-change context. No single tree captures all these dimensions without collapsing material distinctions. [P01], [P02], [P10], [P11]

The present implementation distributes its dictionaries across JSON registries, JSON Schema enumerations, RDF terms, JSON-LD contexts, source records and UI labels. It does not contain a single reviewed SKOS concept scheme unifying all these terms. A SKOS export is therefore an interoperability proposal, not a description of an existing PALO deliverable. [P01], [P07], [P08], [W01]

1.2 Framework layers and their authority#

The December 2025 founding document supplies the conceptual roots: fairness/non-discrimination; transparency/explainability; accountability/responsibility; privacy/data governance; safety/robustness; human agency/oversight; and societal/environmental well-being. It evaluates use cases across ethical integrity, technical robustness/safety, business value/feasibility, legal/regulatory conformity and socio-environmental impact. These are normative evaluation dimensions and objectives, not assertions that a system has achieved them. The later semantic spine and agentic contracts turn parts of this conceptual structure into versioned identifiers and evidence requirements. [H01]

This distinction is part of the semantic design, not just product naming. The core ontology explicitly separates RegimeDefinition, GovernanceFrameworkDefinition and EnforcementAdapterDefinition, with pairwise disjointness axioms. However, declaring classes does not automatically classify every UI label or component as an instance of them. [P07], [P10], [P11], [P12]

The spine has four evidence/authority classes: canonical-definition, source-backed-context, illustrative-local-preview and human-review-required. The first is authoritative as a PALO definition. None of the four, merely by classification, grants legal authority or changes the state of a case. The authoritative: true flag on canonical definitions must always be read within this scope. [P01], [P02]

The public semantic catalog, case workspace and assurance review are three workspaces. “Executive” and “Technical” are presentation lenses, not authenticated identities or access-control roles. Delivery maturity is another axis: the capability matrix distinguishes specified, prototype, implemented and production-ready. These values must not be merged with evidence authority or legal status. [P01], [P02], [P13]

1.3 The lifecycle taxonomy#

Gate definitions list proceed, proceed-with-conditions, hold, redesign and stop. The Gate Decision Record additionally permits unresolved, preserving the difference between a concluded routing choice and a recorded undecided state. A conditional decision requires conditions; decisions after sequence 1 require the preceding decision identifier and digest. [P03], [P14]

The PALO-AM page also retains a five-phase historical presentation: ideation and screening; assessment and planning; development and validation; ethical deployment and monitoring; continuous improvement and decommissioning. This is not the same list as the canonical six-phase lifecycle. The editorial glossary and agentic page publish the following explanatory correspondence: historical phase 1 mainly informs Frame/Classify; phase 2 informs Classify/Assess/Control; phase 3 informs Control/Measure; phase 4 informs Measure/Prove; phase 5 informs Prove and the next cycle. That correspondence is a versioned interpretation for readers, not a one-to-one migration mapping or an executable gate rule. [P35] Canonical identifiers should remain the six current phases. [P03], [P11]

1.4 The five PALO-AM operational objects#

Agent Identity Profile describes the agent and its provenance, owner and operating context. The narrative includes credential lifecycle, topology, clearance and revocation. The concrete Agent Profile schema represents agentId, profileVersion, role, lineage, base model and systemPromptHash, with optional temperature. Status can be active, suspended or retired. A prompt hash binds bytes; it does not prove that the model followed the prompt or retained all conversational requirements. [P11], [P15]

Agent Authority Profile describes permitted activity. The schema supplies tool allow-lists, operation types, read/write scopes, external-network permission, optional host constraints, argument schemas and a Vibe Gate requirement. Identity and authority coexist in the Agent Profile but remain conceptually distinct. A recognised agent is not automatically authorised to use every tool. [P15]

Agentic Risk Matrix routes a configuration using action-space impact and autonomy, modified by reversibility, sensitivity and potential impact. Narrative considerations additionally include third-party dependency, speed/volume and multi-agent complexity. Those additional considerations are not independent inputs to the inspected five-field simulator. [P11], [P16]

Agentic Control Layer describes the technical and organisational controls surrounding model proposals: policy evaluation, tool schemas, scoped credentials, approval checkpoints, observability, circuit breakers and change management. The presence of a control in this taxonomy is a governance expectation. Whether it is implemented and non-bypassable must be established for the actual connector and deployment. [P11], [P12]

Agentic Evidence Layer records proposals, tool calls, structured inputs/outputs, policy decisions, approvals, incidents, measures and retirement evidence. It does not require disclosure of a model’s private chain of thought. The object cards are useful operational domains; they are not five correspondingly named OWL classes in the core vocabulary. [P07], [P11]

1.5 Action space, autonomy and the exact routing matrix#

The implemented base matrix is reproduced below. Lower numbered positive tiers demand stronger controls. 0 means redesign required in the simulator. [P16]

Tier 1 is “Maximum controls”; Tier 2 “Controlled”; Tier 3 “Supervised”; Tier 4 “Monitored”. If at least one of irreversible action, restricted data or severe impact is present, a positive base tier is escalated by one tier only, with a floor of Tier 1. The three escalation triggers do not accumulate into three tier changes. High autonomy plus critical action remains 0. Partial reversibility changes recommended controls/evidence but does not itself trigger the tier escalation. These details matter if a third party reimplements the taxonomy. [P16]

The reconciled static matrix and simulator both label the high-autonomy/critical combination “Redesign required”. The former static label “PROHIBITED” is retained only as a deprecated display alias in the editorial glossary. This is a PALO design rule and must not be equated with a prohibited practice under the EU AI Act. [P35] A legal classification would require a separate source-specific analysis. “Supervised” also appears both as an autonomy input and a tier label; these are different fields and should be qualified when exported. [P11], [P16]

1.6 Identity, authority and delegation dictionaries#

The Agent Profile permits six operation values: read, create, update, delete, execute, delegate. Action Claims use the same operation vocabulary, while network intent is separately classified as none, read, write or bidirectional. An operation token is intentionally broad. The exact tool, resource, canonical path and argument schema determine what the action actually means. [P15], [P17]

Delegation uses a maximum depth, maximum subagent count, permitted subagent roles and a human-validation requirement. The profile schema allows a depth from 0 to 20 and a maximum subagent count from 0 to 1,000. These are schema bounds, not recommended safe operating settings. An adopting organisation must choose substantially narrower limits where appropriate and test enforcement. [P15]

Action Claim authority context distinguishes the human principal, agent identity, workload identity, delegation chain and tenant. Workload proof types include mtls, dpop, http-message-signature and spiffe-svid; the enumeration lists accepted representation categories and does not establish universal interoperability with every implementation of those technologies. ANS integration is upstream identity/status evidence and does not itself establish permission, data fitness or successful effect. [P17], [P18]

The swarm mandate extends the scope to a named owner, objective, coordinator, members, tenant/case, validity interval, budget and concurrency limit. Budget rules bind tool, operation, resource and path; the prototype’s narrative requires one unambiguous matching rule, a non-negative integer charge and a per-action maximum. Membership changes carry an expected membership digest and reason. A natural-language objective records an accountable intention; it is not a machine proof of goal alignment. [P19]

This yields a useful delegation taxonomy: principal versus agent versus workload; profile versus one-action authority; parent versus descendant; individual limit versus shared exposure; permission revocation versus confirmed interruption. Revoking future authority must not be described as undoing an action already executed or proving cancellation of an in-flight external effect. [P18], [P19]

1.7 The action and assurance dictionary#

The reference sequence is Propose → Authorize → Approve when required → Capability → Execute → Receipt → Observe → Verify → Escalate when required. This is a governance/assurance sequence, not a replacement for the six lifecycle phases. Approval is conditional; it should not be depicted as necessarily occurring in every action. [P12], [P17], [P20]

Action Claim versions 1.1.0 through 1.4.0 are represented in the schema. Version-specific conditions matter: 1.3 introduces the identity-bound authority context; 1.4 additionally binds the Data Fitness Decision and Disclosure Contract by identifier and digest, subject and purpose. An integration must evaluate the actual schema branch rather than treating schemaVersion as decorative metadata. [P17], [P21]

1.8 State vocabularies must remain separate#

These values are not interchangeable booleans. An approved mapping is a publication/review assertion; an approved action is a particular human approval; an accepted evidence claim has still a distinct evaluation record. Likewise, unknown, unverified, inconclusive and unresolved preserve different kinds of missing knowledge. The catalogue keeps each enum attached to its schema and field path instead of deduplicating words that only look similar. [P14], [P17], [P20], [P21], [P22], [P23], [C01]

A notable implementation detail is the effect evaluator’s aggregate precedence: a check with unknown makes the aggregate inconclusive before the code considers failing checks. Therefore a record may contain both a failed predicate and an inconclusive aggregate. Consumers must retain and inspect per-predicate results rather than hiding an observed failure behind the aggregate label. This is an observation of the inspected reference code, not a proposed alteration. [P24]

1.9 Data and information disclosure taxonomy#

The data-assurance contracts classify the governed subject as dataset, data-product, model, ai-system, agent, tool, access-entitlement or other. They connect the subject and tenant to a purpose, source references, quality and lineage assertions, access state, source authority, approval, freshness and incident context. External metadata is evidence to be evaluated; importing it does not independently attest its truth. [P21], [P25]

Data fitness means suitability for a stated use under a particular policy and current evidence. The reference evaluator supports quality thresholds, age limits, source authority, ownership/approval, lineage, access, incidents, prohibited classifications and permitted purposes. Missing evidence has explicit deny/review handling. Conflicting current evidence is evaluated conservatively rather than selecting the most favourable assertion. This remains a rule-based fitness decision, not a universal numerical quality score. [P21]

Disclosure is separately governed because appropriate access does not imply appropriate transmission. The Disclosure Contract classifies egress as zero-row, aggregated or row-level; trace modes as disabled, metadata-only or redacted-payload; and binds fields, row limits, redactions, destinations, provider/model/region/host, retention, export and output schema. Aggregation does not automatically establish anonymity. [P21], [P25]

The lawful-basis field permits consent, contract, legal-obligation, vital-interests, public-task, legitimate-interests, not-applicable and pending-review. These tokens record a classification supplied to the governance process. They do not determine whether a basis is legally available. The documented active-contract rule excludes pending-review and requires an approver; that runtime condition is stronger than simply observing that the string exists in a schema enum. [P21], [P25]

An observation records actual fields/rows read and disclosed, sensitive categories, redactions, destination, trace behaviour and digests. The Disclosure Receipt compares that observation with the contract. Missing trustworthy observation remains inconclusive. Because the reference executor and signing material share an in-process boundary, its signed observation is not independent proof that all external network activity was observed. [P21]

1.10 Controls, indicators and applicability dictionaries#

The 12 governance-control domains are fairness and subgroup testing; system cards and explanations; notice, appeal, review and remedy; Article 50 transparency; data lifecycle; GPAI and systemic risk; serious incidents and decommissioning; accessibility; environmental performance; AI-literacy effectiveness; ISO/IEC 42001 AIMS overlay; and PALO-AI production boundary. Each domain names its objective, applicability questions, controls, indicators, gates, evidence contracts, completion criteria, stop conditions and residual boundary. [P04]

The control library classifies controls as directive, preventive, detective or corrective. It includes purpose boundaries, provenance, meaningful review, supplier due diligence, adversarial testing, incident response, material change gates, decision traceability and agentic authority, alongside the domain-specific additions. “Not applicable” must be supported by a reasoned accountable decision; omission is not an applicability outcome. [P04], [P05]

The 38 registered KPI/KRI definitions carry formula, cadence, direction, thresholds, linked controls/gates/sources and caveats. Their source explicitly labels thresholds as illustrative. A metric can indicate documentation coverage while saying little about substantive correctness. For example, provenance coverage does not establish permission or fitness, and completed reviews do not establish that reviewers had enough time or independence. [P06]

The agentic page adds 11 named indicators: HOR, RTD, ABI, TCER, AISI, MACR, MTTI, CECR, AIRT, TDS and PVR. These are not 11 automatically additional canonical registry entries: some overlap with registry concepts, and others remain narrative definitions. ABI and TDS lack a fully specified numerical protocol in that page. The earlier CECR collision is resolved in the editorial glossary: palo-am:cascading-error-containment-rate retains CECR, while palo-am:simulator-control-effectiveness-coverage names the separate simulator recommendation without that abbreviation. The latter still needs a numerical protocol before it can be treated as an operational metric. The glossary does not add either concept to the canonical KPI/KRI registry. [P35] [P11], [P16]

Oversight and bias crosswalks in the briefing are separate research artefacts. Their relationship to the core should be expressed as versioned, source-scoped mappings, retaining draft-source status, clause interpretation and reviewer responsibility. They should not be counted among the 409 core mappings merely because they also use the word crosswalk. Private draft source documents are not required for the public dictionary export. [P26]

1.11 Evidence, mappings and versioned meaning#

The atomic evidence model distinguishes an artifact, an evidence claim, an evaluation and a bundle manifest. The artifact identifies content and provenance. The claim states a falsifiable assertion about one target in one case scope. The evaluation records the reviewer, assessment-run context, outcome, rationale and quality dimensions. The bundle composes digest-bound records. This prevents a document’s presence from being mistaken for successful evaluation of the proposition it is meant to support. [P22], [P23], [P27]

Evidence Evaluation quality values separately cover relevance, integrity, recency and independence, each in the range 0–1. The schema bounds the values but does not supply a universally valid scoring method. A consumer should preserve the method and rationale and avoid treating a mean of four values as proof of assurance. [P23]

Each core mapping is atomic: one source version, one target version, mapping type, coverage, conditions, rationale, basis, approval and provenance. The 409 records comprise 101 control-to-gate, 55 control-to-indicator, 72 control-to-source, 11 gate-to-source, 106 indicator-to-gate and 64 indicator-to-source relationships. Every control-to-gate record is conditional; all other current records are supporting. Although the schema permits total and partial, those values do not occur in this inspected registry. [P09]

These mapping counts measure authored relationships, not coverage of 409 legal obligations. The mapped source version is a PALO registry reference, not a statement that every clause of an external standard is represented. A mapping’s approved publication state must not be transformed into a conformity assertion. [P09], [P28]

1.12 A reviewable dictionary entry and maintenance process#

For an interoperable exchange, a dictionary entry should contain a stable concept IRI, preferred label, definition, scope note, aliases/acronyms, broader/related concepts, schema and field paths, allowed values, version, status, owner/reviewer, provenance and change history. Language labels should use explicit tags. Semantic identity should remain stable across translation; an English label and its Italian translation are not different control concepts.

PALO already supplies substantial ingredients, especially identifiers, versions, source references, authority boundaries, schemas and mappings. The accompanying extraction preserves these machine-level facts. Additional bilingual definitions, ownership and synonym resolution are a proposed curated layer, not fields assumed to be populated in every existing artifact. [P01], [P02], [C01]

The maintenance sequence should be: propose term; identify existing meanings; choose reuse or a new identifier; attach source and scope; review consequences for schemas, policies and user interfaces; test representative and adversarial records; approve a version; publish a digest-bound release; preserve old identifiers or explicit migration. Major meaning or cardinality changes require the existing change-impact and migration process. A wording clarification should not silently change what actions a policy permits. [P28], [P29]

1.13 PolicyWatcher transport and review dictionaries#

Three additional JSON contracts make external-policy signals more precise. They complement the individual PolicyWatcher signal contract and the draft dependency graph; none grants policy applicability or action authority. [P34]

The registry separately names error codes network-error, http-error, schema-error, response-too-large, pagination-error and capacity-exceeded. Those classifications preserve the reason a snapshot cannot be relied on as complete. Registry statistics count received, accepted, rejected, changed, active and revoked signals; the schema fields must accompany the number, because “accepted” here describes the import process.

The review ledger binds an assessment to the imported signal digest and source-registry digest. If the transport later reports revocation or a different digest, the prior local review must remain attributable to the version actually seen. The JSON contract supplies those bindings; an adopting implementation must enforce reconciliation, reviewer identity and persistence. Browser-local data must not be represented as an organisation-wide authoritative review log.

The complete schema catalogue now includes the union of the inspected agentic and semantic contracts, these three transport/review schemas, and three explicitly draft or local extension schemas. Equal counts in two repositories do not imply identical memberships. The published field dictionary therefore includes the schema filename, path and constraints for every entry rather than presenting an undifferentiated list of terms.

Sources and accompanying catalogues#

PALO artifact links resolve to public source locations where available. The research snapshot and validation records preserve the inspected bytes. Linked living pages may subsequently change.

• [P01] PALO semantic foundation.
• [H01] Fabrizio Degni, The PALO Framework A Paradigm for Principled AI Lifecycle Orchestration in Business, December 2025, 67-page local founding document under framework/. Core principles: pp. 13–15; five-phase lifecycle: pp. 18–22; evaluation dimensions: pp. 22–23. Page numbers refer to the PDF page sequence. Extract retained in the research record.
• [P02] Semantic spine.
• [P03] Lifecycle definitions.
• [P04] Governance control packs.
• [P05] Control library.
• [P06] KPI and KRI registry.
• [P07] Core ontology.
• [P08] Core SHACL profile.
• [P09] Semantic mappings.
• [P10] Stack and policy impact graph and stack model.
• [P11] PALO-AM operational model.
• [P12] Full-cycle assurance.
• [P13] Agentic capability matrix.
• [P14] Gate Decision Record schema.
• [P15] Agent Profile schema.
• [P16] PALO-AM simulator source.
• [P17] Action Claim schema.
• [P18] ANS integration.
• [P19] Swarm prototype, distributed extension and mandate schema.
• [P20] Effect Contract, Execution Capability, Execution Receipt, Outcome Attestation, Policy Decision, Approval.
• [P21] Data assurance control plane.
• [P22] Evidence Claim schema.
• [P23] Evidence Evaluation schema.
• [P24] Inspected local source packages/palo-mcp-server/core.js, preserved with digest in the research snapshot; public project PALOframework. Local working-tree code is not assumed to equal the published Git HEAD.
• [P25] Disclosure Contract, Disclosure Observation, Disclosure Receipt, Data Fitness Decision.
• [P26] Oversight crosswalk and bias crosswalk.
• [P27] Evidence Artifact and Evidence Bundle Manifest.
• [P28] Semantic Release Manifest and pinned public release generator.
• [P29] Semantic change-impact register.
• [P30] Stack ontology, stack SHACL, stack JSON-LD context and core JSON-LD context.
• [P31] Pinned public semantic validator.
• [P32] Semantic invariants.
• [P33] Evidence-envelope schema and pinned assurance foundation implementation.
• [P34] PolicyWatcher Signal Batch, Operational Signal Registry and Browser-local Review Ledger. Acquired from Git commit 42d17508ddc836ae37076d9320cbbc672ea268cc.
• [P35] Agentic editorial glossary and historical lifecycle correspondence, version 1.0.0. Separate from the canonical ontology and KPI/KRI registry.
• [P36] Semantic publication inventory. This records the editorial release; deployment evidence is a separate receipt.
• [W01] W3C SKOS vocabulary.
• [W02] W3C OWL 2 Primer.
• [W03] W3C SHACL Recommendation.
• [W04] W3C PROV-O.
• [W05] W3C ODRL Information Model.
• [W06] Data Privacy Vocabulary. DPV 2.3 identifies itself as a Final Community Group Report and explicitly states that it is not a W3C Standard or on the W3C Standards Track.
• [W07] W3C DCAT 3.
• [W08] W3C JSON-LD 1.1.
• [C01] Schema index, field dictionary JSON, field dictionary CSV and controlled values.
• [C02] RDF inventory and searchable catalogue.
• [V01] Snapshot verification results and source inventory. The reproducible audit script and complete acquired source snapshot are retained in the local review package. Verification date: 12 October 2026.