fxdemo:02-part:04-logical-architecture-principles:04-8-policy-governed-sharing-without-centralised-data-routing:start

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
fxdemo:02-part:04-logical-architecture-principles:04-8-policy-governed-sharing-without-centralised-data-routing:start [2026/07/11 11:07] – ↷ Links adapted because of a move operation nick_didofxdemo:02-part:04-logical-architecture-principles:04-8-policy-governed-sharing-without-centralised-data-routing:start [2026/07/18 12:33] (current) – external edit 127.0.0.1
Line 4: Line 4:
 The Logical Architecture supports policy-governed information sharing without requiring all protected information to pass through a single central policy server, release server, or gateway. The Logical Architecture supports policy-governed information sharing without requiring all protected information to pass through a single central policy server, release server, or gateway.
  
-Policy-governed sharing is represented as a distributed logical capability. Logical Nodes may enforce [[fxdemo:dido_99_annexes:annex-b-terms-and-definitions:l:logical_policy_constraints|policy constraints]] near protected actions, request policy decisions from replicated decision capabilities, obtain attributes from policy information sources, receive policy baselines from policy administration capabilities, and record obligations, release actions, and [[fxdemo:dido_99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] through audit and provenance relationships.+Policy-governed sharing is represented as a distributed logical capability. Logical Nodes may enforce [[dido:99_annexes:annex-b-terms-and-definitions:l:logical_policy_constraints|policy constraints]] near protected actions, request policy decisions from replicated decision capabilities, obtain attributes from policy information sources, receive policy baselines from policy administration capabilities, and record obligations, release actions, and [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] through audit and provenance relationships.
  
-This principle supports data sovereignty and data residency. Full transaction detail may remain within an authorised local, institutional, national, or other residency domain, while authorised metadata, aggregate summaries, derived indicators, redacted views, masked views, exception views, or recipient-specific release products may move across boundaries under policy control.+This principle supports data sovereignty and data residency. Full transaction detail may remain within an authorized local, institutional, national, or other residency domain, while authorized metadata, aggregate summaries, derived indicators, redacted views, masked views, exception views, or recipient-specific release products may move across boundaries under policy control.
  
-The Logical Architecture defines these responsibilities at the PIM level. Later implementation profiles may realise them using DDS topics, APIs, gateways, policy engines, caches, services, or other mechanisms, but those mechanisms do not define the logical architecture.+The Logical Architecture defines these responsibilities at the PIM level. Later implementation profiles may realize them using DDS topics, APIs, gateways, policy engines, caches, services, or other mechanisms, but those mechanisms do not define the logical architecture.
  
 ---- ----
  • fxdemo/02-part/04-logical-architecture-principles/04-8-policy-governed-sharing-without-centralised-data-routing/start.1783793235.txt.gz
  • Last modified: 2026/07/11 11:07
  • by nick_dido