Content and publishing

Everything the Hub publishes — a page, an announcement, an opportunity, a resource entry — passes through the same pipeline: drafted by someone, reviewed by someone else, then released. There are no shortcuts around the review stage, and that is the point. The pipeline exists so that a compromised credential, an over-eager agent, or an honest mistake cannot put content on the public site unobserved.

The pipeline

stateDiagram-v2
    [*] --> Draft: create_content_draft
    Draft --> InReview: submit_content_draft
    InReview --> Draft: review sends back
    InReview --> Approved: review_content_draft
    Approved --> Published: publish_content_draft
    Published --> Unpublished: unpublish_content
    Unpublished --> [*]

Loading

A content_drafts row holds the working copy; the published artefact lives in content_documents. Separating the two means the public site only ever reads finished material — there is no "half-edited page accidentally visible" state, because the published collection never contains drafts.

Who can do what

The roles in the pipeline map to authority records, not to a special content permission:

• Drafting — a member capability; agents get it through the same route.
• Reviewing — the review_content_draft step needs a reviewer capability scoped to the relevant context.
• Publishing — a further step, so the person who approves is not necessarily the one who ships.

The MCP agent tools use this exact pipeline — create_content_draft, submit_content_draft, review_content_draft, publish_content_draft are the same calls the member interface makes. An agent cannot publish its own draft past a human reviewer, because the capability check does not know or care that the caller is a machine.

Resources and attribution

The resource collection mirrors material from external sources while keeping its provenance: original attribution, review status, and source are retained on the record. Inclusion in the collection is a mirror, not an endorsement — a distinction the interface states outright rather than leaving implied.

Opportunities

Opportunities follow the pipeline with a review queue of their own: submit → list_opportunity_review → review_opportunity. Members see their own submissions' state; organisations see theirs through their org context. Withdrawing (withdraw_opportunity) is a first-class transition, not a delete — the record of what was offered and when stays in the audit trail.

Practical notes

• update_content can patch a live document — either straight through (with the right capability) or by routing the change back into the draft pipeline. Prefer the pipeline when the change is substantive; apply-now exists for typos and metadata.
• Drafts are versioned, so review happens against a specific version — approving a draft, then editing it, requires re-review. This is what prevents the "approved then quietly changed" failure mode.
• The audit trail records every transition, so "who published this" is always answerable.