deliverable-ingest

Deliverable Ingest (Connect)

Purpose

Normalize a draft deliverable and its support pack into ps.deliverable-review-quality-gate.v1: deliverable metadata, explicit recipients, located assertions, evidence items, prior findings, provenance and citations.

When to use

Start every Deliverable Review & Quality Gate flow here, especially for requests to review a deliverable, check the evidence pack, find unsupported claims or prepare a quality-gate review.

Inputs

• Draft deliverable from an engagement workspace or SharePoint.
• Supporting evidence index: models, extracts, minutes, signed client data, workshop notes, prior analysis and third-party content records.
• Intended recipient list, disclaimer block and prior review notes when supplied.

Steps

1. Retrieve inputs read-only; never modify source files.
2. Capture recipients exactly. If recipients are absent or ambiguous, record that state for gate-check; do not guess names, addresses or allowed users.
3. Extract candidate assertions with section, page, paragraph and label, quoting the assertion text from its paragraph. Take page from the source's page breaks, or from [Page N] markers in a text extract. Number paragraphs from 1 on each page: a paragraph is a block of body text separated by a blank line, and headings, page markers and blank lines are not paragraphs. If a source is unpaginated, use page: 1 for every location, number paragraphs from 1 from the top of the document (still skipping headings), preserve the section and label, and include a missing-source note that page numbers were not present. page and paragraph are integer physical positions counted from 1 (0 and negative numbers are input errors); keep printed labels such as roman-numeral front-matter pages (iv) in label.
4. Classify assertions as factual, quantified, forward-looking or recommendation, and set scope_aligned (true/false, required on every assertion) from the signed SOW/evidence boundary; set sample_size on every recommendation (null when not sample-based). Take sample_size and population_size only from figures stated in the assertion's paragraph or its linked evidence entries; leave them null otherwise. Type every evidence item with one of the contract's evidence type values; do not decide support or severity.
5. Record deliverable_id, title, version, type, confidentiality_marking, client_name (and any client_aliases) from the deliverable cover so recipients can be positively matched to the client. Take intended_recipients exactly from the distribution list or named recipients; never complete or rename them. Set third_party_recipient_named (required; true whenever any recipient is outside the client entity), then required_disclaimer_type (reliance_restriction when a third party is named, otherwise general_advice). Take present_disclaimer_types and present_language only from disclaimer and limitation text actually in the draft, such as a Disclaimer - general advice clause. Set client_data_handling from the client-data register, using unknown when no register is supplied or it cannot confirm handling. Load brand_checks and licensed_content from their registers; when a register is not supplied, leave the field absent (never []). Use [] only when the register explicitly states it has no entries (for example No licensed or third-party content.); a placeholder or prose line such as TBD is not a register entry and never an empty register, so treat that register as not supplied (field absent) and add a missing-source note. criteria-retrieve verifies these fields; it does not own the first extraction.
6. Seed criteria before criteria-retrieve runs: criteria_set_id comes from the criteria extract header (for example Criteria set ID: PS-QRM-DG-2026-demo), and criteria_sections starts as the shipped floor ["quality-gate-criteria.md #1-#8", "severity-rules.md #1-#4"]. criteria-retrieve compares the floor with the engagement extract and may add stricter sections, but never removes floor sections.
7. Preserve every source as provenance in the exact form connector:<slug> or skill:<skill-name>: a lower-case prefix, a colon and a lower-case slug of letters, digits, -, _ or . with no spaces, for example connector:sharepoint, connector:engagement-workspace or skill:deliverable-ingest (evidence extracted by this skill). Evidence without this provenance cannot support any assertion (quality-gate-criteria.md #1.5). Every assertion and the deliverable also carry source in this form (normally skill:deliverable-ingest), and deliverable.deliverable_id is required. Every location needs a non-blank label, and a provenance object, if you write one, needs engines (an empty array before any engine runs) and an ISO-8601 generated_at (quality-gate-criteria.md #8.14). When a source record (an evidence item, prior finding, brand check, licensed-content entry, assertion or reviewer finding) names the engagement, deliverable or client it belongs to, carry that as the entry's engagement_id, deliverable_id or client exactly as written; never drop or rewrite it to match this review. An entry of another engagement, deliverable or client is held and never used, and the engines show none of its contents, only its position; another subject named anywhere else in the payload (criteria, provenance, other deliverable or top-level members) is refused (quality-gate-criteria.md #8.15). The engines refuse a payload that breaks the contract. Pass the full payload to criteria-retrieve, then assertion-map.