Minimum Sufficient Control Architecture for AI Enabled Urban Systems

Tegrity.AI · The Integral Management Society

Working paper v0.4 · 15 September 2026

Abstract

Interoperability is necessary for many AI-enabled urban services, but it does not establish how much coordination or intervention is sufficient to achieve their objectives. Minimum Sufficient Control Architecture (MSCA) addresses this architectural gap. Starting from a city’s legitimately defined outcomes and mandatory constraints, it describes coordination scope C, intervention mechanisms P and enabling means M, including reusable Minimal Interoperability Mechanisms (MIMs). The aim is not maximum sensing or control, but an evidence-supported configuration sufficient within stated operating conditions. This paper develops the argument of FG-AI4SSC input FGAI4SSC-I-097 through interoperability precedents, bounded urban-control examples and a retrospective case study conducted in 2026 of the pre-agentic xSeil system developed in 2016–2017. It distinguishes transferable architectural reasoning from claims that require local validation, and outlines how cities could compare configurations without assuming identical infrastructures or a universal minimum.

1 From sufficient interoperability to sufficient control

Smart-city systems must connect heterogeneous services, but connectivity is not the outcome a city ultimately needs. A mobility service may exchange accurate information while lacking the authority, coordinated actors or available interventions to preserve accessibility, punctuality or safety. Conversely, a city may meet a bounded objective using existing interfaces and human-mediated operations. The architectural question is therefore how much coordinated control is sufficient, not how much technology could be installed.

The original contribution FGAI4SSC-I-097 placed this question within the Focus Group’s system-level remit [1]. FG-AI4SSC’s Terms of Reference connect architectural frameworks, interoperability including MIMs, supervisory/control requirements and assessment [2]. MSCA addresses their intersection. It does not prescribe general urban policy, sector-specific regulation or detailed AI-model design.

MIMs provide the central precedent. OASC identifies common mechanisms that allow heterogeneous systems and services to interoperate [3]. SynchroniCity pursued a common minimal technical ground across cities [4]. NIST’s Pivotal Points of Interoperability similarly direct standardization toward selected interfaces instead of prescribing every component [5]. ITU-T Y.4200 and Y.4201 address smart-city platform interoperability requirements and reference frameworks [6]. These approaches illustrate selective architectural commitments; they are not demonstrations of MSCA.

MIMs can enable selected systems to work together, but do not by themselves determine which actors or what proportion must be coordinated, or which interventions are needed. Excellent interoperability does not answer whether coordinating a small strategic subset is sufficient or whether a wider operational reach is required. MSCA adds that outcome-dependent question; it is not another MIM.

2 Describing an objective led architecture

A city first declares an objective envelope S(t): the outcomes to maintain, their acceptable ranges and mandatory constraints. Mobility objectives may include travel time, accessibility, emissions, capacity use and safety. Other services involve access, appointments, water losses or facility occupancy. Outcomes may conflict. A weighted preference must not compensate for violating a mandatory constraint, and no universal scalar is required.

The envelope is locally legitimate, not chosen by the control system. Its owner must identify the authority to revise it. Operating assumptions also matter: demand, disruptions, information quality, infrastructure and available staff determine where the sufficiency claim applies. An architecture is represented through three practical dimensions, inherited from the submission.

FIGURE 1 · OPEN FULL RESOLUTION

Figure 1. Objective-led organization retained from FGAI4SSC-I-097. This is a conceptual description, not an adopted FG framework or an experimentally established minimum.

MSCA seeks the least intervention-intensive sufficient configuration within this declared scope. “Minimum” does not mean the fewest sensors or the smallest software stack. Removing a redundant channel may reduce component count while making the service insufficient during a disruption. Relevant burdens include coordination reach, data collection, staffing, infrastructure and intervention intensity. Conflicting burdens should remain explicit rather than disappear inside an arbitrary aggregate score.

Two cities may achieve comparable outcomes with different C/P/M combinations. Comparability requires compatible definitions of outcomes, constraints and operating conditions; matching a headline performance number is insufficient. The opportunity is a common description of sufficiency, not uniform infrastructure.

3 Why bounded control is relevant to smart cities

Direct controllability and system-level effect need not increase in the same proportion. Stern et al. demonstrated stop-and-go-wave damping with one controlled vehicle among more than twenty on a circular track [7]. The CIRCLES MegaVanderTest subsequently deployed a heterogeneous fleet of one hundred controlled vehicles in open-road traffic [8]. Together they justify studying the controlled fraction as a design variable. They do not supply a transferable minimum for a city, a non-automated population or a different service objective.

Zurich is a closer urban-service precedent: selected inner-city observations inform interventions at access-road signals when operating conditions deteriorate [9]. The relevant pattern is bounded observation, an operational threshold, intervention and feedback. SCOOT’s responsive signal coordination and EPAL’s WONE water-loss management provide other domain-specific examples [10,11]. Target-control theory offers a formal precedent for influencing selected targets, subject to its dynamical assumptions [12].

Application is credible where an outcome can be observed, a relevant intervention can be executed by an authorized actor, and feedback can establish whether the objective is being maintained. The boundary may be a corridor, fleet, service or district rather than the whole city. Urban systems add heterogeneous ownership, unequal service access, uncoordinated participants and cross-domain effects. These are part of the assessment, not reasons to assume wider control is always desirable.

Local improvement can also displace a problem. A route change may protect a fleet’s punctuality while moving congestion to another neighbourhood. A water intervention may affect pressure elsewhere. A city-level claim must therefore include relevant external effects and protected service constraints. Where those effects are unobserved, the result remains a bounded service claim, not evidence of overall urban improvement.

4 xSeil as a retrospective bounded case

In 2026, we studied xSeil retrospectively as an expert logistics system developed in 2016–2017 [13–15]. It coordinated a tourism-transport operation in the Riviera Maya serving approximately four hundred hotels and seven destination parks, with hundreds of vehicles and several thousand daily passenger movements [1,15]. The preserved source snapshot examined in the study is dated 21 April 2018. That archive date is distinct from both the historical operation and the 2026 research.

The system was pre-agentic: explicit planning, heuristics, operational rules and human roles performed functions now often discussed in agentic terms. It was not designed under the MSCA label. Its usefulness for MSCA is a retrospective interpretation supported by three features. First, its architectural separation of scenario parameters, planning, monitoring and reassignment makes C/P/M choices inspectable. Second, requirements, functional inventories, code, issue history, reservation exports and executed route sheets allow intended functions, implementation and operational records to be compared. Third, committed demand, finite fleet capacity, transfers and deadlines expose concrete trade-offs rather than an unconstrained optimization problem.

FIGURE 2 · OPEN FULL RESOLUTION

Figure 2. Bounded fleet and shared-network interaction, redrawn from the submission for legibility. The diagram indicates operational scale and a feedback pathway, not a quantified causal effect on regional traffic.

Traffic reports were inputs to alternative routing; revised routes redistributed fleet movements across shared corridors and access points. This creates a plausible reciprocal interaction between controlled operations and the wider network. The retained evidence does not isolate a causal reduction in regional congestion. Private operating objectives are not equivalent to legitimate city-wide objectives.

The 2026 code study also exposes testable mechanisms: scenario-based scoring, bounded search and reassignment checks distinguish preferences, planning effort and available corrective actions [13,14]. A good score does not prove that constraints hold, and a detected problem does not guarantee an executable repair. These features make xSeil a useful case for future matched replay and capability-removal tests. They do not establish minimality, superiority over agentic systems or readiness for unmodified deployment in another city. The surviving code requires execution-level validation; comparative MSCA experiments have not been completed.

5 Making sufficiency assessable without prescribing a universal stack

The modest extension beyond the submission is an evidence obligation attached to the C/P/M description. Each candidate should state the objective envelope, operating assumptions, authorized reach and interventions, reusable means, outcome evidence and conditions that invalidate the claim. This turns an architectural question into something a city can examine without imposing a complete universal methodology.

For example, a city could compare two designs for keeping a bus corridor within a declared travel-time range while preserving pedestrian crossing requirements. One might coordinate an eligible fleet through interoperable arrival predictions; another might also provide authorized signal-priority interventions. MIM-based exchange can support both. Whether either is sufficient depends on demand, coverage, information age, effective authority and observed outcomes—not merely on interface conformance. This is an illustrative comparison, not a reported experiment.

Assessment should distinguish three outcomes: sufficient within the supported scope; insufficient because a declared requirement fails; or unresolved because the evidence cannot establish either. Candidates must be compared under compatible objectives and disturbances. Where several are sufficient, the chosen trade-offs should be stated. Removing or weakening a capability can test whether it is necessary in that configuration, but failure to obtain evidence is not proof of physical insufficiency. Nor does testing a few alternatives establish a global minimum.

For AI-enabled services, the unit of assessment includes what model or agent outputs cause in the urban operation. A better prediction is useful only insofar as observation, coordination and legitimate intervention can preserve the declared outcomes. Existing interfaces, legacy control systems and human-mediated responses remain candidates; AI is neither excluded nor treated as sufficient by itself.

The implication for future urban reference architectures is concrete: describe not only possible components, but the conditions under which their combination is enough. Reuse and rationalize existing capabilities before adding new ones; justify additions against unmet requirements; and reopen the assessment when demand, actors, infrastructure or objectives change. This is complementary to MIMs and consistent with FG-AI4SSC’s architectural and assessment remit. It is an independent research proposal, not an adopted standard. Its central claim is conditional sufficiency with proportionate means—not maximum control, and not minimalism for its own sake.

5.1 Integrating the MSCA components

C, P and M are architectural dimensions, not three mandatory software products. A practical implementation maps them to existing components through a versioned sufficiency record: S, operating assumptions E, configuration, supporting evidence, decision owner, permissions, deadlines and contingency policy. An illustrative integration is:

Component / responsibility	Receives	Supplies to the next component
M: observation adapters	Existing telemetry, events and human reports	Observations with source, time, quality and scope
C: coordination registry	Observations, declared scope and current mandates	Reachable actors, legitimate influence and coverage gaps
P: intervention catalogue and planner	Current state, C’s reach, objectives and constraints	Feasible action candidates and a bounded proposal
Assessment and authorization	Evidence, proposal, approved envelope and permissions	Supported / failed / unresolved judgment; scoped permit or refusal
M: command and effect adapters	Versioned proposal, permit and expiry	Execution receipt plus separately observed effect, linked to the evidence log

The same operation identifier connects observation, decision, command, receipt and measured effect. Configuration version, provenance, timestamps, permission reference and expiry prevent a command from being detached from the conditions supporting it. These are illustrative integration requirements, not new normative MIM fields. MIM-compatible exchanges can carry the relevant information where their semantics fit; adapters must address any remaining gap explicitly.

Architectural selection remains separate from the operational loop. ASSESS returns SUPPORTED, FAILED or UNRESOLVED against declared criteria, not an optimization score. Selection considers intervention burden only among supported alternatives and records the owner’s trade-offs. It remains relative to the tested set, not a proven global minimum.

DESIGN(S, E, candidates, evidence):
    require owner-approved objectives, constraints and contingency policy
    for A in candidates:                         # A = (C, P, M)
        verdict[A] = ASSESS(A, S, E, evidence[A])
    supported = {A where verdict[A] == SUPPORTED}
    if supported is empty:
        return REASSESS(verdict)                 # FAILED != UNRESOLVED
    A = owner_select_and_authorize(supported, burden_tradeoffs)
    if A is NONE: return NO_DEPLOYMENT_APPROVAL
    return versioned_record(A, S, E, evidence, limits, contingency_policy)

The operational pseudocode makes the component handoffs explicit. Function names describe responsibilities, not an implemented API or a required platform.

cfg = load_owner_approved_sufficiency_record()
C = CoordinationRegistry(cfg.actors, cfg.mandates)
P = InterventionCatalogue(cfg.actions, cfg.preconditions)
M = ExistingSystemAdapters(cfg.observation_and_command_interfaces)

ON_TRIGGER(trigger):
    op = new_operation_id(cfg.version, trigger)
    obs = M.observe_with_provenance_and_freshness()
    reach = C.resolve_current_reach(obs, cfg.scope)
    log.append(op, obs, reach)
    if assessor.check_current_scope(cfg, obs, reach) != SUPPORTED:
        return EXCEPTION(op, "scope failed or unresolved")
    options = P.feasible_actions(obs, reach, cfg.constraints)
    proposal = planner.select(options, cfg.objectives)  # may be no-change
    if proposal is NONE: return EXCEPTION(op, "no feasible action")
    permit = authority.check(proposal, cfg, obs, reach)
    if permit is REFUSED_OR_UNRESOLVED:
        return EXCEPTION(op, "no authorized feasible action")
    log.append(op, proposal, permit)
    receipt = M.dispatch_with_recheck(op, proposal, permit, cfg.expiry)
    effects = M.observe_effects(op, cfg.response_deadline)
    result = evaluator.verify(receipt, effects, cfg.S, cfg.E)
    log.append(op, receipt, effects, result)
    if result != SUPPORTED: return EXCEPTION(op, result)
    return CONTINUE_WITHIN_RECORDED_SCOPE

EXCEPTION(op, reason):
    response = contingency.apply_if_currently_authorized_and_feasible(cfg)
    log.append(op, reason, response)
    notify_operator_and_owner(reason, response)
    reopen_assessment(cfg.version)               # never silently relax S
    return REASSESSMENT_REQUIRED

Dispatch rechecks permission, configuration validity and action preconditions at the point of execution. Rejection, delivery failure or timeout must produce an explicit failed or unresolved result, never a silent success. Verification requires evidence of the effect, not merely an acknowledgement; its independence and timeliness depend on the service. Contingency may be a constrained mode, manual response or suspension of affected actions, as explicitly authorized—not an assumed universally safe shutdown. No feasible contingency means escalation of that capacity gap.

5.2 Deployment notes and BPMN

Deploy incrementally. First map existing interfaces, decision rights and service constraints; reuse usable MIM-compatible and legacy components. Then establish a baseline and test alternatives in replay or shadow mode, without issuing live commands. A bounded live pilot requires separate approval of scope, permissions, stop criteria, observability and a feasible contingency; it is not production authorization. Use its evidence, including disturbance and capability-removal tests where safe, to decide whether a configuration is supported. Only then authorize production within the documented envelope.

Version the record, adapter mappings and intervention catalogue together. Enforce scoped permissions, command expiry, duplicate handling and correlation identifiers at integration boundaries. Test missing or stale observations, rejected commands, delayed effects and loss of operator capacity. Production needs an assigned exception owner, review triggers and an executable contingency—not merely a running model. Changes to actors, objectives, interfaces or demand reopen the assessment as appropriate.

The two BPMN processes below use start/end events, tasks and exclusive gateways [16]. They are non-executable implementation sketches. The city/service owner defines and approves the envelope and deployment; the assessment function compares evidence; the operator or controller carries out only authorized actions. A change or failed/unknown check returns the case to assessment, not automatically to wider control.

FIGURE 3A · OPEN FULL RESOLUTION

Figure 3a. Staged deployment and production approval. Replay and shadow tests do not actuate the service. A live pilot requires its own authorization; unsupported or unresolved evidence cannot justify production approval.

FIGURE 3B · OPEN FULL RESOLUTION

Figure 3b. One operational cycle. Each gateway takes exactly one branch. The successful end waits for the next observation or review trigger; an exception invokes the scoped contingency policy and reopens assessment. An execution receipt alone cannot satisfy the final gateway.

Implementation note. These BPMN diagrams are a deliberately simple roadmap, not implementation guidelines. Practitioners can adapt the architecture to real systems and decision rights; formal MSCA implementation guidelines have not yet been developed. JubAp.eu Mobility shows related field practice, not a validated MSCA deployment.

References

[1] Abril Palma, I. Minimum Sufficient Control as an Architectural Property of AI-enabled Urban Systems. Tegrity.AI input FGAI4SSC-I-097, 2026. https://github.com/dakleyer/structural-awareness-contributions/tree/main/submissions/itu-fg-ai4ssc/FGAI4SSC-I-097

[2] ITU-T. Terms of Reference for FG-AI4SSC, 2026. https://www.itu.int/en/ITU-T/focusgroups/ai4ssc/Documents/Terms-of-Reference-FG-AI4SSC.pdf

[3] OASC. Minimal Interoperability Mechanisms. https://oascities.org/minimal-interoperability-mechanisms/

[4] European Commission. SynchroniCity final reporting, grant 732240. https://cordis.europa.eu/project/id/732240/reporting

[5] NIST. Pivotal Points of Interoperability Enable Smart City Standardization, 2021. https://www.nist.gov/news-events/news/2021/11/nists-pivotal-points-interoperability-enable-smart-city-standardization

[6] ITU-T. Y.4200 and Y.4201, 2018. Requirements for the interoperability of smart city platforms; High-level requirements and reference framework of smart city platforms. https://www.itu.int/rec/T-REC-Y.4200-201802-I/en and https://www.itu.int/rec/T-REC-Y.4201-201802-I/en

[7] Stern, R. E., et al. Dissipation of stop-and-go waves via control of autonomous vehicles: Field experiments. Transportation Research Part C 89 (2018), 205–221. https://doi.org/10.1016/j.trc.2018.02.005

[8] Lee, J. W., et al. Traffic Control via Connected and Automated Vehicles: An Open-Road Field Experiment with 100 CAVs. IEEE Control Systems 45(1) (2025), 28–60. https://doi.org/10.1109/MCS.2024.3498552

[9] Menendez, M., and Ambühl, L. Implementing Design and Operational Measures for Sustainable Mobility: Lessons from Zurich. Sustainability 14(2), 625 (2022). https://doi.org/10.3390/su14020625

[10] Hunt, P. B., et al. SCOOT—a traffic responsive method of coordinating signals. TRRL LR1014, 1981. Operator research context: https://www.trl.co.uk/projects/pedestrian-scoot-system

[11] EPAL. WONE—Water Optimization for Network Efficiency. https://www.epal.pt/EPAL/en/menu/products-and-services/our-products-and-services

[12] Gao, J., Liu, Y.-Y., D’Souza, R. M., and Barabási, A.-L. Target control of complex networks. Nature Communications 5, 5415 (2014). https://doi.org/10.1038/ncomms6415

[13] Abril Palma, I. Large Problems Without Large Hardware. xSeil technical series, v2, 2026. https://jubap.net/xseil-functionality-analisis/

[14] Abril Palma, I. Vehicle Routing Under Fully Committed Tourism Demand, v1; Pre-Agentic Orchestration, v0.4. xSeil technical series, 2026. https://jubap.net/xseil-vrp/ and https://jubap.net/xseil-orchestration/

[15] JubAp.Net. xSeil 2016 to 2018 Provenance Delivery and Code Evidence. Public register v1.1, September 2026. https://jubap.net/xseil-2016-to-2018-provenance-delivery-and-code-evidence/

[16] OMG. Business Process Model and Notation (BPMN), version 2.0.2. https://www.omg.org/spec/BPMN/2.0.2/About-BPMN