Independent Submission G.A. Aldana Flores Internet-Draft Aldana Innovations Intended status: Informational 1 May 2026 Expires: 2 November 2026 Smart Traffic Synchronization Protocol (STSP) Version 1.0 draft-aldana-stsp-00 Abstract This document defines the Smart Traffic Synchronization Protocol (STSP), version 1.0 -- an open, extensible protocol for real-time coordination of urban traffic signal infrastructure across distributed networks of intersections. STSP defines a standard message format, node state machine, synchronization algorithm, and inter-node communication model that enables any compliant traffic controller to participate in a federated intelligent network -- regardless of manufacturer, city, or country of deployment. The key contribution of STSP is the definition of the Infrastructure- to-Infrastructure (I2I) coordination layer -- a communication model between traffic signal nodes that does not exist as an open standard in any currently published specification. Existing standards such as SAE J2735 SPaT/MAP and ETSI ITS-G5 address Vehicle-to-Infrastructure (V2I) communication. STSP addresses the orthogonal problem: how nodes coordinate with each other. This document is placed in the public domain under CC BY 4.0 with Open Implementation Clause. Any city, government, company, or individual may implement STSP freely, provided that original authorship is attributed in all implementations, documentation, and derivative works as follows: "Implements STSP, designed by Gustavo Angel Aldana Flores (draft-aldana-stsp)." Author's Note on Priority Aldana Flores Expires 2 November 2026 [Page 1] Internet-Draft STSP May 2026 This Internet-Draft constitutes the first formal public disclosure of the STSP protocol specification. The conceptual foundation was developed independently by the author beginning approximately in 2015. The first working implementation was completed on 1 May 2026 and validated on ARM64 hardware (Raspberry Pi 4, 8GB RAM) running a full Docker stack including the STSP engine, TimescaleDB, Apache Kafka, Redis, and Grafana. The author asserts perpetual moral rights to this work under Mexican copyright law (Ley Federal del Derecho de Autor, as a Mexican citizen born 21 July 1992) and under the Berne Convention for the Protection of Literary and Artistic Works. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 2 November 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Fragmentation of Existing Systems . . . . . . . . . . . . 4 2.2. The Technical Opportunity . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Node Layer . . . . . . . . . . . . . . . . . . . . . . . 6 Aldana Flores Expires 2 November 2026 [Page 2] Internet-Draft STSP May 2026 4.2. Corridor Layer . . . . . . . . . . . . . . . . . . . . . 6 4.3. Federation Layer . . . . . . . . . . . . . . . . . . . . 6 5. Message Format (STSP/1.0) . . . . . . . . . . . . . . . . . . 6 5.1. Standard STSP Message . . . . . . . . . . . . . . . . . . 6 5.2. Compact Form . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Phase Enumeration . . . . . . . . . . . . . . . . . . . . 7 5.4. Node ID Format . . . . . . . . . . . . . . . . . . . . . 8 6. Node State Machine . . . . . . . . . . . . . . . . . . . . . 8 6.1. Fixed Mode . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Adaptive Mode . . . . . . . . . . . . . . . . . . . . . . 8 6.3. Emergency Override . . . . . . . . . . . . . . . . . . . 8 7. Green Wave Synchronization Algorithm . . . . . . . . . . . . 9 7.1. Offset Calculation . . . . . . . . . . . . . . . . . . . 9 7.2. Bidirectional Propagation . . . . . . . . . . . . . . . . 9 7.3. Priority Resolution . . . . . . . . . . . . . . . . . . . 9 8. Adaptive Phase Control . . . . . . . . . . . . . . . . . . . 9 8.1. Demand Ratio Policy (Normative Baseline) . . . . . . . . 9 8.2. Early Termination . . . . . . . . . . . . . . . . . . . . 9 8.3. Reinforcement Learning Extension (Optional) . . . . . . . 10 9. Federated Network Architecture . . . . . . . . . . . . . . . 10 9.1. Data Sovereignty . . . . . . . . . . . . . . . . . . . . 10 9.2. Federated Learning . . . . . . . . . . . . . . . . . . . 10 9.3. Inter-Region Protocol . . . . . . . . . . . . . . . . . . 10 10. Degraded Mode and Failsafe . . . . . . . . . . . . . . . . . 10 10.1. Degraded Mode Triggers . . . . . . . . . . . . . . . . . 11 10.2. Degraded Mode Behavior . . . . . . . . . . . . . . . . . 11 10.3. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11.1. Message Authentication . . . . . . . . . . . . . . . . . 11 11.2. Emergency Override Authorization . . . . . . . . . . . . 12 11.3. Denial of Service . . . . . . . . . . . . . . . . . . . 12 11.4. Physical Security . . . . . . . . . . . . . . . . . . . 12 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 13. Reference Implementation . . . . . . . . . . . . . . . . . . 12 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 14.1. Normative References . . . . . . . . . . . . . . . . . . 13 14.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A: RL State Space (Non-Normative) . . . . . . . . . . . 14 Appendix B: Glossary . . . . . . . . . . . . . . . . . . . . . . 14 Author's Declarations . . . . . . . . . . . . . . . . . . . . . . 14 Declaration of Priority . . . . . . . . . . . . . . . . . . . . 15 Declaration of Open Intent . . . . . . . . . . . . . . . . . . 15 Declaration of Independence . . . . . . . . . . . . . . . . . . 15 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 Aldana Flores Expires 2 November 2026 [Page 3] Internet-Draft STSP May 2026 1. Introduction Urban traffic congestion represents one of the most pervasive and quantifiable quality-of-life challenges in modern cities. According to INRIX Global Traffic Scorecard data, the average driver in a major metropolitan area loses between 50 and 150 hours per year to traffic delays. The aggregate economic cost exceeds hundreds of billions of US dollars annually worldwide. The root cause of this problem is not vehicle density alone -- it is the absence of coordination between traffic signal controllers. The vast majority of traffic signals deployed worldwide operate on fixed- cycle timers programmed once and rarely updated. These controllers have no knowledge of real-time queue conditions, no awareness of neighboring intersections, and no mechanism for inter-city coordination. Existing adaptive systems (SCATS, SCOOT, Siemens SiTraffic, Kapsch) address portions of this problem but share critical limitations: they are proprietary, city-siloed, non-interoperable, and incapable of federated coordination across administrative boundaries. This document specifies STSP -- a protocol designed to be for urban mobility infrastructure what TCP/IP is for digital communication: an open, implementable, universally adoptable standard that enables any conforming node to participate in a global intelligent traffic network. The key insight motivating STSP is the distinction between two communication layers that existing standards conflate or ignore: * *V2I (Vehicle-to-Infrastructure):* the layer that informs vehicles of the current signal phase. Standards such as SAE J2735 SPaT/MAP and ETSI ITS-G5 address this layer. * *I2I (Infrastructure-to-Infrastructure):* the layer that enables traffic signals to coordinate with each other in real time. No open standard exists for this layer. STSP fills this gap. 2. Problem Statement 2.1. Fragmentation of Existing Systems Current traffic management systems worldwide share the following structural deficiencies, each of which STSP is designed to resolve: Aldana Flores Expires 2 November 2026 [Page 4] Internet-Draft STSP May 2026 Proprietary protocols prevent interoperability. A city deploying System A cannot coordinate with an adjacent city running System B, even when both cities share the same physical corridor. Static timing plans do not respond to real demand. Fixed green cycles optimized for average conditions perform poorly during peak hours, incidents, special events, or adverse weather. Absence of federation means no city benefits from another city's operational data. Cities independently develop solutions that could be shared. No equivalent of internet routing exists for urban traffic. 2.2. The Technical Opportunity The convergence of edge computing, 5G connectivity, computer vision, and reinforcement learning creates the technical conditions for a fundamentally different approach. STSP specifies the coordination layer -- the protocol -- that allows these technologies to compose into a coherent, federated, open system. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Node A single traffic signal controller implementing STSP. Region A set of nodes within a single administrative boundary (city, district). Federation A collection of Regions participating in the STSP global network. Phase The current signal state of a Node. One of: NS_GREEN, NS_YELLOW, EW_GREEN, EW_YELLOW. Green Wave A coordinated sequence of phase transitions across adjacent Nodes timed to allow vehicles traveling at design speed to encounter consecutive green signals. Degraded Mode The autonomous fixed-cycle operation a Node reverts to when network connectivity is lost. I2I Infrastructure-to-Infrastructure. The communication layer Aldana Flores Expires 2 November 2026 [Page 5] Internet-Draft STSP May 2026 between STSP Nodes. Distinct from V2I (Vehicle-to-Infrastructure) as defined in SAE J2735 and ETSI ITS-G5. STSP/1.0 The wire format and protocol version defined in this document. 4. Protocol Overview STSP operates across three hierarchical layers. Each layer functions independently. Higher layers augment but do not replace lower layers. 4.1. Node Layer Each STSP Node maintains an autonomous state machine governing its phase transitions. The Node broadcasts its current state via the STSP message format at a configurable interval (default: 200ms). A Node MUST be capable of operating indefinitely in Degraded Mode without network connectivity. 4.2. Corridor Layer Nodes within communication range of one another form a corridor. The Green Wave algorithm (Section 7) coordinates phase transitions across corridors based on vehicle travel time between Nodes. 4.3. Federation Layer Regions (cities) connect to the STSP federation via a standardized gRPC interface. Federation enables cross-city route optimization, shared model training via Federated Learning, and global traffic event dissemination. Participation in the federation is OPTIONAL for Node and Corridor layer functionality. 5. Message Format (STSP/1.0) All STSP messages are encoded as JSON objects transmitted over WebSocket [RFC6455] or MQTT (ISO/IEC 20922). Future versions MAY specify binary encoding for bandwidth-constrained deployments. 5.1. Standard STSP Message The following is the normative STSP/1.0 message schema: Aldana Flores Expires 2 November 2026 [Page 6] Internet-Draft STSP May 2026 { "stsp_version": "1.0", "node_id": "MX-QRO-CONST-042", "region_id": "MX-QRO", "grid_row": 2, "grid_col": 4, "latitude": 20.5928, "longitude": -100.4048, "phase": "NS_GREEN", "phase_remaining_ms": 18400, "timestamp_utc": 1746123456.789, "queue_ns": 3, "queue_ew": 0, "density_ns": 0.30, "density_ew": 0.00, "neighbor_ids": ["MX-QRO-CONST-041", "MX-QRO-CONST-043"], "green_wave_offset_ms": 0, "emergency_override": false, "uptime_s": 86432.1, "firmware_ver": "0.1.0", "degraded_mode": false } 5.2. Compact Form For high-frequency broadcasts (greater than 10Hz), Nodes MAY transmit the compact form, which omits static identity fields: { "id": "MX-QRO-CONST-042", "ph": "NS_GREEN", "rm": 18400, "qns": 3, "qew": 0, "ts": 1746123456.789 } 5.3. Phase Enumeration STSP defines four canonical phase values. Implementations MUST NOT use any other values in the "phase" or "ph" fields: NS_GREEN -- North-South has right of way. NS_YELLOW -- Transition from NS_GREEN. Minimum: 3 seconds. EW_GREEN -- East-West has right of way. EW_YELLOW -- Transition from EW_GREEN. Minimum: 3 seconds. Aldana Flores Expires 2 November 2026 [Page 7] Internet-Draft STSP May 2026 Nodes with non-orthogonal street geometry SHOULD map their local phase names to the nearest STSP canonical phase and document the mapping in their configuration. 5.4. Node ID Format Node IDs MUST follow the hierarchical format: {COUNTRY}-{REGION}-{CORRIDOR}-{SEQUENCE} Example: MX-QRO-CONST-042 MX -- ISO 3166-1 alpha-2 country code QRO -- Region/city identifier (max 8 chars, uppercase) CONST -- Corridor identifier (max 8 chars, uppercase) 042 -- Zero-padded sequence number within corridor 6. Node State Machine Each STSP Node implements a deterministic four-state cyclic machine. The transition function f(phase) is defined as: NS_GREEN --[timer_expired]--> NS_YELLOW NS_YELLOW --[timer_expired]--> EW_GREEN EW_GREEN --[timer_expired]--> EW_YELLOW EW_YELLOW --[timer_expired]--> NS_GREEN 6.1. Fixed Mode Phase durations are statically configured. Minimum yellow duration MUST be 3 seconds. Maximum green duration SHOULD NOT exceed 90 seconds. This mode is the mandatory Degraded Mode fallback. Default durations: NS_GREEN 26s, NS_YELLOW 4s, EW_GREEN 26s, EW_YELLOW 4s. 6.2. Adaptive Mode Phase durations are computed dynamically by the Adaptive Controller (Section 8). MIN_GREEN default: 10 seconds. MAX_GREEN default: 45 seconds. 6.3. Emergency Override When emergency_override is set to TRUE by an authenticated and authorized source, the Node MUST immediately transition to a predefined safe state and hold that state for the override duration. The override MUST expire automatically. Manual reset MUST be available at all times. Aldana Flores Expires 2 November 2026 [Page 8] Internet-Draft STSP May 2026 7. Green Wave Synchronization Algorithm 7.1. Offset Calculation When Node N transitions to a green phase, it SHOULD notify its downstream neighbor N+1 to schedule its own green phase transition at time T + delta, where: delta = D / V_design D -- physical distance between N and N+1, in meters V_design -- corridor design speed, in meters per second The notified Node schedules the transition only if it has already served its minimum green duration (MIN_GREEN). 7.2. Bidirectional Propagation Wave propagation is bidirectional. Nodes SHOULD compute offsets for both upstream and downstream neighbors to accommodate traffic in both directions of a corridor simultaneously. 7.3. Priority Resolution When a Node receives conflicting wave triggers from two different corridors simultaneously, it MUST prioritize the trigger with the higher queue density on the requesting direction. 8. Adaptive Phase Control 8.1. Demand Ratio Policy (Normative Baseline) For each green phase, the controller MUST compute: ratio = queue_active / (queue_active + queue_waiting) duration = MIN_GREEN + ratio * (MAX_GREEN - MIN_GREEN) queue_active -- vehicles queued in the currently green direction queue_waiting -- vehicles queued in the opposing direction 8.2. Early Termination A green phase MAY be terminated early (but not before MIN_GREEN) if the ratio of queue_waiting to queue_active exceeds SWITCH_IMBALANCE (default: 1.8) AND queue_active is zero or near-zero (less than 1 vehicle) AND MIN_GREEN has been served. Aldana Flores Expires 2 November 2026 [Page 9] Internet-Draft STSP May 2026 8.3. Reinforcement Learning Extension (Optional) Implementations MAY replace the demand ratio policy with a full reinforcement learning controller, subject to the following normative constraints: State: S = (q_ns_bucket, q_ew_bucket, current_phase) Bucket size: 3 vehicles. Buckets: {0,1,2,3,4} Actions: A = {EXTEND_GREEN, SWITCH_NOW} Reward: R = alpha * throughput - beta * weighted_wait Default: alpha=0.8, beta=1.0 The RL controller MUST respect all hard bounds defined in Sections 6.1 and 6.2. Minimum yellow duration is non-negotiable. 9. Federated Network Architecture 9.1. Data Sovereignty Individual vehicle trajectories and personally identifiable information MUST NOT be transmitted in any STSP message or shared across regional boundaries. Only aggregate queue metrics and phase states are federated. This requirement is normative and reflects a core design principle of STSP. 9.2. Federated Learning Regions participating in the federation MAY share model gradients (not training data) for improving adaptive controllers globally. This approach follows the Federated Learning paradigm and ensures that no city's raw traffic data leaves its administrative boundary. 9.3. Inter-Region Protocol Regions communicate via gRPC over TLS 1.3. The inter-region message format extends the compact STSP message with additional fields for regional routing and model versioning. Full specification is deferred to STSP/2.0. 10. Degraded Mode and Failsafe This section specifies MANDATORY failsafe behavior. Implementations that do not conform to this section MUST NOT be deployed in production traffic infrastructure. Aldana Flores Expires 2 November 2026 [Page 10] Internet-Draft STSP May 2026 10.1. Degraded Mode Triggers A Node MUST enter Degraded Mode automatically upon any of the following conditions: * Network connectivity loss exceeding 30 seconds * Regional engine heartbeat timeout * Hardware sensor failure detected by watchdog * Watchdog timer expiry * Explicit authenticated operator command 10.2. Degraded Mode Behavior In Degraded Mode, the Node MUST: * Revert to fixed-cycle operation with pre-configured durations * Continue operating indefinitely without network connectivity * NOT require operator intervention to enter Degraded Mode * Log the trigger event with UTC timestamp and cause code 10.3. Recovery When connectivity is restored, the Node MAY re-synchronize after a mandatory stabilization period of not less than one complete phase cycle. Re-synchronization MUST be gradual and MUST NOT cause abrupt phase changes visible to road users. 11. Security Considerations Traffic signal infrastructure is critical public safety infrastructure. Implementations MUST address all threat vectors described in this section. 11.1. Message Authentication All STSP messages MUST be authenticated using HMAC-SHA256 or equivalent. Unauthenticated messages MUST be silently discarded. Message replay attacks MUST be mitigated via timestamp validation with a maximum tolerance window of 5 seconds. Aldana Flores Expires 2 November 2026 [Page 11] Internet-Draft STSP May 2026 11.2. Emergency Override Authorization The emergency_override field MUST only be accepted from authenticated sources with explicit override authorization. Unauthorized override attempts MUST be logged and reported to the regional engine immediately. 11.3. Denial of Service Nodes MUST implement rate limiting on incoming STSP messages. A Node receiving more than 100 messages per second from a single source SHOULD enter protective throttle mode and alert the regional engine. 11.4. Physical Security Node hardware MUST be deployed in tamper-evident enclosures rated minimum IP67. Physical access MUST require multi-factor authentication. All tamper events MUST be logged with timestamp and reported to the regional engine. 12. IANA Considerations This document requests the following IANA registrations: * WebSocket Subprotocol "stsp": for STSP/1.0 over WebSocket connections per the WebSocket subprotocol registry ([RFC6455]). * MQTT Topic Namespace "stsp/": reserved for STSP message routing per MQTT specification (ISO/IEC 20922). * A dedicated TCP port number for STSP engine-to-engine communication is requested (specific number pending IANA assignment). The author requests that IANA reserve the "stsp" identifier across relevant registries to prevent namespace collision with future incompatible uses. 13. Reference Implementation A complete reference implementation of STSP/1.0 exists and is operational as of the date of this document. The implementation includes: * Python 3.12 asyncio engine with WebSocket server (RFC 6455) * Intersection state machine (models/intersection.py) Aldana Flores Expires 2 November 2026 [Page 12] Internet-Draft STSP May 2026 * Traffic network model -- 5x4 node grid (models/network.py) * Adaptive controller with demand ratio and Q-Learning derived policy (algorithms/adaptive.py) * Green Wave coordinator with offset calculation (algorithms/ green_wave.py) * STSP protocol encoder/decoder (protocol/stsp.py) * TimescaleDB schema for time-series metrics persistence * Docker Compose stack: engine + Kafka KRaft + Redis + Grafana * REST API: /health, /state, /stats, /mode * Validated on ARM64 (Raspberry Pi 4, 8GB RAM) and Apple M3 Repository: https://github.com/smartflow-stsp/reference [Publication pending] 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . 14.2. Informative References [ETSI-ITS] ETSI, "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications", ETSI EN 302 665, 2019. [McMahan2017] McMahan, H.B., "Communication-Efficient Learning of Deep Networks from Decentralized Data", AISTATS 2017, 2017. Aldana Flores Expires 2 November 2026 [Page 13] Internet-Draft STSP May 2026 [SAE-J2735] SAE International, "Dedicated Short Range Communications (DSRC) Message Set Dictionary", SAE Standard J2735, 2020. Appendix A: RL State Space (Non-Normative) State: S = (q_ns_bucket, q_ew_bucket, current_phase) Actions: A = {EXTEND_GREEN, SWITCH_NOW} Reward: R = 0.8 * throughput - 1.0 * weighted_wait Bucket mapping: 0 -- 0 vehicles (empty) 1 -- 1-3 vehicles (light) 2 -- 4-6 vehicles (moderate) 3 -- 7-9 vehicles (heavy) 4 -- 10+ vehicles (saturated) Appendix B: Glossary IETF Internet Engineering Task Force I2I Infrastructure-to-Infrastructure communication V2I Vehicle-to-Infrastructure communication STSP Smart Traffic Synchronization Protocol SPaT Signal Phase and Timing (SAE J2735) SCATS Sydney Coordinated Adaptive Traffic System SCOOT Split Cycle Offset Optimization Technique RL Reinforcement Learning HMAC Hash-based Message Authentication Code gRPC Google Remote Procedure Call (open protocol) OT Operational Technology (industrial control systems) HSM Hardware Security Module Author's Declarations Aldana Flores Expires 2 November 2026 [Page 14] Internet-Draft STSP May 2026 Declaration of Priority I, Gustavo Angel Aldana Flores, hereby declare that I am the sole inventor and author of the Smart Traffic Synchronization Protocol (STSP) as specified in this document. The conceptual foundation of this protocol was developed independently beginning approximately in 2015. The first working implementation was completed on 1 May 2026 and validated on physical ARM64 hardware (Raspberry Pi 4, 8GB RAM) running a full production stack. This Internet-Draft constitutes the first formal public disclosure of the STSP protocol specification. Declaration of Open Intent I hereby irrevocably dedicate the STSP protocol specification to the global commons under CC BY 4.0 with Open Implementation Clause. My intent is that this protocol serve as open infrastructure for the benefit of cities, governments, and citizens worldwide -- without commercial enclosure -- while preserving permanent attribution to its author. Declaration of Independence This protocol was developed independently, without funding from any government, corporation, or institution. No entity holds rights over this specification other than those expressly granted in the copyright notice. The author is not affiliated with any traffic signal manufacturer, smart city platform provider, or standards body at the time of this writing. Acknowledgements The author developed this protocol independently. This document was first drafted on 1 May 2026 in Peachtree City, Georgia, USA. Author's Address Gustavo Angel Aldana Flores Aldana Innovations Peachtree City, Georgia United States of America Email: g.aldana@aldanainnovations.com URI: https://github.com/smartflow-stsp Aldana Flores Expires 2 November 2026 [Page 15]