Skip to content

Active-Site Capacity Dashboard

Monitor — instantiates Catalytic Pathway Enablement

A live view of how much facilitator capacity is free, queued, saturated, or degrading — so substrate inflow can be matched to real throughput instead of nameplate capacity.

A facilitator's leverage evaporates the moment demand outruns its real capacity — but that moment is invisible unless someone is watching. Active-Site Capacity Dashboard is the live monitoring surface that shows, at a glance, how many "active sites" are free versus occupied, how deep the queue is, how long a cycle is taking, and whether activity is drifting down from interference or poisoning. What makes it THIS mechanism is that it only observes and displays: it turns the facilitator's hidden operating state into a signal operators can act on, so inflow is matched to actual throughput rather than to the optimistic nameplate number. It is the instrument panel, not the intervention.

Example

A company runs a shared rapid-prototyping cell — a handful of CNC mills and 3D printers — that turns engineers' design files into physical parts, a reusable facilitator many teams depend on. Teams keep flooding it with jobs and then complain it is "slow." The Active-Site Capacity Dashboard makes the real state visible: machines busy versus idle, queue depth per machine type, average cycle time, and a degradation flag when a printer's reject rate creeps up because a nozzle is clogging.

Setup to outcome: the board shows the resin printers saturated with a two-day queue while the CNC mills sit idle, and one printer flagged for rising scrap. The response stops being "add more jobs." It becomes obvious instead — route eligible jobs to the idle mills, hold new resin jobs until the queue drains, and pull the flagged printer for cleaning. Throughput recovers not by adding substrate but by matching inflow to what the facilitator can really do right now.

How it works

  • Instrument the facilitator for occupancy, queue depth, and cycle time, and compute a live saturation figure rather than a nominal one.
  • Surface interference and inhibition as it emerges — rising reject rate, activity drift, a contaminant signal — so a degradation problem is visibly distinct from a saturation problem.
  • Close the loop. Feed the state back to whoever controls inflow, so demand tracks real capacity instead of the nameplate number. It displays; it does not throttle, regenerate, or test.

Tuning parameters

  • Refresh latency — real-time vs. periodic. Live data enables tight inflow control but costs instrumentation and can invite twitchy overreaction; slower refresh is cheaper but lets saturation build unseen.
  • Saturation thresholds / alerting — where "busy" becomes "saturated." Sensitive thresholds warn early but cry wolf; loose ones fire only once the queue is already painful.
  • Granularity — one aggregate capacity number vs. per-active-site detail. Fine granularity localizes the constraint but clutters the view; coarse hides which site is actually the limit.
  • Which signals are shown — occupancy only, or also degradation and inhibition trends. Leading indicators (reject-rate drift) catch poisoning early but need more instrumentation and risk false alarms.

When it helps, and when it misleads

Its strength is replacing "it feels slow" with a picture of where the real limit sits, and separating a saturation problem (too much inflow) from a degradation problem (the facilitator itself failing) — two conditions with opposite fixes.

Its failure modes come from measuring the wrong things. A dashboard sees only what it is wired to see, so an un-instrumented failure mode stays invisible and falsely reassuring. Vanity metrics mislead: utilization pinned near 100% can look healthy while queue time explodes. And watchers can fixate on the board instead of acting on it. The classic misuse is reading high utilization as "efficient" when, by ordinary queueing behavior, throughput time blows up long before utilization reaches 100%. A real anchor makes the point precise: Little's Law relates average queue length, arrival rate, and wait time (L = λW), which is why a capacity board must show queue and cycle time, not just how busy the machines look.[1] The discipline is to monitor queue and degradation alongside occupancy, and to treat the dashboard as an input to action, never the action itself.

How it implements the components

Active-Site Capacity Dashboard fills the observation components — the ones that detect and display state, not the ones that act on it:

  • saturation_and_interference_monitor — its core function: it tracks occupancy, queue depth, and congestion and shows when capacity is fully occupied or disrupted.
  • inhibitor_or_poison_monitor — it surfaces the leading signs that the facilitator is being suppressed or poisoned (activity drift, rising reject rate), distinguishing reversible interference from creeping deactivation.
  • feedback_monitoring — it closes the loop, feeding the facilitator's live state back to whoever controls substrate inflow so demand tracks real capacity.

It does not act on what it sees — it does not regenerate the degraded facilitator (that's Catalyst Regeneration Protocol), run the diagnostic test for what is poisoning it (that's the Inhibitor and Poison Screen), or measure turnover and off-target rate (that's the Turnover and Selectivity Assay).

Notes

The dashboard's numbers are only as honest as its instrumentation, and the most dangerous state it can show is a green board sitting over an un-measured failure. What the dashboard does not show therefore deserves as much scrutiny as what it does — a periodic audit of its blind spots is part of trusting it, not a separate concern.

References

[1] Little's Law (queueing theory): in a stable system the average number of items present equals the average arrival rate times the average time each spends in the system (L = λW). A practical consequence is that waiting time climbs steeply as utilization approaches 100%, so utilization alone is a misleading measure of a facilitator's health. ↩