Media Generation Pipeline
The Media Generation Pipeline is a proposed system for transforming daily operational content -- staff activity reports, program notes, and photos -- into polished communication materials such as daily highlights sheets, weekly magazines, and social media content. The system is designed so that RABS performs all editorial decision-making while external rendering services handle layout and typesetting.
1. Purpose
DSW collects substantial operational content every day through staff reports, shift notes, program observations, and photo uploads. This content currently lives in the application but is not systematically reused for communication or publication.
The media pipeline aims to convert this existing data into:
- daily highlights sheets (single-page PDF summaries)
- daily multi-page mini-booklets
- weekly magazine-style digests
- daily Facebook content
- daily Instagram content
- future promotional, archival, and family-facing materials
The key principle is that the pipeline should not require a separate heavy publishing workflow. It draws from data that is already being collected through normal operational activity.
2. Architecture Principle
RABS does the editorial thinking. The external service does the layout.
This means raw staff notes are never sent directly to a design platform. Instead, the system first:
- Collects and groups the raw material
- Chooses and ranks the best content
- Generates clean summaries
- Selects the strongest images (respecting consent flags)
- Builds structured sections
- Hands those structured fields to a rendering tool
The rendering tool's job is to typeset the day, not to understand it. This separation is what makes the architecture robust and vendor-independent.
3. System Layers
Layer A -- Source and Grouping
Responsible for:
- retrieving staff reports and shift notes
- retrieving matching photos from the gallery/media system
- filtering by consent and approval status
- grouping content by day, program, and location
Layer B -- Editorial Logic
Responsible for:
- cleaning and deduplicating raw wording
- identifying the strongest moments of the day
- selecting hero and supporting images
- generating overall day summaries and program-level summaries
- producing short captions and headings
- generating optional statistics blocks
- ordering sections logically
The output is a structured editorial payload, not raw notes.
Layer C -- Visual Rendering and Export
Responsible for:
- applying prebuilt templates
- fitting supplied content into layouts
- placing and cropping images
- handling single-page and multi-page output
- exporting PDF, image, or other required formats
- returning final files to RABS storage
Staff reports + Gallery photos
│
▼
Layer A: Source & Grouping
(collect, filter by consent, group by day/program)
│
▼
Layer B: Editorial Logic
(summarise, rank, select images, build sections)
│
▼
Structured Payload (JSON)
{ title, summary, hero_image, highlights[], programs[], stats }
│
▼
Layer C: Rendering Service (Placid / Bannerbear)
(apply templates, layout, export)
│
▼
Final Assets → RABS Storage
(storage/media/publications/YYYY/MM/)
4. Content Sources
The pipeline draws from materials already present in RABS or adjacent systems:
| Source | Data |
|---|---|
| Daily activity reports | Text summaries, observations, highlights |
| Shift/session notes | Staff observations, attendance |
| Program metadata | Program names, locations, types |
| Session counts | Attendance and participation data |
| Date and time | For grouping and titling |
| Tags | Outing, art, cooking, community access, achievement, event, celebration |
| Gallery photos | Images associated with the same day/program/location |
| Consent flags | Per-image consent and usage status |
| Staff member | Who submitted the report |
No separate content creation workflow is required. The pipeline reuses what operational staff are already producing.
Photo Selection Logic
Image matching for a given day's output should support:
- date matching (same day as the report)
- program matching (same program)
- location matching (same centre/venue)
- tag matching (activity tags align with report content)
- manual hero image override (staff can pin a specific image)
- consent/approval filtering (mandatory gate)
- exclusion of unsuitable or duplicate images
5. Editorial Payload Structure
Before anything reaches a rendering service, Layer B produces a clean structured payload. Example fields:
{
"date": "2026-04-21",
"document_type": "daily_highlights_booklet",
"title": "Today at DSW",
"subtitle": "Highlights across all programs",
"overall_summary": "Participants enjoyed a varied day across community access, creative activities, and social connection.",
"hero_image": "https://ourapp/images/hero.jpg",
"stats": {
"programs": 4,
"participants": 32,
"staff": 11
},
"highlights": [
{
"heading": "Community outing success",
"text": "Participants visited the local markets and practised budgeting, decision-making, and social confidence.",
"image": "https://ourapp/images/highlight1.jpg"
}
],
"program_sections": [
{
"program_name": "Liverpool Centre",
"summary": "A creative and social day with art, music, and group lunch.",
"images": [
"https://ourapp/images/liv1.jpg",
"https://ourapp/images/liv2.jpg"
]
}
],
"footer": "Disability South West Ltd"
}
The document_type field determines which template the renderer applies. The same editorial payload can produce multiple output types by varying this field.
This clean separation between editorial preparation and visual rendering is the most important design decision in the system.
6. Output Types
6.1 Daily Highlights Sheet
A one-page end-of-day summary. Printable, emailable, easy to archive.
Components: title/date, hero image, whole-day summary paragraph, 3-5 highlight items, optional quick stats, branded footer.
6.2 Daily Mini-Booklet
A richer multi-page daily summary across all programs. Magazine-style recap suitable for internal archive and selected stakeholder communication.
Components: cover page, overall day highlights, page per major program, image spreads, short captions, optional closing summary.
6.3 Weekly Magazine / Digest
A broader weekly summary with greater narrative depth. Suitable for showcase, management reporting, or family/community communication depending on content controls.
Components: weekly cover, intro summary, major moments of the week, section per program or theme, selected image sets, wins/milestones/notable activities, closing page.
6.4 Daily Facebook Post
Outward-facing branded update. Outputs: square or landscape asset, concise summary text, 1-3 highlight points.
6.5 Daily Instagram Post
Image-first daily highlight content. Outputs: square image, portrait story variant, brief caption generated from the editorial package.
6.6 Future Derivative Outputs
Once the pipeline is working, the same editorial payload can also feed: event flyers, participant spotlight cards, staff recognition cards, family newsletter inserts, monthly or annual recaps.
7. Rendering Service Evaluation
Placid
Currently the strongest first candidate for structured publication-like automation.
Strengths:
- daily highlights rendering
- multi-page PDF/booklet generation
- structured editorial automation
- template-driven layout
Recommended role: primary renderer for daily highlights and booklets.
Bannerbear
Strong for repeatable visual templates and social graphics.
Strengths:
- social-focused asset generation
- simple automated templates
- quick setup
Recommended role: social media output (Facebook/Instagram assets) or alternate renderer for direct comparison.
Canva
Remains under evaluation for nonprofit pricing and private integration eligibility. Canva is attractive for manual polish and ad-hoc editing but should not become the core automation dependency unless pricing is confirmed as viable.
Recommended role: optional manual finishing tool, not the core pipeline.
Adobe Express Embed SDK
Potential future option for richer embedded editing within the RABS admin interface.
VistaCreate API
Worth monitoring as an integration-first white-label alternative. Not currently a primary candidate.
8. Storage and Archive
Final outputs return to RABS storage in a predictable structure:
storage/media/publications/
├── daily-highlights/
│ └── 2026/04/2026-04-21-highlights.pdf
├── daily-booklets/
│ └── 2026/04/2026-04-21-booklet.pdf
├── weekly-digest/
│ └── 2026/w16-digest.pdf
├── facebook/
│ └── 2026/04/2026-04-21-fb.png
└── instagram/
└── 2026/04/2026-04-21-ig.png
Each output should include metadata alongside the file:
- generation date
- source date covered
- program coverage
- image count
- template used
- renderer used
- automation job ID
This ensures ownership, auditability, and no dependence on a vendor dashboard.
9. Quality Criteria
Any rendering tool must handle realistic real-world conditions:
- long staff notes (overflow handling)
- very short staff notes (graceful fallback)
- too many photos (selection and prioritisation)
- too few photos (placeholder or text-only layout)
- portrait photos in landscape areas (cropping)
- missing hero image (fallback)
- uneven coverage between programs
- one program dominating the day
A platform that handles these edge cases gracefully is more valuable than one that only looks good with ideal mock data.
Specific Test Cases
Any vendor comparison should include:
- short text (one-line report)
- long text (multi-paragraph report with overflow)
- missing hero image (fallback to text-only or placeholder)
- portrait image placed in a landscape slot
- landscape image placed in a portrait slot
- too many highlights (more than template can fit)
- not enough highlights (sparse day)
- one very strong program and several quiet ones
- uneven photo coverage across programs
10. Detailed Workflow
Step 1 -- Staff Input Captured
Staff submit daily activity reports, notes, or observations through the existing system. Associated data includes date, program, location, staff member, participant-safe highlights, attendance metadata, and activity tags.
Step 2 -- Image Sourcing
The system retrieves candidate photos from the gallery matching the same program/day. Consent filtering is applied before any images enter the editorial pipeline.
Step 3 -- Editorial Assembly
The app transforms raw content into structured editorial fields: title, subtitle, overall summary, 3-6 highlight blurbs, per-program mini-summaries, captions, hero image selection, image ranking, stats box, and footer text. The design platform should not receive messy raw staff notes.
Step 4 -- Rendering
A service such as Placid or Bannerbear receives the prepared payload and applies it to templates.
Step 5 -- Export and Save-back
Generated outputs are saved to the RABS file system in the folder structure defined in Section 8.
Step 6 -- Optional Manual Finishing
For selected items, staff may optionally open and edit outputs in a richer design environment such as Canva or Adobe Express.
11. Implementation Guidance
When building this feature, it should be treated as three distinct layers that must not be entangled:
Layer A -- Data and Asset Gathering
- Retrieve daily reports for the target date
- Retrieve related images from the gallery
- Filter by consent/approval status
- Group by program/date/location
Layer B -- Editorial Generation
- Summarise the day (LLM or rule-based)
- Build headings and highlight rankings
- Select hero image and supporting images
- Generate captions
- Build the structured JSON payload
Layer C -- Rendering and Export
- Send structured payload to the template service API
- Receive the exported file (PDF/PNG)
- Store output in the correct file path
- Record metadata and audit trail
Editorial logic must never leak into the rendering layer. The rendering service should be a pure layout engine that can be swapped without changing any editorial code.
12. Consent and Safeguarding
The pipeline must respect image consent flags at every stage:
- only images with confirmed consent are included in any output
- the editorial logic layer (Layer B) is responsible for filtering before the payload reaches any external service
- no unconsented images should leave the RABS boundary
- consent metadata should be logged per-output for audit purposes
13. Implementation Path
Stage 1 -- Canva Enquiry
Complete the nonprofit/private integration pricing enquiry. Wait for response.
Stage 2 -- Proof of Concept (Placid)
Build a small PoC using one real day:
- 3 programs, 6-10 images, realistic staff report text
- One daily highlights PDF
- One 3-page mini-booklet
- One Facebook asset
- One Instagram asset
Stage 3 -- Bannerbear Comparison
Run the same test pack through Bannerbear for direct comparison.
Stage 4 -- Evaluation
Compare output quality, flexibility, setup effort, automation ease, overflow handling, image fitting, and long-term scalability.
Stage 5 -- Operational Model Decision
Select primary renderer (likely Placid for publications, possibly Bannerbear for social) or a blended model.
Stage 6 -- Optional Manual Finishing
Add manual editing tools (Canva, Adobe Express) later if needed for polish.
14. Relationship to Existing Systems
| System | Relationship |
|---|---|
| Gallery & Media System | Source of curated photos and videos |
| Activity Reports | Source of daily program content |
| YP3000 Identity System | Consent flag verification for individuals |
| Bookface Facial Recognition | Future: auto-identify people in selected images |
| Discord Media Grabber | Upstream source of raw photos |
The media pipeline is a consumer of these existing systems, not a replacement for any of them.