S-12 — Sourcing and Optimization: First-Class Capabilities (stakeholder)

Scope: Why sourcing, solving, and optimizing are promoted to first-class platform capabilities, what full utilization looks like in day-to-day work, and what we promise and cannot promise. Written for decision-makers and operations owners, in plain language. Status: as of 2026-11-09 Blueprint sources: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md; S-03 — Jijibora Playbook Registry (stakeholder + developer); S-02 — What Jijibora Can Do for You (plain-language feature guide); docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md; docs/jijibora-government-trial/08_LIMITS_AND_RISKS.md; docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md

How to read this page: plain words first, cause second. Every factual claim carries its source so you can check it without hunting.

1. What makes it different: machines only propose, rules dispose

Most products answer one question: "who qualifies?" We answer three, in order, and keep them separate:

Sourcing discovers the best candidate who is allowed and able (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md).
Solving turns the shortlist into a clear answer under constraints — the least-cost, least-route, or feasible schedule that still covers the need (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md).
Optimizing keeps that answer the best all day, replanning as the day changes, so no one is left working from yesterday's plan (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md).

The discipline that makes all three trustworthy is: machines only propose, rules dispose (source: S-03 — Jijibora Playbook Registry (stakeholder + developer)). In plain terms:

The match, the solver, and the optimizer can suggest, rank, allocate, and resequence — but they cannot award, dispatch, approve, or settle on their own (source: S-03 — Jijibora Playbook Registry (stakeholder + developer); source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md).
A named person or a governed rule has to say "yes, award it" — and until they do, nothing moves (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md).
Why this matters causally: if the proposing machine could also dispose, a scoring error or a stale estimate would become a real award or a real truck on the road with no human check. Separation means an error is caught while it is still a suggestion (source: docs/jijibora-government-trial/08_LIMITS_AND_RISKS.md).

Three more rules hold the whole line together:

Solving only happens after sourcing has produced a real match. No match, no solve. This stops the machine from inventing a convenient answer out of an empty shortlist (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md; source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md).
A feasible plan and an explicit "cannot be done" are different outcomes. When the need cannot be met from who qualifies, the platform says so plainly and shows why, instead of quietly over-allocating or promising what does not exist (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md).
When the solving service is down, the platform refuses and explains. It never types a fake "optimal" plan to keep the screen looking finished. That is why you will sometimes see a refusal instead of an answer — refusing is the product working as designed (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md).

2. Three stakeholder stories

Story A — The sourceer: `/match` and discovering the best candidate

The sourceer is the ward officer, the market official with a phone, and the buyer who needs work done. Their job is to express a need — "bring a certified plumber to Block C," "cover 100 kg of mangoes" — and discover the best candidate who is actually allowed to do it (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md).

How it feels:

The need is written once, in plain language, and the system checks it against the council's own approved register of local workers and suppliers — and only that register (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md).
The system then ranks who qualifies by the facts a resident would care about: distance, licence status, past completion — and shows its working so an auditor can inspect the ranking for favouritism later (source: docs/jijibora-government-trial/08_LIMITS_AND_RISKS.md).
The estate version is the same story with a phone in hand: the assistant proposes the nearest certified worker, and the manager approves in one tap (source: docs/jijibora-gtm/03_ENTRY_POINT_AND_STARTER_PACK.md).

Why the register matters causally: if the system could pick anyone, "qualified" would mean whatever the machine felt like saying. Restricting it to the approved register means the community's own vetting decision is what makes someone eligible — the machine only searches inside the choice the community already made (source: docs/jijibora-government-trial/08_LIMITS_AND_RISKS.md).

What if the network is down? The sourceer is told to assign by hand rather than wait for the machine to pretend. That fallback is stated in the plan so nobody is surprised mid-incident (source: docs/jijibora-government-trial/08_LIMITS_AND_RISKS.md).

Story B — The solver: a clear answer under constraints

Sourcing answers "who qualifies." It cannot answer "how much from whom, in what order, at what cost, and still cover everything" — because that is a joint puzzle, not a single match (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md).

The classic example is simple to picture: you need 100 kg of mangoes. Three farms can supply 30 kg, 20 kg, and 60 kg. The solver's clear answer is what to take from each farm so the total adds up, the least suppliers are used, and nothing is taken that a farm does not have — for example, take all 30 kg from the first farm, all 20 kg from the second, and 50 kg from the third, leaving 10 kg on the third farm's pile (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md).

In council work the same shape repeats:

Least cost that still works — split a repair bundle across shops or crews without over-buying from one and under-buying from another (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md).
Least route that still covers — order the pickups or stops so travel is shortest while every stop is still served on time (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md).
Feasible schedule that still covers — place time-windowed jobs so windows, curfews, and capacity rules are all satisfied, or declare honestly that no feasible schedule exists (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md).

Why a solver is needed causally: a spreadsheet can rank people one by one, but it cannot hold all the constraints at once and prove the combination is actually feasible. The solver does that — and when feasibility is impossible, it proves it instead of guessing (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md).

The solver never acts alone: it runs only on the shortlist sourcing already proved, under the rules the platform was given, and its answer is checked independently before anyone can use it (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md).

Story C — The optimizer: keeping crews, vehicles, garbage trucks, and technicians on the best plans all day

The solver gives a good plan at a moment in time. The day does not stay still. A crew runs late, a new fault lands near a truck already on the road, a market is cleared at dawn and the round must sequence around it, a technician's arrival slips — and yesterday's "best" is no longer best (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md).

The optimizer's job is to keep every crew, vehicle, garbage truck, and technician on the best feasible plan all day: replan when reality changes, re-score when conditions change, resequence when a stop is missed — without anyone manually redrawing the whole day (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md). Municipal sequencing already assumes this: refuse-truck rounds are sequenced so markets are cleared before morning trade, and nearby road reports are grouped so a crew covers them in one trip (source: docs/jijibora-government-trial/05_IMPLICATIONS_AND_APPLICATIONS.md).

Put in the user's own words: the recruiter never leaves the app with a stale plan for tomorrow. Whoever finishes the day's dispatch should close the app knowing tomorrow's crews, vehicles, and technicians are already on the freshest feasible plans — not that they need to redo the puzzle in the morning (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md).

Why this matters causally: a plan decays the moment the world moves. Without optimization, the team keeps executing a plan that was only true at 8 a.m. The optimizer closes that gap by treating the plan as a living thing — each new signal triggers a fresh, feasible proposal, still subject to human approval before anything is dispatched (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md).

What the optimizer does not do is decide. It produces evidence — a better proposal with its reasons — and stops there (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md).

3. The warranties: what we promise, and what never happens

Warranty 1 — No award without qualification. No job, quantity, or budget is awarded unless the winner first passed qualification from the approved register. Skilled data cannot be evaded: if someone is not on the register, or not licensed for that work, or not entitled to supply, the machine refuses rather than routing around the rule (source: docs/jijibora-government-trial/08_LIMITS_AND_RISKS.md). Why: the community's vetting is the authority; the machine is only the search inside it (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md).

Warranty 2 — No dispatch without a deal/fill. No crew, truck, or technician is dispatched until there is a real deal — a feasible fill plan that covers the need from qualified suppliers — and then a route or schedule that covers it in the world. A match alone never dispatches anyone (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md). Why: matching says who could do it; only a feasible fill says how much from whom so the day actually works (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md).

Warranty 3 — Optimizers never approve or settle. The optimizer keeps plans fresh and produces proposals with evidence. Approval stays with a named person or a governed rule, and money settlement stays outside the optimizing engine entirely. An optimized plan never becomes an approval, and an approval never becomes a payment inside the optimizer (source: S-03 — Jijibora Playbook Registry (stakeholder + developer); source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md). Why: the moment the proposer could also approve, "best plan" could quietly become "approved plan" — the same failure the whole separation exists to prevent (source: docs/jijibora-government-trial/08_LIMITS_AND_RISKS.md).

Warranty 4 — Infeasible is a first-class answer. When the need cannot be covered from who qualifies, the platform returns a plain, evidenced "cannot be done under these constraints" rather than a forced plan. The buyer then widens the register, changes the constraint, or accepts partial coverage — by decision, not by invention (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md).

Warranty 5 — No pretending when services are down. If the solving service, the connections, or the scheduling clock are unavailable, the platform refuses with a reason instead of inventing an answer to fill the screen. A refusal always beats a fake "optimal" (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md).

4. Honest limits: what you should not over-claim

Estimates before live probing. Until the solving service is probed live and the routing inputs are real, every plan is an estimate from test or practice data. We do not describe practice-mode estimates as live results, and we do not let a practice fill leave the building as a real award (source: S-03 — Jijibora Playbook Registry (stakeholder + developer); source: docs/commercialization/33_EVENT_SPINE_PLAYBOOK_BACKLOG.md). Whether a given deployment is running estimates or live probing at any moment is — UNKNOWN in this read set without a deployment status check.

Telemetry gaps when crews are offline. Optimization can only replan on signals it actually receives — arrival, completion, location, condition changes. When a crew is offline, out of coverage, or reporting through a channel that does not stream, the optimizer works from the last known facts and says so. It does not invent positions or completions to keep the plan looking fresh (source: docs/jijibora-government-trial/08_LIMITS_AND_RISKS.md). Exact offline-reporting conventions for crews are UNKNOWN in the read set.

Provider burden. "Best candidate" and "best plan" assume providers keep their facts fresh — stock, capacity, licence, availability — and accept the assignment discipline. If providers do not update their facts, or the register itself is thin, the optimizer can only choose among what exists. It cannot summon a plumber the town does not have (source: docs/jijibora-government-trial/08_LIMITS_AND_RISKS.md).

Explainability parity with the competition. Buyers rightly ask "why this worker, why this split, why this route?" Today we can show the ranking facts that decided — distance, licence, past completion — and the constraints that made a plan feasible or proved it infeasible (source: docs/jijibora-government-trial/08_LIMITS_AND_RISKS.md; source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md). Full natural-language, per-decision explainability that matches the polished explanations enterprise competitors advertise — e.g. syllable-level narration of every alternative the solver considered — is UNKNOWN as a shipped guarantee in this read set; do not quote it as parity until demonstrated on a live decision (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md).

One more limit to hold in the room. Sourcing, solving, and optimizing are capabilities, not guarantees of savings. No specific percentage saving, cost cut, or time saving is promised for your ward until your own baseline is measured (source: S-03 — Jijibora Playbook Registry (stakeholder + developer)).

What to ask us next

Which ward/service should be the first sourcing-plus-solving deployment — so shortlist criteria, fill policy, and approval gates can be agreed before anyone goes live? Owner: authority leadership (source: docs/jijibora-government-trial/02_TRIAL_PROPOSAL.md).
Who will hold the approved register, and who taps approve on each award — so the "propose vs. dispose" line names real people? Owner: authority leadership with platform team (source: docs/jijibora-government-trial/04_UNIFIED_ONTOLOGY_AND_REACTIVE_GOVERNANCE.md).
Whether tomorrow's-plan freshness (end-of-day replanning) is required on day one, or whether first-week freshness with daily replan is acceptable — so telemetry and reporting burden can be scoped honestly? Owner: operations lead (source: docs/event-sourcing/SOURCING_SOLVER_OPTIMIZER_INTEGRATION.md).