{"id":"briefing-package","slug":"briefing-package","title":"Briefing Package","description":"An analyst investigating a cross-border financial crime network has assembled evidence about three corporate entities and two individuals. They need to share a concise intelligence summary with a partner agency without g","category":"intelligence","tags":["intelligence","compliance"],"lastModified":"2026-04-14","source_ref":"content/modules/briefing-package.md","url":"/developers/briefing-package","htmlPath":"/developers/briefing-package","jsonPath":"/api/docs/modules/briefing-package","markdownPath":"/api/docs/modules/briefing-package?format=markdown","checksum":"fa662e947f96db8197c10b4fe8348c598bfd82859005c6702fbc3d10eb546f8a","headings":[{"id":"overview","text":"Overview","level":2},{"id":"key-features","text":"Key Features","level":2},{"id":"use-cases","text":"Use Cases","level":2},{"id":"integration","text":"Integration","level":2},{"id":"open-standards-compliance","text":"Open Standards Compliance","level":2}],"markdown":"# Briefing Package\n\n## Overview\n\nAn analyst investigating a cross-border financial crime network has assembled evidence about three corporate entities and two individuals. They need to share a concise intelligence summary with a partner agency without giving the partner access to the live investigation graph, without applying in-graph redaction, and without exporting the graph itself. The Briefing Package module solves this by letting the analyst compose a new, purpose-built document — a distinct object assembled from selected identifiers — that is published as a first-class artifact and shared on its own terms.\n\nA BriefingPackage is a **distinct, purpose-built data artifact assembled from selected entities and relationship references and published as a new document object encoded in W3C JSON-LD**. It is never a \"redacted version\" of an existing graph. The analyst chooses which entity identifiers to include; the service fetches the corresponding records from PostgreSQL, constructs a new JSON-LD document, and stores that document as a first-class object with its own lifecycle (DRAFT → PUBLISHED → ARCHIVED). The live graph is never modified. No in-graph redaction is applied at any stage.\n\n```mermaid\ngraph LR\n    A[Analyst selects entity IDs] --> B[BriefingPackageCreator UI]\n    B --> C[createBriefingPackage mutation]\n    C --> D[BriefingPackageService]\n    D --> E[Fetch entity rows from PostgreSQL]\n    E --> F[Assemble W3C JSON-LD artifact]\n    F --> G[Store as new BriefingPackage row]\n    G --> H[DRAFT artifact]\n    H --> I[publishBriefingPackage mutation]\n    I --> J[PUBLISHED artifact]\n    J --> K[Partner receives JSON-LD document]\n    K --> L[Consume via standard JSON-LD tooling]\n```\n\n**Last Reviewed:** 2026-04-14\n**Last Updated:** 2026-04-14\n\n## Key Features\n\n- **Assembled Artifact, Not Redacted Graph**: The analyst selects entity and relation identifiers; the system assembles a new W3C JSON-LD document from those references. The live graph is never modified, filtered, or exported. There is no in-graph redaction step.\n\n- **W3C JSON-LD Export Format**: Every BriefingPackage is encoded as a W3C JSON-LD document using the `https://knogin.com/ns/argus#` vocabulary. Each selected entity becomes a typed `@graph` node. Partners can consume the artifact with any standards-compliant JSON-LD processor without requiring Argus tooling.\n\n- **Lifecycle Management**: Packages progress through a defined lifecycle: DRAFT (assembled, not yet shared) → PUBLISHED (available to permitted parties) → ARCHIVED (retired). Only DRAFT packages can be published. Lifecycle transitions are recorded with timestamps and logged to the immutable audit trail.\n\n- **Visibility Controls**: Each package carries a visibility setting — PRIVATE (creator only), INTERNAL (organization members), or SHARED (explicitly permitted external parties). Visibility is distinct from lifecycle status and can be set at creation.\n\n- **Full Organization Isolation**: Every database query, service method, and GraphQL resolver is scoped to `organization_id`. Cross-organization access is not possible through this module. All resolvers require `ensure_ontology_access` permission checks on the `briefing_package` object type.\n\n- **Audit Trail**: Every read and write operation — create, publish, archive, list, view — is logged to the Argus audit trail with `userId`, `organizationId`, `action`, `resourceId`, and `timestamp`. This satisfies EDF-2026-DA-EXP-DIGIT-MDOC compliance requirements for multi-national data sharing audit trails.\n\n- **Progressive Disclosure UI**: The BriefingPackageCreator presents a task-first guided form: title and description first, then entity identifiers, then a live JSON-LD preview that updates as the analyst types. The analyst sees exactly what will be published before committing.\n\n## Use Cases\n\n- **Partner Agency Briefing**: Share a curated intelligence summary with a partner agency encoded in a portable, standards-compliant JSON-LD document, without granting access to the live investigation.\n- **Command-Level Summary**: Assemble a strategic briefing from key entities for a commander who requires a read-only snapshot rather than live graph access.\n- **Evidence Export for Legal Proceedings**: Package selected entity records as a structured, auditable artifact for use in legal or regulatory proceedings.\n- **Cross-Domain Intelligence Sharing**: Publish a SHARED-visibility package for consumption by coalition partners operating in separate Argus tenants under a Community of Interest arrangement.\n- **Archival Record**: Produce a point-in-time artifact that records which entities were assessed as significant at a given moment in an investigation, preserving the analytical judgment independently of future graph changes.\n\n## Integration\n\n- **Investigation Domain**: Analysts navigate from an active investigation to the Briefing Packages module to compose a package from investigation-linked entity IDs.\n- **Entity Profiles**: Entity IDs passed to `createBriefingPackage` are resolved against the `profiles` table (PostgreSQL, scoped to `organization_id`) to populate the JSON-LD `@graph` nodes.\n- **Audit Trail**: All BriefingPackage operations are logged to the platform-wide immutable audit trail for EDF/PESCO compliance.\n- **Sharing Domain**: A published BriefingPackage can be referenced in a `CrossAgencyShare` record to deliver it to a partner tenant via the cross-agency sharing workflow.\n- **GraphQL API**: Full CRUD exposure via three queries (`briefingPackage`, `listBriefingPackages`) and three mutations (`createBriefingPackage`, `publishBriefingPackage`, `archiveBriefingPackage`).\n\n## Open Standards Compliance\n\nThe BriefingPackage module implements **W3C JSON-LD** ([https://www.w3.org/TR/json-ld/](https://www.w3.org/TR/json-ld/)) as its export format. JSON-LD is a W3C Recommendation that provides a standardised, self-describing, machine-readable serialisation of linked data using JSON. Each BriefingPackage is encoded as a JSON-LD document using the `https://knogin.com/ns/argus#` vocabulary. Consumers do not require Argus tooling to process BriefingPackage artifacts; any conformant JSON-LD processor can parse them.\n"}