GovOPlaN/govoplan
1
0
Fork 0
Code Issues 10 Pull Requests Actions 3 Packages Projects Releases Wiki Activity

[User Story] Screen persons and organizations against versioned sanctions and embargo sources #12

New Issue
Open
opened 2026-07-20 15:13:23 +02:00 by zemion · 2 comments
zemion commented 2026-07-20 15:13:23 +02:00
Owner
Copy Link

User Story

As an export-control or compliance reviewer responsible for a governed action, I want persons, organizations, and relevant destination jurisdictions screened against configured sanctions and embargo sources, so that potential restrictions stop or enter review before the action proceeds and every result remains reproducible, contestable, privacy-aware, and auditable.

Product Scope

This is a product-level GovOPlaN capability and is deliberately independent of any single operational module or Workflow. The implementation must expose an explicit, permissioned screening and evidence contract. Concrete consumers, triggering contexts, and module ownership are separate integration decisions; no domain record is screened or blocked implicitly.

Ownership Boundary

The GovOPlaN meta backlog owns this user story and its cross-system contract. The eventual implementation boundary must cover source registration and immutable snapshots, normalized entries and aliases, screening runs and candidates, review dispositions and exceptions, freshness and reconciliation policy, evidence references, and reviewer-facing interfaces. The concrete repository/module composition is intentionally undecided. Existing domain modules retain ownership of their records; audit and retention remain governed platform capabilities.

Acceptance Criteria

  • Each source snapshot records publisher, jurisdiction/list type, source ID, publication/effective/acquisition time, version, checksum or signature evidence, parser version, connector run, trust/licence metadata, and retained raw evidence where policy permits.
  • Source snapshots are immutable; every screening result pins the exact snapshot set and refreshing a source never rewrites historical results.
  • A screening request uses a minimal explicit snapshot of a person, organization, or destination, with tenant, purpose, originating resource reference, subject fingerprint, and normalization version.
  • Runs record matcher and policy versions, thresholds, source snapshots, input fingerprint, candidate evidence, and a deterministic idempotency key.
  • Results distinguish clear, potential_match, confirmed_match, false_positive, insufficient_data, source_stale, and source_unavailable; a fuzzy score alone never declares a legal match.
  • Candidate explanations identify contributing fields without exposing unrelated source or subject data.
  • Potential matches enter human review. No ambiguous subject is silently excluded or accepted.
  • False-positive and exception decisions record actor, authority, reason, evidence, scope, list record, subject fingerprint, expiry/review time, and supersession history; they become stale after relevant subject, source, or policy changes.
  • Refresh reconciliation identifies subjects requiring rescreening without altering completed historical evidence.
  • Tenant policy defines required contexts, freshness, unavailable-source behavior, separation of duties, and which dispositions may unblock a governed action.
  • Every future integration explicitly declares its trigger, subject mapping, invalidation rules, blocking or degraded behavior, freshness check, evidence reference, and authorized override path.
  • Source changes, screenings, dispositions, overrides, invalidations, gate decisions, and reconciliation emit audit evidence.
  • Scopes separate source administration, screening execution, review, override, and reporting.
  • Logs, diagnostics, notifications, and exports minimize or redact personal data; external providers receive subject data only when explicitly configured and their disclosure and provenance are visible.
  • Synthetic-list tests cover idempotency, tenant isolation, stale and unavailable sources, false-positive expiry, subject or source changes, authorization, privacy-safe logging, fail-closed and review behavior, and deterministic historical reproduction.

Reference Constraints

GovOPlaN therefore stores source and version provenance and supports review; it must not present automated matching as a legal conclusion.

Out Of Scope For The First Slice

Goods or technology classification, export-licence determination, end-use legal conclusions, customs filings, and automated declarations based only on fuzzy matching.

Deferred Status

Deferred by product decision on 2026-07-20. Do not start implementation until GovOPlaN has selected connector/provider boundaries for authoritative list sources, event or webhook contracts for rescreening and consuming systems, and the applicable privacy, retention, legal, and review policies. The story remains in the meta repository as the cross-system capability contract; no Campaign-specific implementation is implied.

Decisions Needed Before Live-Data Rollout

  • Authoritative publishers, jurisdictions, and source licensing.
  • Whether external screening services may receive subject data.
  • Initial subject fields, normalization, thresholds, and review policy.
  • Which governed actions and integration contexts require screening.
  • Override authority, separation of duties, and exception expiry.
  • Lawful basis and retention periods for subject snapshots and evidence.
## User Story As an export-control or compliance reviewer responsible for a governed action, I want persons, organizations, and relevant destination jurisdictions screened against configured sanctions and embargo sources, so that potential restrictions stop or enter review before the action proceeds and every result remains reproducible, contestable, privacy-aware, and auditable. ## Product Scope This is a product-level GovOPlaN capability and is deliberately independent of any single operational module or Workflow. The implementation must expose an explicit, permissioned screening and evidence contract. Concrete consumers, triggering contexts, and module ownership are separate integration decisions; no domain record is screened or blocked implicitly. ## Ownership Boundary The GovOPlaN meta backlog owns this user story and its cross-system contract. The eventual implementation boundary must cover source registration and immutable snapshots, normalized entries and aliases, screening runs and candidates, review dispositions and exceptions, freshness and reconciliation policy, evidence references, and reviewer-facing interfaces. The concrete repository/module composition is intentionally undecided. Existing domain modules retain ownership of their records; audit and retention remain governed platform capabilities. ## Acceptance Criteria - [ ] Each source snapshot records publisher, jurisdiction/list type, source ID, publication/effective/acquisition time, version, checksum or signature evidence, parser version, connector run, trust/licence metadata, and retained raw evidence where policy permits. - [ ] Source snapshots are immutable; every screening result pins the exact snapshot set and refreshing a source never rewrites historical results. - [ ] A screening request uses a minimal explicit snapshot of a person, organization, or destination, with tenant, purpose, originating resource reference, subject fingerprint, and normalization version. - [ ] Runs record matcher and policy versions, thresholds, source snapshots, input fingerprint, candidate evidence, and a deterministic idempotency key. - [ ] Results distinguish `clear`, `potential_match`, `confirmed_match`, `false_positive`, `insufficient_data`, `source_stale`, and `source_unavailable`; a fuzzy score alone never declares a legal match. - [ ] Candidate explanations identify contributing fields without exposing unrelated source or subject data. - [ ] Potential matches enter human review. No ambiguous subject is silently excluded or accepted. - [ ] False-positive and exception decisions record actor, authority, reason, evidence, scope, list record, subject fingerprint, expiry/review time, and supersession history; they become stale after relevant subject, source, or policy changes. - [ ] Refresh reconciliation identifies subjects requiring rescreening without altering completed historical evidence. - [ ] Tenant policy defines required contexts, freshness, unavailable-source behavior, separation of duties, and which dispositions may unblock a governed action. - [ ] Every future integration explicitly declares its trigger, subject mapping, invalidation rules, blocking or degraded behavior, freshness check, evidence reference, and authorized override path. - [ ] Source changes, screenings, dispositions, overrides, invalidations, gate decisions, and reconciliation emit audit evidence. - [ ] Scopes separate source administration, screening execution, review, override, and reporting. - [ ] Logs, diagnostics, notifications, and exports minimize or redact personal data; external providers receive subject data only when explicitly configured and their disclosure and provenance are visible. - [ ] Synthetic-list tests cover idempotency, tenant isolation, stale and unavailable sources, false-positive expiry, subject or source changes, authorization, privacy-safe logging, fail-closed and review behavior, and deterministic historical reproduction. ## Reference Constraints - The [European Commission sanctions overview](https://finance.ec.europa.eu/eu-and-world/sanctions-restrictive-measures/overview-sanctions-and-related-resources_en) states that its consolidated financial-sanctions list reflects adopted legal texts and is updated as needed. - The [UN Security Council consolidated list](https://main.un.org/securitycouncil/en/content/un-sc-consolidated-list) is published in XML, HTML, and PDF and distinguishes persons/entities and the measures of each sanctions regime. - [BAFA's embargo guidance](https://www.bafa.de/DE/Aussenwirtschaft/Ausfuhrkontrolle/Embargos/embargos.html) explains that search lists are aids, binding legal texts remain authoritative, and suspected name matches require review using additional identifiers. GovOPlaN therefore stores source and version provenance and supports review; it must not present automated matching as a legal conclusion. ## Out Of Scope For The First Slice Goods or technology classification, export-licence determination, end-use legal conclusions, customs filings, and automated declarations based only on fuzzy matching. ## Deferred Status Deferred by product decision on 2026-07-20. Do not start implementation until GovOPlaN has selected connector/provider boundaries for authoritative list sources, event or webhook contracts for rescreening and consuming systems, and the applicable privacy, retention, legal, and review policies. The story remains in the meta repository as the cross-system capability contract; no Campaign-specific implementation is implied. ## Decisions Needed Before Live-Data Rollout - Authoritative publishers, jurisdictions, and source licensing. - Whether external screening services may receive subject data. - Initial subject fields, normalization, thresholds, and review policy. - Which governed actions and integration contexts require screening. - Override authority, separation of duties, and exception expiry. - Lawful basis and retention periods for subject snapshots and evidence.
zemion commented 2026-07-20 16:42:22 +02:00
Author
Owner
Copy Link

Product decision (2026-07-20): defer the complete export-control/sanctions capability for now. The missing prerequisites are source-system connectors/providers, webhook or event integration contracts, and governance decisions for live personal/compliance data. This remains the canonical meta user story and is not Campaign work.

Product decision (2026-07-20): defer the complete export-control/sanctions capability for now. The missing prerequisites are source-system connectors/providers, webhook or event integration contracts, and governance decisions for live personal/compliance data. This remains the canonical meta user story and is not Campaign work.
zemion commented 2026-07-28 00:58:11 +02:00
Author
Owner
Copy Link

Product decision on 2026-07-28 supersedes the blanket deferred status: sanctions screening is now a P1 product stream.

Synthetic, domain-model, matcher, review-UI, and connector-contract work may begin now. Live-source rollout and use as a blocking legal gate remain conditional on the listed source/licensing/privacy/retention/reviewer-policy decisions.

This preserves the legal safeguards while allowing implementation to progress.

Product decision on 2026-07-28 supersedes the blanket deferred status: sanctions screening is now a P1 product stream. Synthetic, domain-model, matcher, review-UI, and connector-contract work may begin now. Live-source rollout and use as a blocking legal gate remain conditional on the listed source/licensing/privacy/retention/reviewer-policy decisions. - P1 Risk Compliance epic: https://git.add-ideas.de/GovOPlaN/govoplan-risk-compliance/issues/2 - P1 immutable source acquisition: https://git.add-ideas.de/GovOPlaN/govoplan-connectors/issues/10 - Supporting Dataflow foundation: https://git.add-ideas.de/GovOPlaN/govoplan-dataflow/issues/1 This preserves the legal safeguards while allowing implementation to progress. <!-- codex-sanctions-activation-2026-07-28 -->
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
HTTP API contracts, routers, schemas, or API smoke behavior.
area/auth
Authentication, sessions, access bootstrap, or login behavior.
area/db
Database sessions, models, transactions, or persistence primitives.
area/devex
Local developer workflow, scripts, tests, tooling, or release helpers.
area/docs
Durable documentation and project guidance.
area/governance
Governance policy, audit, privacy, retention, or compliance behavior.
area/marketing
Public website, product messaging, publication copy, or legal page content.
area/migrations
Alembic migrations, schema bootstrap, or persistence evolution.
area/module-system
Module discovery, manifests, capabilities, routing, or optional integrations.
area/rbac
Permissions, roles, delegation, or authorization policy.
area/release
Versioning, release locks, tags, packaging, or dependency pins.
area/security
Security posture, static analysis, supply-chain hardening, or vulnerability remediation.
area/tenancy
Tenant boundaries, provisioning, or tenant-scoped data behavior.
area/webui
Shared WebUI shell, frontend components, routing, or frontend tests.
audit/complexity
Complexity finding from Radon, Xenon, or equivalent maintainability scans.
audit/duplication
Duplicated-code finding from jscpd or equivalent similarity scans.
audit/false-positive
Audit finding reviewed as a narrow false positive or acceptable risk.
audit/needs-design
Audit finding that needs an architectural or product decision before implementation.
audit/quick-fix
Audit finding that appears narrow and directly fixable.
audit/structural
Audit finding that needs design, refactoring, or behavior review.
codex/needs-human
Needs an explicit human decision before Codex should implement.
codex/ready
Suitable for Codex to pick up with the existing issue context.
module/access
GovOPlaN access, identity, authentication, RBAC, and administration behavior.
module/addresses
GovOPlaN Addresses module behavior or integration.
module/admin
GovOPlaN Admin module behavior or integration.
module/appointments
GovOPlaN Appointments module behavior or integration.
module/audit
GovOPlaN Audit module behavior or integration.
module/calendar
GovOPlaN Calendar module behavior or integration.
module/campaign
GovOPlaN campaign module behavior or integration.
module/cases
GovOPlaN Cases module behavior or integration.
module/connectors
GovOPlaN Connectors module behavior or integration.
module/core
GovOPlaN core runner, shared primitives, shell, or extension points.
module/dataflow
GovOPlaN Dataflow module behavior or integration.
module/datasources
GovOPlaN governed datasource contracts, catalogs, and integrations.
module/dist-lists
GovOPlaN Distribution Lists module behavior or integration.
module/dms
GovOPlaN Dms module behavior or integration.
module/erp
GovOPlaN Erp module behavior or integration.
module/evaluation
GovOPlaN Evaluation module behavior or integration.
module/files
GovOPlaN files module behavior or integration.
module/fit-connect
GovOPlaN Fit Connect module behavior or integration.
module/forms
GovOPlaN Forms module behavior or integration.
module/identity
GovOPlaN Identity module behavior or integration.
module/identity-trust
GovOPlaN Identity Trust module behavior or integration.
module/idm
GovOPlaN Idm module behavior or integration.
module/ledger
GovOPlaN Ledger module behavior or integration.
module/mail
GovOPlaN mail module behavior or integration.
module/notifications
GovOPlaN Notifications module behavior or integration.
module/ops
GovOPlaN Ops module behavior or integration.
module/organizations
GovOPlaN Organizations module behavior or integration.
module/payments
GovOPlaN Payments module behavior or integration.
module/permits
GovOPlaN Permits module behavior or integration.
module/policy
GovOPlaN Policy module behavior or integration.
module/poll
GovOPlaN Poll module behavior or integration.
module/portal
GovOPlaN Portal module behavior or integration.
module/postbox
GovOPlaN Postbox module behavior or integration.
module/reporting
GovOPlaN Reporting module behavior or integration.
module/risk-compliance
GovOPlaN Risk Compliance module behavior or integration.
module/scheduling
GovOPlaN Scheduling module behavior or integration.
module/search
GovOPlaN Search module behavior or integration.
module/tasks
GovOPlaN Tasks module behavior or integration.
module/templates
GovOPlaN Templates module behavior or integration.
module/tenancy
GovOPlaN Tenancy module behavior or integration.
module/views
GovOPlaN governed task views, interface projections, and workflow view integration.
module/workflow
GovOPlaN Workflow module behavior or integration.
module/xoev
GovOPlaN Xoev module behavior or integration.
module/xrechnung
GovOPlaN Xrechnung module behavior or integration.
module/xta-osci
GovOPlaN Xta Osci module behavior or integration.
priority
p0
Immediate stop-the-line priority.
priority
p1
High priority for the next focused work window.
priority
p2
Normal planned priority.
priority
p3
Low priority or opportunistic cleanup.
source/backlog-import
Imported from markdown backlog, roadmap, plan, or TODO files.
source/security-audit
Created from a structured security or code-quality audit report.
source/todo-scan
Imported from inline TODO/FIXME/HACK markers by the Gitea TODO importer.
status
blocked
Cannot progress without a decision, dependency, credential, or external change.
status
in-progress
Currently being worked.
status
needs-info
Needs clarifying input before implementation can proceed safely.
status
ready
Ready for implementation.
status
triage
Needs review, ownership, priority, or acceptance criteria.
type
bug
A reproducible defect, regression, or incorrect behavior.
type
debt
Cleanup, refactoring, risk reduction, or deferred engineering work.
type
docs
Documentation, process, or developer workflow work.
type
feature
New user-visible behavior or platform capability.
type
task
Implementation, maintenance, migration, or operational work.
type
user-story
End-to-end user journey or real-world process story used to steer product slices.
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
zemion
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan#12
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?