privacy/workstreams/bandi-agevolazioni.json

{
  "schema_version": 3,
  "workstream": "bandi-agevolazioni",
  "display_name": "Bandi e agevolazioni",
  "role": "workflow",
  "governed_paths": [
    "skills",
    "scripts",
    "schemas"
  ],
  "governed_shared_paths": [
    "vendor/modules/vera_assurance"
  ],
  "runtime_profiles": [
    "openai-codex",
    "anthropic-cowork"
  ],
  "model_context": {
    "policy": "real_case_data_may_enter_selected_runtime_model_context",
    "classes": [
      {
        "id": "radar-client-evidence-mapping",
        "purpose": "Create one dated, reviewable opportunity profile for an opaque client reference",
        "content": "One client-specific model phase may read the exact client evidence selected for profile mapping. It can therefore see identity, territory, ATECO, size, legal form, age, ownership, planned investment, property, workforce, energy, digitization, vehicle, export, training, innovation, financial and project details present in those selected materials. It produces receipted evidence descriptions and dated structured facets with provenance. The later opaque client reference reduces direct identity exposure but is not automatic anonymization or general pseudonymization, and combinations of structured facets may still identify the client.",
        "runtime_profiles": [
          "openai-codex",
          "anthropic-cowork"
        ]
      },
      {
        "id": "radar-public-source-and-portfolio-reasoning",
        "purpose": "Plan official-source checks, interpret public opportunities, and match them against the selected portfolio",
        "content": "A separate model phase receives opaque client references, the structured profile facets, public source-plan metadata, official opportunity material, lifecycle observations, match rationales, missing information, contradictions, complexity and any supplied economic assumptions. It does not receive the clients' raw evidence documents from the mapping phase. Public retrieval queries contain generic territory, category, investment topic, programme, authority, act family, call identifier and date-window terms; they do not contain client references or profile content.",
        "runtime_profiles": [
          "openai-codex",
          "anthropic-cowork"
        ]
      },
      {
        "id": "codex-application-instruction",
        "purpose": "Prepare a source-bound application dossier in a Studio Archive run",
        "content": "Source interpretation and requirement drafting may read the exact selected official source files, and evidence mapping may read the exact selected client evidence. Later model contributions receive only a task-allowlisted, reference-closed packet from the bound run: application title, issuing authority, procedure ID, deadline and status; project title, summary, requested amount and currency outside source-only tasks; selected source metadata and exact stored excerpts; and, as the task requires, requirements, company, financial, quotation, declaration and project facts, assessments, document-checklist items, expenses, form fields, narratives, consistency checks, issues and authority-simulation checks. The ordinary packet includes the complete required structured collections. It is limited to 500 items per collection, 200 stored excerpts and 2,000,000 bytes; it fails instead of truncating and can be rerun in a fresh session with exact professional-selected IDs for each over-limit collection. The intake applicant object and local paths are omitted by default, but professionally relevant facts, excerpts, form values or checks may contain exact identity. There is no automatic anonymization or pseudonymization.",
        "runtime_profiles": [
          "openai-codex"
        ]
      },
      {
        "id": "cowork-application-instruction",
        "purpose": "Prepare a reviewable application dossier from user-connected files",
        "content": "Cowork uses the portable Studio Archive run and the same bundled selected-source, task-packet, exact-ID expansion, hash and operator-attested session-reference controls as Codex. If code execution is unavailable, the workflow does not claim that those controls ran or that durable artifacts were created; it does not substitute an unbounded connected-file analysis. There is no automatic anonymization or pseudonymization.",
        "runtime_profiles": [
          "anthropic-cowork"
        ]
      },
      {
        "id": "approved-portal-preparation",
        "purpose": "Prepare and verify an approved application draft",
        "content": "Available host browser tools expose the selected application screens, applicant identity, approved field values, project details, attachment names and visible validation or save results to the selected model runtime. The workflow does not request or record authentication secrets. It writes approved values and approved attachment files to the official portal after the user chooses this route. There is no automatic anonymization.",
        "runtime_profiles": [
          "openai-codex",
          "anthropic-cowork"
        ]
      },
      {
        "id": "readable-local-dossier",
        "purpose": "Review the generated application dossier against its bound evidence",
        "content": "The generated local HTML dossier displays the selected intake, source links, recorded requirements, facts, assessments, expenses, form and narrative material, consistency and authority-simulation checks. Reading that complete report supplies its visible case content to the selected model; it is separate from the bounded task-packet interface. The renderer performs no network request or publication.",
        "runtime_profiles": [
          "openai-codex",
          "anthropic-cowork"
        ]
      }
    ]
  },
  "external_boundaries": [
    {
      "id": "official-public-research",
      "kind": "public_research",
      "destination": "Direct official national, regional, local, chamber, EU, sectoral, issuing-authority, official-gazette, act-repository, funding-program and FAQ sources selected for an opportunity radar or call; general semantic web search only after priority-source attempts",
      "purpose": "Discover and monitor opportunities source-first across an explicit temporal window, including relevant DGR, DDR, BUR, annex and amendment publications, while recording registry coverage and provenance without disclosing client data",
      "content": "Generic territory, activity, investment topic, call identifier, authority, act family, program and temporal-window query; public document metadata, lifecycle observations, last-seen public publication cursor and official URLs; no client identifiers, opaque client references, financial data, project narrative, quotations, declarations, credentials, or portal-session material",
      "optional": true,
      "requires_confirmation": false,
      "runtime_profiles": [
        "openai-codex",
        "anthropic-cowork"
      ],
      "controls": [
        "Use only official public sources and generic territory, activity, investment-topic, program or call-level queries; keep opaque client references, profiles, applicant and project facts inside the selected runtime context.",
        "Keep public research read-only and do not use login, upload, contact, assistance, form-save, signature, payment, or submission routes.",
        "Use a model-led, professionally reviewed query-scoped selection from the priority-source registry; disclose one covered-or-gap claim for every requested territory and category, then inspect each selected institutional URL and relevant underlying act for the requested window before complementary semantic web search.",
        "Record each planned source and actual check separately; failed, unavailable, missing and unreviewed priority sources remain explicit and block a complete scan, while full registry coverage never claims exhaustive discovery.",
        "Keep source cursors, scan snapshots and coverage history in the owner-only private radar workspace; send only the public act identifier, date or URL needed for read-only source retrieval.",
        "Register exact selected source bytes and metadata before using them for confirmed requirements."
      ]
    },
    {
      "id": "approved-portal-draft",
      "kind": "external_connector",
      "destination": "The official application portal and exact applicant draft chosen by the user",
      "purpose": "Enter approved fields, upload approved attachments, save a draft and, after separate explicit final approval, submit the exact application",
      "content": "Approved applicant and project values and approved attachment files; private run records retain destination without query or session material, approved scope hash and observed action results",
      "optional": true,
      "requires_confirmation": true,
      "runtime_profiles": [
        "openai-codex",
        "anthropic-cowork"
      ],
      "controls": [
        "The user approves the project and requests portal preparation; existing explicit authorization suffices without repeated per-field confirmation.",
        "The user authenticates. Inspect destination, applicant, draft and each control effect before writing; stop for new decisions or unclear effects.",
        "Preparation approval permits ordinary fields, approved uploads and draft saving. Submission requires explicit approval after showing the exact final portal summary. Authentication, declaration acceptance, signature and payment remain manual, including combined controls.",
        "Verify visible values, attachment list and draft-save result. Host tool availability is checked; no bundled portal driver or universal portal compatibility is claimed.",
        "After submission inspect status and receipt/protocol; uncertain results require inspection before retry, never an automatic duplicate submission."
      ]
    }
  ],
  "security_controls": [
    {
      "id": "private-workspace-and-bound-case-folder",
      "control": "When the local workflow scripts are used, pre-client radar initialization requires explicit user confirmation, records asserted operator and retention ownership, binds owner-only files to one exact local path, and rejects Git or published roots. In Codex and Cowork, application initialization, source registration, review, validation, and packaging require a digest-valid Studio Archive bandi-agevolazioni context, accept files only from its exact run boundary, and write generated artifacts only inside its output root. Without that valid context the workflow stops and cannot claim this bound-run control."
    },
    {
      "id": "reject-secret-and-session-material",
      "control": "Exhaustive JSON Schema validation rejects unknown artifact fields; a recursive normalized-key guard rejects credential/session field classes; and narrow value patterns block unmistakable passwords, bearer or session tokens, API secrets and private-key material before a structured model packet, radar proposal or dossier can pass. The value guard is not a generic personal-data detector and does not remove names, tax identifiers or other professionally relevant facts."
    },
    {
      "id": "portal-preparation-record-contract",
      "control": "Run-state schema distinguishes draft actions from submission attempts. Submission requires a separate explicit_final_submission_confirmation record, approved scope hash, destination, final review and observed result. Validator rejects stale scope hashes and mismatched preparation/submission destinations; ready_to_file and signature flags stay false. These are artifact checks, not authenticated browser execution or an authorization engine."
    },
    {
      "id": "crash-safe-case-mutation-lock",
      "control": "Mutating commands use a non-blocking operating-system file lock on an owner-only regular file on POSIX and Windows; the operating system releases the lock when a process exits, while concurrent writers fail closed."
    },
    {
      "id": "sealed-review-package",
      "control": "Validation and packaging hold the same case lock across one atomic state snapshot; packaging rechecks canonical state hashes after rendering, rejects any change, and records byte hashes for every input JSON artifact, the validation audit, and the rendered dossier."
    },
    {
      "id": "explicit-review-confirmation",
      "control": "A review event is recorded only after the caller supplies explicit user confirmation; the event marks the reviewer identity as locally asserted and not authenticated, so the dossier cannot misrepresent identity assurance."
    },
    {
      "id": "sealed-model-contribution-boundary",
      "control": "In Codex and Cowork, each model contribution uses a task-specific input allowlist and exact subject/reference closure, publishes included and omitted class counts and bytes, and fails rather than truncating above 500 items per collection, 200 stored excerpts or 2,000,000 packet bytes. Exact professional-selected IDs scope an over-limit global collection while the other required collections remain complete. Recording requires the digest of the exact packet supplied to the model and rejects a reconstructed scope or projected-content mismatch before mutating the register. Digest equality is caller-attested packet identity, not proof of provider receipt. The contribution is sealed with exact input and packet hashes, model and prompt-template identity and a fresh operator-attested model-session reference; code rejects reuse of that reference across contributions, while explicitly not treating it as provider-authenticated identity. An insufficient packet stops without substantive recommendations and requests an exact expansion in another fresh session. Every suggestion starts as MODEL_SUGGESTED, requires explicit professional disposition, cannot overwrite confirmed or blocked work, becomes stale when authoritative inputs change, and enters the workbench only as proposed through a crash-recoverable two-phase write."
    },
    {
      "id": "opaque-portfolio-radar-boundary",
      "control": "The private portfolio radar accepts only opaque client references, closes document-observed facets to same-client receipted evidence, prevents one match from citing another client's evidence or profile facet, and rejects reuse of one client-evidence mapping session reference for another client. Public-source planning, discovery and portfolio matching must use session references separate from every client-evidence mapping session in either direction, so those phases operate on opaque structured profiles and public opportunity material rather than inherited raw client documents. The references are operator-attested, not provider-authenticated. The radar records exact provider and model provenance, requires fresh explicit professional review, and never sends client references or profile content in public discovery queries or contacts a client."
    },
    {
      "id": "sealed-radar-handoff",
      "control": "A radar handoff requires fresh confirmed profile evidence, profile, checked source-plan entries, source-check results, opportunity and match; contains only the selected client's subset; seals that embedded selection and its source entries with recomputable hashes; and is schema-, hash-, identity-, and reference-validated again before registration in one client-bound Studio Archive run."
    },
    {
      "id": "source-first-coverage-gate",
      "control": "Each recent discovery scan binds an exact model-provenanced and professionally reviewed query-scoped source selection, one covered-or-gap claim for every requested territory and category, the selected-source registry revision and temporal window; it records immutable per-source check snapshots and optional public publication cursors, prevents semantic web research from preceding selected priority-source attempts, and rejects a complete outcome while the selection is unreviewed, a scope gap remains, or any selected priority source is failed, unavailable, missing or unreviewed."
    },
    {
      "id": "gazette-issue-inventory",
      "control": "Gazette source checks marked checked require an operator-supplied, professionally reviewed issue inventory: official index URLs, enumeration time and window, each issue URL and publication date, inspection status and timestamp, public act URLs and notes. Schema, unique IDs, date consistency and complete declared issue coverage are checked mechanically and included in review hashes and sealed scan snapshots. Code does not authenticate retrieval or decide semantic relevance."
    },
    {
      "id": "chatgpt-public-discovery-boundary",
      "control": "The shared institutional-discovery method also governs ChatGPT public research. Public source text, generic scope, registry metadata and issue evidence may enter the selected OpenAI ChatGPT account model context; Vera is not a separate recipient and does not enforce account retention or training controls. Without execution or storage, the response discloses that local schema validation, hash-bound review, workspace isolation and durable persistence did not run. Without browsing, current coverage remains partial. No private client profiles or identifiers enter public retrieval queries. The named runtime profiles in this register describe the local Codex and Cowork paths; they do not certify ChatGPT runtime controls."
    }
  ],
  "review": {
    "reviewed_at": "2026-09-28",
    "reviewed_by": "privacy-surface-review",
    "basis": "external_boundary_review_of_workflow_source",
    "source_fingerprint": "c9e4682436e9fc08760b0cd594937d32338131fbc409b3b4600a457c87fb9b9f"
  }
}