Source-verified case
A multi-role product case connecting organization materials, knowledge, AI-assisted creation, human approval, publishing preparation, and report structures. Completed facts come from current source, delivery documentation, and deployment configuration; unconnected external integrations and future items are marked separately.
Product operating scene
This scene represents the application flow present in the repository: sources, knowledge, creation, human review, and publishing preparation. It does not claim that production publishing is connected.
Files and web sources enter the organization library with processing, provenance, and repair states.
Materials become reviewable knowledge candidates; formal Wiki publication retains quality and human gates.
A natural-language brief moves into topics, drafts, rewrites, and visual preparation with organization context.
Editors submit work; reviewers approve or request changes, retaining decisions and feedback in the record.
Approved content enters scheduling, task-state, and URL-backfill paths; external publishing remains separately accepted.
Application flow present · external platform connection requires separate acceptance
Business background
The repository defines LinkinPro as a LinkedIn content operations workspace for enterprise content marketing teams: organization materials and product information move into source-grounded creation, human review, publishing preparation, and report structures.
Documented starting point
These breakpoints come from the April 15, 2026 comparison between the ideal SOP and the then-current implementation. They explain why a connected workflow was needed; later delivery and status documents govern current capability claims.
The earlier flow used a brief for one-off generation, followed by manual copy and paste into downstream tools.
Materials could be uploaded, but extraction and learning state were not visible, so the team could not verify whether brand context had been understood.
There was no unified content history, classified view, or team archive connecting drafts with published content.
Scheduling, the approval flow, post-publication performance tracking and reports were missing or disconnected, preventing a continuous path from input to review.
Decision record
Pressure
Uploading material did not prove brand context had been understood; processing, provenance, and repair states were not visible.
Decision
Files and web sources enter the organization library before becoming reviewable knowledge candidates, rather than disappearing into untraceable prompt context.
Pressure
Content, factual claims, and formal Wiki material affect external expression; generation completion cannot be treated as approval.
Decision
Editors submit work, review roles approve or request changes, and both feedback and decisions remain in the organization record.
Pressure
Scheduling, task state, and URL backfill can be built, while external account authorization, live publishing, and return data still require separate acceptance.
Decision
The product moves approved content into release preparation without presenting a code path as a connected platform-operations capability.
Completed facts
This section describes capabilities present in the repository, database migrations, delivery guides, and operating configuration. Roadmap items are not presented as complete.
The application flow connects files and web sources, material processing, knowledge candidates, creation, human approval, publishing preparation, metric entry, and report views. External publishing and sync status are not counted as completed here.
The database role model includes admin, editor, and reviewer, while the delivered interface distinguishes customer operators, content or design users, customer administrators, and platform administrators.
Organization-scoped data is associated through organization_id and row-level policies across members, brand materials, knowledge chunks, content versions, review logs, publish records, post metrics, and report snapshots.
The runtime includes a Next.js web application, a FastAPI AI service, a queue-driven AI worker, and routes for knowledge, tasks, workflows, and runs.
The materials area accepts files and web sources and exposes processing, provenance, and repair states. Materials can become Wiki candidates, while formal Wiki publication retains a quality gate and human review.
The creation flow moves from a natural-language brief through topic selection, draft, visual materials, review feedback, and saving into the publishing workflow. The AI service also exposes topic, LinkedIn draft, rewrite, summary, and embedding tasks.
Editors can submit work for review, and review roles can approve it or request changes. Review logs and organization feedback are retained, and neither formal Wiki publication nor content release preparation defaults to unsupervised release.
The repository contains UI and data paths for drafts, review, scheduling and publishing preparation, task states, public-post URLs, and manual backfill. This is code-level workflow scaffolding, not production-confirmed integration.
Schema and API paths can record impressions, likes, comments, and clicks. The repository includes weekly summaries and PDF exports alongside report aggregation and snapshots. This proves recording and reporting structure, not an enabled production analytics sync.
The self-hosted Docker Compose configuration defines the web service, AI service, AI worker, and Redis, with service dependencies, health checks, resource controls, and systemd operating units.
Future direction
Future direction: configure and re-verify real account authorization, provider publishing, webhook return data, and analytics sync. External publishing and return data become completed capabilities only after production acceptance passes.
Future direction: unify the Evidence Pack, Task Brief, Review Report, and publishing status so sources, decisions, and state remain traceable.
Add an independent reviewer for high-risk claims and formal publishing tasks instead of introducing a fleet of always-on agents.
Organize brand voice, SEO, Wiki style, and review rubrics as versioned Skills with fixed evaluation sets, then compare improvements on real samples.
Only turn edits, final selections, and real performance into strategy changes after organization-level evaluation, human approval, staged rollout, and rollback are available.
Known limitations
The verified production status plan records that social-account sync and real publishing were not connected, return data remained unconfirmed, and analytics sync was disabled. External providers and platform authorization remain prerequisites; code scaffolding is not connection evidence.
Image and video capabilities require real product evidence, an available external service, and human output review. A successful technical task does not establish visual quality.
Metric fields and reporting capabilities show that the system can record and aggregate data; they do not prove a customer's business outcome. No customer outcome or ROI is claimed by this case study.
This page does not claim a security certification, compliance conclusion, availability guarantee, or continuous availability of every third-party platform.
Related commercial solutions