Experience 003 · The Ubuntu Town Operating System · Blueprint is portfolio authority · Supabase is operational truth · nothing fabricated
UTUbuntu Town OS

Operating loop · signal → mission → work

MISSIONS

Two objects share the word “mission”. This screen keeps them apart instead of pretending the schema says something it does not.

Terminology resolution (contradiction D-01)

CONTRADICTION

Terminology resolution (D-01): the canonical schema object uto.missions holds CAMPAIGN TARGETS (target_count × cadence, progress derived from community work) — not assigned work items. The UI language "MISSION (CAMPAIGN TARGET)" preserves this distinction; the schema is untouched. The operating loop's "mission" sense (SIGNAL → MISSION → WORK) lives at the experience layer as the proposal-to-work flow, and is labelled PROPOSED MISSION where it appears.

Mission (campaign target) — uto.missions

Campaign targets

RECORDS NOT ACCESSIBLE — uto.missions rows are visible to authenticated users (RLS: missions_read for authenticated). This public experience cannot list active campaigns. What is known from the schema (migration 0011): a campaign target has target_count × cadence (daily | weekly | once), optionally scoped to a town and work type, with progress DERIVED from community work counts — never stored as a score.

Community work (the progress source)

uto.community_work is publicly readable and returned 0 rows to this experience — but row-level security can filter visibility by consent and tenancy. Therefore the correct state is INSUFFICIENT EVIDENCE for “no community work exists”, and ZERO (visible to this experience) for what this read can see. Those are different claims and the system keeps them apart.

Proposed missions — the operating-loop sense

DERIVED

In the operating loop (SIGNAL → MISSION → WORK → PROOF → LEARNING → OPPORTUNITY → NEXT MISSION), a mission is what a signal becomes when a human decides to act on it. Below are mission candidates derived from real recorded signals — every one is a PROPOSAL awaiting human approval. None executes.

  • PROPOSED MISSION: act on “Inside.Town Media + Local Business & SMME Visibility + Youth Opportuni…” in Acornhoek

    PROPOSED — PENDING HUMAN APPROVAL

    A recorded signal with enough context to consider a workpack — translated into a mission candidate by the operating loop, not decided by it.

    Signal: uto.towns.opportunity_notes (live canonical record)

  • PROPOSED MISSION: act on “Admin / Civic Opportunity + Local Business & SMME Visibility + Youth O…” in Bethlehem

    PROPOSED — PENDING HUMAN APPROVAL

    A recorded signal with enough context to consider a workpack — translated into a mission candidate by the operating loop, not decided by it.

    Signal: uto.towns.opportunity_notes (live canonical record)

  • PROPOSED MISSION: act on “Transport and Logistics — As a logistics corridor town, Bethlehem can …” in Bethlehem

    PROPOSED — PENDING HUMAN APPROVAL

    A recorded signal with enough context to consider a workpack — translated into a mission candidate by the operating loop, not decided by it.

    Signal: Dihlabeng_Local_Municipality_Bethlehem opportunity domain (confidence 0.8, research)

  • PROPOSED MISSION: act on “Community Civic Intelligence — Improving civic engagement and communit…” in Bethlehem

    PROPOSED — PENDING HUMAN APPROVAL

    A recorded signal with enough context to consider a workpack — translated into a mission candidate by the operating loop, not decided by it.

    Signal: Dihlabeng_Local_Municipality_Bethlehem opportunity domain (confidence 0.7, research)

  • PROPOSED MISSION: act on “Inside.Town Media + Community Anchors + Youth Opportunity Network” in Bloemfontein

    PROPOSED — PENDING HUMAN APPROVAL

    A recorded signal with enough context to consider a workpack — translated into a mission candidate by the operating loop, not decided by it.

    Signal: uto.towns.opportunity_notes (live canonical record)

  • PROPOSED MISSION: act on “Youth Employment — The town has a young population that can benefit fr…” in Bloemfontein

    PROPOSED — PENDING HUMAN APPROVAL

    A recorded signal with enough context to consider a workpack — translated into a mission candidate by the operating loop, not decided by it.

    Signal: MAN_Bloemfontein_v1 opportunity domain (confidence 80, research)

What completed missions would feed

Proof

Mission completion is proven through the work's proof standards (see work items). Captured proofs are protected — PROOF GAP.

Learning

ABSENT — uto.learnings does not exist in the canonical schema (verified). The learning step of the operating loop is a documented structural gap (G3): completed work can be proven but cannot yet be recorded as learning. Memories (protected) hold narrative context for authorised users. Until the learnings object exists, this system shows the gap — never a fake learning feed.

CHIEF OF STAFF

operating intelligence · Missions · campaign targets + loop proposals

What is happening?

Two distinct objects share the word "mission": schema campaign targets (uto.missions) and the operating-loop mission (signal → decided action). This surface keeps them apart on purpose.

AUTHORED
Why?

Evidence: migration 0011 (uto.missions schema) · operating loop doctrine

Reasoning: Terminology conflict resolved at the experience layer; the schema is untouched (per the mandate: do not silently rewrite the schema).

Next moves