{
"chat_uuid": "3ba86aa1-3157-425b-bf52-800cfe5da76d",
"history": [
{
"content": "You have received a document titled Workflow Library: Titles and Summaries. This document contains natural-language summaries of 53 visual analytics workflows drawn from the published research literature. Each summary describes the analytical goal, the workflow structure, and the methodological approach of a specific published workflow. The summaries were extracted from a public workflow library curated by our research group.\n\nPlease read the summaries carefully before we proceed. In the next message I will describe a specific visual analytics design task. Your job will be to design an analytical workflow that addresses the task, drawing on the workflows in the library where relevant. The library is a resource — you may consult it to identify workflow structures, analytical strategies, or methodological approaches that could inform your recommendation for the target task. You are not obliged to use the library workflows, and you may combine elements from multiple workflows, adapt them, or design new steps as the task requires.\n\nPlease describe your recommended workflow in natural language, in sufficient detail that a research analyst could use it as a design template. Where you draw on specific library workflows, please cite them by name so the analyst can trace the sources of your recommendation.\n\nBefore we proceed, could you briefly confirm that you have absorbed the library, and let me know if you have any questions before the task is described? Please reply in English only.",
"role": "user"
},
{
"content": "I have carefully read through the Workflow Library, which contains 53 workflow summaries spanning a wide range of visual analytics domains, including:\n\n- **Temporal/sequential data**: calendar-based clustering, event sequence simplification, event thread analysis, cross-impact detection in time series, IVESA event sequences\n- **Spatial/movement data**: mobility graphs, movement track analysis, progressive trajectory clustering\n- **Network/graph analysis**: dynamic network snapshots, NodeTrix, state transition graphs, RelEx overlay networks\n- **Model understanding & ML interpretability**: EventAction recommendation, exploratory model analysis, binary classifier diagnostics, RfX ensemble exploration, TensorFlow dataflow graphs, What-If Tool, explAIner, RuleSense, compound potency models, VBridge healthcare explanations\n- **Cohort/subgroup analysis**: COQUITO, Coral, Kokiri, single-cell omics cohort comparison\n- **Clustering & dimensionality reduction workflows**: SOMFlow, progressive high-dimensional analysis, knowledge-incorporated embeddings, EnsembleLens\n- **Domain-specific design studies**: DPVis (disease progression), IRVINE (acoustic diagnostics), StratomeX (cancer genomics), Tuner (segmentation parameters), ParaGlide (simulation parameter spaces), Hybrid Visual Steering (engineering simulations), QVis (spatiotemporal ensembles)\n- **Eye-tracking & multimodal analysis**: ISeeCube, Space-Time gaze analytics, Active Gaze Labeling, Image-Based Projection Labeling, Multimodal Collaborative Design\n- **Text/investigative/sensemaking**: Jigsaw, SensePath, topic modeling (UTOPIAN), Visual Movie Analytics, LFPeers temporal peer comparison\n- **Regression/statistical modeling**: Partition-based regression, spatio-temporal modelling, feature engineering for behavior recognition\n\nI have absorbed the analytical goals, workflow structures, and methodological logic of each entry, including the key visual encodings, iterative loops, and citation details needed to trace design decisions back to specific sources.\n\nI'm ready for the design task. I have no questions at this stage — please go ahead and describe the target task, and I will draw on relevant workflows from this library to construct a detailed recommended workflow.",
"role": "assistant"
},
{
"content": "A public health team in Vastopolis, a metropolitan area of about two million residents, has observed a sharp increase in flu-like illnesses over the past few days, with several deaths believed to be associated with the current outbreak. The team wants to understand where the outbreak started and how the infection is being transmitted (person-to-person, airborne, waterborne, or something else) so that emergency management resources can be deployed appropriately.\n\nThe available data consists of: geolocated microblog messages posted from mobile devices over a period of several days, each with a timestamp, GPS coordinates, and text content; a map of the metropolitan area showing highways, hospitals, landmarks, and water bodies; population statistics for 13 city zones; and daily weather observations including wind speed and direction.\n\nThe analyst will need to inspect intermediate results visually and use domain knowledge to interpret patterns and make judgements at each stage.\n\nDesign an analytical workflow for this problem.",
"role": "user"
},
{
"content": "I'm setting up a framework to analyze the Vastopolis outbreak using the microblog data, city geography, population zones, and weather patterns to trace where the outbreak started and how it spread through the population.\n\nI'm drawing on several visualization and analysis techniques from the literature: Jigsaw for extracting entities and symptoms from the microblog text, movement clustering methods to identify significant locations where people congregated, temporal pattern visualization to track when cases appeared, and spatio-temporal modeling to understand how the infection propagated across zones. Some approaches like disease progression visualization and event sequence analysis could help me stage how the infection evolved over time.\n\nThe core workflow is filtering geolocated microblogs for flu-related content, then geocoding and timestamping them to build a spatio-temporal dataset. From there I'd apply density clustering to pinpoint outbreak origins, analyze temporal case counts to determine when and where it started, overlay geographic features like water bodies and highways to test transmission routes, and incorporate wind data to evaluate whether airborne spread explains the observed patterns. Then I'd validate the extracted entities through manual sampling to ensure the classifier is catching the right signals. For the temporal analysis, I'm aggregating message counts across the city and by zone to spot when the outbreak begins, using a calendar view to identify the sharp uptick in activity and clustering similar days to pinpoint the anomaly onset.\n\nFor the spatial component, I'm treating each geolocated flu message as an event and applying density-based clustering to find spatial hotspots and their timing, which helps identify the likely origin versus later spread zones. I'll also normalize incidence rates by population across the 13 zones to account for differences in baseline activity.\n\nIn Stage 4, I'm overlaying the hotspot locations and spread direction against contextual map features—highways for mobility-driven transmission, water bodies for potential contamination sources, landmarks like hospitals that might indicate reporting bias or point-source events—and then comparing the spatial spread pattern of new cases against wind direction and speed data to test whether airborne transmission aligns with the observed spread. cases concentrated in zones sharing that water source rather than spreading diffusively. For case linking, I'd extract social mentions from microblogs—coworkers, shared locations, family connections—to map person-to-person transmission chains and validate whether clusters align with social networks or workplaces. Then I'd iterate through spatial clusters, temporal curves, wind patterns, and text evidence together to test which transmission hypothesis best fits the data.\n\nThe system should coordinate multiple linked views: a map showing heatmaps, hotspot clusters, wind vectors, water bodies, and highways; a timeline tracking case counts colored by cluster; a text panel for reading actual microblog content; and a correlation view checking wind lag against spread timing. I'd also examine severity mentions and death locations—early severe cases near the true source would narrow down the origin point given the incubation period.\n\nNow I'm structuring this as a design template that references established visualization workflows: entity extraction and symptom parsing from raw data with human feedback, temporal aggregation using hourly bins across the outbreak window with burst detection metrics, and spatial hotspot identification to pinpoint significant locations.\n\nFor the spatio-temporal component, I'm drawing on frameworks that group zones by similar temporal patterns and model their growth curves, then examining lagged correlations between wind conditions and disease spread using cross-impact detection methods.\n\nThen I'd extract person-to-person relationships from text data, overlay everything onto a map with contextual features like highways and hospitals, and iterate through the analysis with human feedback to refine hypotheses and build the final narrative.\n\nNow I'm structuring the full answer as a linear pipeline with distinct stages, each tied to specific analytical workflows so someone can actually follow and reproduce the approach. I'll frame it around three core questions—when and where it started, how it spread spatially over time, and what the transmission mechanism was—then walk through stages A through G with the appropriate visual encodings, interactions, and decision points where an analyst needs to make judgments.\n\n# Recommended Analytical Workflow: Vastopolis Outbreak — Origin and Transmission Mechanism\n\nThe task decomposes into three linked analytical questions that should be addressed in sequence but revisited iteratively:\n\n1. **When and where did the outbreak begin?** (spatio-temporal origin detection)\n2. **How did it spread?** (diffusion pattern in space and time)\n3. **What is the likely transmission mechanism** — person-to-person, airborne, waterborne, or other — inferred from how the spread pattern relates to human mobility infrastructure, water bodies, and wind?\n\nBecause microblog text is unstructured, population data is tabular, and weather is a bivariate time series, the workflow combines text-mining/entity-extraction logic (from **Jigsaw**), event-to-place extraction (from **\"From Movement Tracks through Events to Places\"**, Andrienko et al. 2011), spatio-temporal grouping and modelling (from **\"A Visual Analytics Framework for Spatio-Temporal Analysis and Modelling,\"** Andrienko & Andrienko 2013), calendar/temporal-cluster reasoning (from **van Wijk & van Selow's Cluster and Calendar-Based Visualization**), and lagged cross-series analysis (from **\"Detecting Stable Cross-Impact Patterns in Bivariate Time Series,\"** Andrienko et al. 2026) to test the wind/airborne hypothesis specifically.\n\n---\n\n## Stage A — Extract candidate illness events from microblog text\n\n**Goal:** turn raw geolocated text into a structured set of \"illness-report events,\" each with a location, timestamp, and semantic content.\n\n- Build a lexicon of flu-related symptom terms (fever, cough, vomiting, headache, chills, \"sick,\" \"dying,\" \"hospital,\" \"ER,\" etc.) and apply keyword/entity extraction to every message, analogous to Jigsaw's entity extraction step where persons, locations, organizations, and dates are pulled from text. Here the extracted \"entities\" are symptom mentions, severity indicators (e.g., mentions of death or hospitalization), and place/landmark references embedded in the text (which may be more precise than the GPS tag, e.g., \"at the lake festival\").\n- As in Jigsaw, treat extraction as imperfect: the analyst samples and corrects false positives/negatives (e.g., \"flu-like\" sarcasm, unrelated \"sick of my job\" posts) before trusting the derived event set. This mirrors Jigsaw's entity-correction loop and the human-in-the-loop feature-validation step from **\"Feature Engineering for Behaviour Pattern Recognition\"** (Andrienko et al. 2024), where engineered indicators are checked visually against representative examples before being trusted for further analysis.\n- Tag each retained message with a severity level (mild symptom mention vs. severe/death mention), since severity will later help disambiguate early point-source cases from general community spread.\n- Output: a table of geolocated, time-stamped \"illness events,\" each with symptom type(s), severity, and raw text (kept for later drill-down reading).\n\n---\n\n## Stage B — Temporal overview: detect onset and growth pattern\n\n**Goal:** establish *when* the sharp increase began and whether it has a single abrupt onset (point-source signature) or a gradual ramp (person-to-person diffusion signature).\n\n- Aggregate illness-event counts into hourly (or 6-hour) bins, city-wide and per zone, producing a short multivariate time series (13 zones × time).\n- Use a timeline/heatmap overview in the spirit of **IVESA**: sort zones by onset time, event density, or burst intensity; visually inspect for gaps, sudden bursts, and regularity versus irregularity of report accumulation.\n- Where the data spans enough days to show daily rhythm (e.g., normal daytime microblogging vs. night silence), apply the **van Wijk Cluster-and-Calendar** logic: split the series into daily profiles, cluster days by shape (using a normalized or offset-corrected distance so that the outbreak's abnormal shape stands out from the \"normal\" pre-outbreak baseline), and display cluster membership per day. This immediately flags the specific day(s) that break from the baseline pattern — the operational start of the outbreak — without requiring the analyst to predefine a threshold.\n- Judgment point: identify the earliest zone(s) whose case curve deviates from baseline. These are candidates for the spatial origin, to be confirmed in Stage C.\n\n---\n\n## Stage C — Spatial hotspot / significant-place extraction\n\n**Goal:** convert scattered illness events into a small number of interpretable \"significant places,\" and identify which one is earliest (candidate origin).\n\nThis stage directly follows the workflow in **\"From Movement Tracks through Events to Places\"** (Andrienko et al. 2011), substituting illness-report events for the paper's m-events:\n\n- Apply density-based clustering (DBSCAN-like) to the illness events in space and time jointly, using a distance function that combines spatial proximity and temporal proximity (and optionally symptom similarity), so that events close in space but far apart in time are *not* merged, and events in different unrelated locations are not merged. Isolated events are treated as noise.\n- Build spatial buffers/hulls around each event cluster to delineate candidate \"outbreak places\" (e.g., a park, a water treatment plant vicinity, a stadium, a hospital catchment).\n- For each place, compute a small time series of event counts, enabling a \"when did this place become active\" comparison across places — mirroring the paper's aggregation of events by place into time series.\n- Cross-reference the earliest, most severe cluster(s) with the city map's landmark layer (hospitals, water bodies, event venues) to see whether the earliest cluster coincides with a specific fixed feature (e.g., a reservoir, a festival ground) — a signature consistent with a point-source (waterborne or common-exposure) event, as opposed to diffuse residential spread consistent with person-to-person transmission.\n- Normalize event counts per place/zone by the 13-zone **population statistics**, producing incidence-per-capita rather than raw counts, since a raw count of reports may simply reflect population density or Twitter usage density rather than true attack rate.\n\n---\n\n## Stage D — Spatio-temporal grouping and growth modelling across zones\n\n**Goal:** determine whether the 13 zones behave as one expanding front (diffusion) or as several independently-seeded clusters (multiple point sources / common exposure).\n\nFollowing the **Spatio-temporal Analysis and Modelling** framework (Andrienko & Andrienko, 2013):\n\n- Treat each zone's per-capita incidence time series as one spatial time series. Cluster zones by similarity of temporal profile (e.g., k-means or hierarchical clustering on normalized incidence curves), using a linked time-graph + map display so the analyst can check whether temporally similar zones are also spatially adjacent (supporting contiguous diffusion, e.g., along highways) or spatially disconnected (supporting a shared non-contact cause, e.g., a common water source or wind-borne plume).\n- Fit a simple growth model (e.g., exponential/logistic onset curve) to each group's representative curve and inspect residuals over time and space, as in the source workflow, to detect zones that deviate from the dominant growth pattern — these deviating zones are candidates for a distinct secondary source or a differently-timed exposure (e.g., a downwind zone affected only after a wind-driven delay).\n- Overlay zone clusters on the map together with the highway network: if the incidence-similar/temporally-lagged zones are strung along major highways or transit corridors, this favors person-to-person/mobility-driven spread; if they are unrelated to the road network but spatially coincide with a shared water body or its service area, this favors waterborne transmission; if they align with a downwind sector regardless of road connectivity or population contact, this favors airborne spread.\n\n---\n\n## Stage E — Wind–spread cross-impact analysis (testing the airborne hypothesis specifically)\n\n**Goal:** rigorously test whether the direction and timing of spread is statistically consistent with wind advection from the candidate origin, using a lagged-correlation approach rather than eyeballing alone.\n\nThis stage directly adapts **\"Detecting Stable Cross-Impact Patterns in Bivariate Time Series\"** (Andrienko et al., 2026):\n\n- Define the **base series** as the daily wind vector (speed and direction) at/near the candidate origin place identified in Stage C.\n- Define the **response series** as a directional exposure measure per zone: e.g., the daily per-capita incidence in each of the other 12 zones, or better, a projected \"downwind alignment score\" per zone (how well the zone's bearing from the origin matches the day's wind direction).\n- Slide a time window across the base series and compare it with time-shifted windows of each zone's response series over a range of plausible incubation lags (using a tolerance-based association measure such as the paper's tolerance-Kendall's-tau, which is robust to noisy daily fluctuations).\n- Visualize the resulting time×lag impact matrix with an Ikat-style plot for each zone (or for an aggregated \"downwind vs upwind\" comparison), and calibrate window length, lag range, and tolerance interactively while cross-checking against the actual wind and incidence series behind any cell.\n- **Interpretation:** if downwind zones show a consistent positive impact at a lag plausible for airborne incubation/dispersal, and upwind/crosswind zones do not, this is strong evidence for airborne transmission from the identified origin. If no stable directional lag pattern emerges (spread is equally likely upwind, downwind, and cross-wind, or tracks population/road proximity instead), airborne transmission from a single point source is less supported, and the analyst should weight person-to-person or waterborne explanations more heavily.\n\n---\n\n## Stage F — Person-to-person and waterborne hypothesis checks\n\n**Goal:** directly test the two remaining mechanisms using complementary evidence, since Stage E only tests the wind/airborne hypothesis.\n\n- **Person-to-person check:** using the corrected illness-event set from Stage A, extract social/co-location mentions from the text (e.g., \"my coworker,\" \"my whole family,\" shared venues, shared bus/train lines) — the same entity/relation-extraction logic as **Jigsaw**, here applied to build a light co-occurrence network of people/places mentioned together. If cases chain along social/mobility links (school, workplace, transit routes) and the spatial growth in Stage D tracks the highway/transit network rather than a single fixed landmark, this supports person-to-person spread following normal human contact and commuting patterns.\n- **Waterborne check:** overlay the earliest and largest clusters from Stage C directly on the map's water-body layer and any known water-distribution/service-area boundaries for the 13 zones (if available via the population/zone metadata). A waterborne signature would show: (a) an origin cluster physically coincident with a water source (reservoir, treatment plant, river) rather than a crowded public venue; (b) case distribution matching the water utility's service zones rather than geographic proximity or road adjacency; (c) no dependence on wind direction (ruling out Stage E's airborne signature) and no dependence on social/mobility chains (ruling out Stage F's person-to-person signature).\n- Because these are complementary, mutually-exclusive-leaning hypotheses, structure this stage as a comparison table/checklist: for each candidate mechanism, list the diagnostic spatial/temporal/contextual signature expected, and whether the data satisfies it — supporting transparent, auditable reasoning rather than a single black-box conclusion.\n\n---\n\n## Stage G — Synthesis, drill-down, and reporting\n\n**Goal:** consolidate findings into a defensible narrative the public-health team can act on.\n\n- Maintain a coordinated multi-view dashboard throughout: (1) a map view showing hotspot clusters, water bodies, highways, hospitals, and wind vectors per day; (2) a timeline/calendar view showing zone-level incidence and cluster membership over time; (3) a text drill-down panel to re-read raw microblog content behind any cluster or spike (essential domain-knowledge check, as emphasized throughout Jigsaw's Document View and the raw-record drill-downs in DPVis and Kokiri); (4) the Ikat-style wind-impact panel from Stage E; (5) a zone table with population-normalized rates.\n- Use an iterative \"propose → visualize → validate against raw text/map → refine\" loop, consistent with the general pattern seen across the library (e.g., **explAIner's** understand–diagnose–refine cycle and **SOMFlow's** provenance-tracked iterative refinement): each hypothesis about origin or mechanism should be checked against raw messages and map context before being accepted, and parameter choices (clustering distance, lag window, tolerance) should be logged so the reasoning is reproducible.\n- Deliverable: a short evidence-linked report identifying (a) the most probable origin place and time window, (b) the dominant spread pattern (contiguous/road-following vs. wind-directional vs. water-service-area-bound), and (c) the best-supported transmission mechanism with the specific visual/statistical evidence (Stage C cluster map, Stage D growth/residual plots, Stage E Ikat wind-lag plot, Stage F checklist) cited for each claim, so emergency-management resources can be targeted (e.g., quarantine/contact-tracing near roads, water-supply intervention, or air-quality/evacuation measures) accordingly.",
"role": "assistant"
},
{
"content": "Make a list of papers from which you have taken relevant approaches.",
"role": "user"
},
{
"content": "Here is the list of papers/workflows from the Workflow Library that I drew on for the Vastopolis outbreak-analysis design, with a note on what specific approach or logic was taken from each:\n\n## Papers Cited in the Recommended Workflow\n\n1. **Jigsaw: Supporting Investigative Analysis through Interactive Visualization**\n J. Stasko, C. Görg, and Z. Liu. *Information Visualization*, 7(2), 118–132, 2008. doi: 10.1057/palgrave.ivs.9500180\n *Used for:* entity/keyword extraction from microblog text (Stage A), human correction of extraction errors, and the raw-text drill-down/document-verification logic (Stage G); also informed the co-occurrence/relation-extraction approach for testing person-to-person transmission (Stage F).\n\n2. **From Movement Tracks through Events to Places: Extracting and Characterizing Significant Places from Mobility Data**\n G. Andrienko, N. Andrienko, C. Hurter, S. Rinzivillo, and S. Wrobel. IEEE VAST, 2011. doi: 10.1109/VAST.2011.6102454\n *Used for:* the core event-to-place extraction logic in Stage C — converting geolocated illness-report \"events\" into density-clustered \"significant places\" using combined spatio-temporal distance functions, then aggregating events into per-place time series.\n\n3. **Cluster and Calendar Based Visualization of Time Series Data**\n J. J. van Wijk and E. R. van Selow. IEEE InfoVis '99, 1999. doi: 10.1109/INFVIS.1999.801851\n *Used for:* the daily-profile clustering and baseline-deviation detection approach in Stage B, applied to detect the onset day(s) that break from the \"normal\" pre-outbreak pattern.\n\n4. **A Visual Analytics Framework for Spatio-Temporal Analysis and Modelling**\n N. Andrienko and G. Andrienko. *Data Mining and Knowledge Discovery*, 27(1), 55–83, 2013. doi: 10.1007/s10618-012-0285-7\n *Used for:* the zone-grouping, representative-curve modelling, and residual-inspection logic in Stage D — clustering the 13 zones by temporal incidence similarity and checking spatial coherence against the map.\n\n5. **Detecting Stable Cross-Impact Patterns in Bivariate Time Series**\n G. Andrienko, N. Andrienko, M. Akila, B. Kathirgamanathan, and M. Ponce-de-Leon. IEEE TVCG, 32(7), 5996–6013, 2026. doi: 10.1109/TVCG.2026.3676810\n *Used for:* the lagged cross-impact/Ikat-plot methodology in Stage E, adapted to test whether wind direction/timing at the candidate origin is followed by consistent downwind incidence increases (airborne hypothesis testing).\n\n6. **Human-in-the-Loop: Visual Analytics for Building Models Recognizing Behavioral Patterns in Time Series** (Feature Engineering for Behaviour Pattern Recognition)\n N. Andrienko, G. Andrienko, A. Artikis, P. Mantenoglou, and S. Rinzivillo. IEEE Computer Graphics and Applications, 44(3), 14–29, 2024. doi: 10.1109/MCG.2024.3379851\n *Used for:* the human-in-the-loop validation principle applied in Stage A — visually checking extracted symptom/severity indicators against representative examples before trusting them for further analysis.",
"role": "assistant"
},
{
"content": "You have designed a visual analytics workflow for a specific task, expressing it in natural language. In this second stage, I am now uploading the ATWL specification and one example workflow expressed in ATWL. Your task is to produce an ATWL representation of the workflow you designed in the previous stage.\n\nThis is not a mechanical translation. Please express your workflow in the ATWL vocabulary using its artifact types, transform intents, actor designations, loop constructs, and specification artifacts in the way that most faithfully captures the analytical process you described in your natural-language recommendation. Where your natural-language description implied structure that is naturally expressed as an ATWL construct (for example, an iterative refinement step that is naturally expressed as a loop with an assess transform and a specification artifact), please make this structure explicit in the ATWL representation.\n\nAt the same time, please be honest about what your original recommendation supports. If a phase of your workflow was described only as a linear sequence of steps without explicit iteration, without human-machine actor distinctions, or without specifications being updated, please do not fabricate these elements to make the ATWL representation appear more sophisticated. The goal is to represent, in ATWL, the workflow you actually designed, not a hypothetically enhanced version of it.\n\nAfter you produce the ATWL representation, please briefly note any structural elements you added that were implicit in your original recommendation. This helps me understand the difference between what your original design communicated explicitly and what your ATWL representation makes explicit. If some structural elements in the ATWL are new additions rather than translations of what was already there, please say so.\n\nPlease read the ATWL specification and the example carefully before proceeding. Do you have any questions about the language or the syntax before you produce the ATWL representation?",
"role": "user"
},
{
"content": "I'm working through how to represent my Vastopolis workflow using ATWL constructs, starting with mapping the input artifacts. I need to clarify the structure of the microblogs data—specifically how entities and their embedment properties relate to the messages and their geolocation information.\n\nFor the map features, I'm thinking of this as a separate artifact containing static geographic entities like highways, hospitals, landmarks, and water bodies, each with spatial embedment and categorical type features. I'm also defining the zones artifact as regional entities with population statistics, and starting to work through the weather data structure.\n\nNow I'm moving into Stage A of the analysis pipeline, which focuses on extracting candidate illness events from the microblog text. I'm designing a transformation that uses keyword and entity extraction to pull symptom and severity indicators from the text, drawing on a symptom lexicon. The key insight here is treating this extraction as inherently imperfect—like in Jigsaw—so I'm building in a human-in-loop validation step where an analyst can sample and correct false positives and negatives before the derived event set gets trusted. Once the lexicon is refined, I exit the validation loop and move on to filtering the microblogs to identify actual illness events—keeping only those messages that contain the validated symptom and severity indicators, with both human review and automated filtering working together to create the final dataset of illness-related posts.\n\nNow I'm structuring these illness events with temporal and spatial embeddings, storing features like symptom type, severity level, and the raw text for reference, then moving into the temporal analysis phase where I'll aggregate the events into time bins organized by zone and time period to detect patterns and onset timing. Now I'm adding the hourly profile as a feature on each day, then clustering those days by the similarity of their profile shapes to create day clusters with categorical labels. Finally, I'm arranging these clustered days within a calendar structure for temporal context. ern as a textual description of the onset day(s) and deviating zones. From this pattern, I'm formulating candidate statements about the earliest zones and onset time windows that deviate from baseline. Then moving into Stage C, I'm defining spatial hotspots by applying spatio-temporal density clustering to the illness events to extract significant places. I'm normalizing the event counts by population to get per-capita incidence rates, then mapping these place clusters onto geographic features like landmarks and water bodies, and finally visualizing the resulting hotspots on an interactive map.\n\nFrom the visualization, I'm identifying candidate origin locations by examining where the earliest and most severe clusters coincide with fixed geographic features like reservoirs or festival grounds. Now I'm moving into zone-level analysis to compute per-capita incidence rates across different geographic zones and model how the outbreak spreads over time. Now I'm mapping the zone groups onto the geographic features like highways, then fitting growth curves to the incidence data for each zone group to capture exponential or logistic patterns. After that, I'm computing the residuals between the observed incidence and the model predictions to see where the growth model deviates from reality, and visualizing those residuals.\n\nNext, I'm interpreting the spatial patterns by looking at whether zones with similar temporal dynamics are clustered together along highways (suggesting diffusion) or scattered apart (suggesting shared exposure), flagging any zones that don't fit the pattern. Then I'm moving into analyzing how wind patterns might explain spread across zones, starting with establishing baseline wind data at the origin point and measuring how zone incidence responds to it.\n\nI'm computing a directional alignment score for each zone that captures how well it aligns with the prevailing wind direction from the suspected origin, then partitioning the time series into sliding windows to compare the base wind signal against zone incidence responses across different time lags. F_impact_matrix gets visualized as a wind impact plot, then I'm setting up a calibration loop that iteratively refines the window length, lag range, and tolerance parameters until the impact matrix reveals a stable, interpretable directional lag pattern that either supports or contradicts the airborne hypothesis. Inside this loop, I'm assessing the impact patterns to guide the calibration process. Now I'm formulating statements about airborne transmission evidence based on the downwind lag patterns observed in the impact matrix. Moving into Stage F, I need to extract social contact mentions from the illness event data to check person-to-person transmission, then define the entities and relationships for a co-occurrence network.\n\nI'm visualizing this social network as a node-link diagram to identify whether cases cluster along social and mobility connections that align with highway or transit routes. The waterborne hypothesis check is coming next.\n\nNow I'm overlaying water bodies and service zones on the map to examine potential waterborne transmission patterns, then comparing all three hypotheses—airborne, person-to-person, and waterborne—against the evidence to identify which mechanisms best explain the outbreak. I'm deciding whether to represent the coordinated dashboard as a separate visualization or just note that the views work together, and I'm treating the general iterative loop of proposing, visualizing, and refining as an underlying principle rather than a distinct artifact since I've already modeled specific validation loops. Now I'm ready to sketch out the template structure, starting with how the stages connect—extraction and filtering in stage A, then moving into daily episode definition and clustering.\n\nContinuing through the remaining stages: places are derived and contextualized with visualization and abstraction, zones get clustered with residual analysis and model building, windows capture cross-impacts through iterative visualization and assessment, the social network gets visualized with a water overlay for additional context, and finally the report synthesizes everything. I'm framing this as a template using intents where characterization feeds into assessment loops that cycle back to refine the characterization. Writing template structure... Continuing through the remaining analysis steps—wind alignment and lag windows to assess cross-impacts, then social media mentions and network analysis, water overlay visualization, and finally the mechanism checklist and report generation. Now I'm ready to write out the full ATWL body systematically with all artifacts and transforms, making sure the entity definitions align with the spec.\n\nDefining the microblogs artifact with elementary structure, space-time embedment, and text content as the key feature. Then the map features artifact capturing static geographic elements like highways and landmarks. Moving into the zones artifact next... I'm defining a symptom lexicon with flu-related terms and severity indicators, then setting up a text extraction transform that pulls symptom mentions and severity signals from the microblogs using this lexicon to generate symptom features.\n\nThe extracted features capture symptom types, severity levels, and place references for each message, and I'm establishing a validation loop where a human samples and inspects the extracted indicators against the raw text to assess extraction quality until the false positive and negative rates reach an acceptable threshold. After refining the lexicon based on the validation results, I update the extracted features and lexicon artifacts, then either loop back to re-extract with the improved rules or exit the validation loop if quality is acceptable. Next, I'm moving into defining illness events as a higher-level unit from the extracted symptom indicators. Now I'm defining the time-partitioning stage to aggregate these illness events into hourly or 6-hour bins grouped by zone and day, creating daily episode records with vector counts and temporal metadata.\n\nNext, I'm characterizing each daily episode by normalizing its hourly count patterns into comparable profile shapes that can be used for clustering and baseline deviation analysis.\n\nThen I'm setting up a clustering transform that groups days together based on the similarity of their daily profile shapes...\n\nDefining cluster artifacts... Defining the calendar visualization that marks each day's cluster membership to highlight baseline versus deviating patterns, then moving into the abstraction layer for detecting onset days. Now I'm defining a machine-driven clustering stage that groups illness events by spatial and temporal proximity to identify candidate outbreak locations, filtering out isolated cases as noise, and tracking which events belong to each place cluster. Defining the place-level time series feature and then normalizing event counts by population to get per-capita incidence rates for each place, which I'll then arrange on a map for visualization. Continuing the visualization description with the map hotspots showing candidate places encoded by color and size based on incidence and timing, overlaid on geographic features. Then I'm moving to the abstraction phase where a human interprets these visual patterns to identify the most likely origin location(s).\n\nNow I'm shifting to Stage D, where I need to compute per-capita incidence rates for each of the 13 zones by normalizing the illness events against population data, creating a time series for each zone.\n\nThen I'm clustering these zones based on how similar their temporal incidence patterns are, grouping them together and assigning categorical labels to identify which zones share comparable outbreak trajectories.\n\nNext, I'm positioning these zones on a map context that includes the highway network, using geographic coordinates to show their spatial relationships. Finally, I'm creating a visualization that colors the zones according to their similarity groups on this map, incorporating the underlying map features to provide geographic context. Now I'm fitting exponential or logistic growth curves to each temporal group's incidence pattern to model how the outbreak expanded within each zone cluster. Then I'll compute the residuals between observed and fitted values to identify zones that deviate from their group's typical growth trajectory.\n\nI'm creating a visualization that overlays these residuals on a geographic map or aligned timeline view, highlighting zones with unusually large deviations that might indicate a separate infection source or delayed exposure pattern.\n\nNow I need to interpret the overall spread pattern by examining whether the zone groupings align with transportation networks and mobility corridors—suggesting person-to-person transmission—or if they're spatially scattered in ways that point toward a shared environmental exposure, while flagging any anomalous zones as potential secondary sources.\n\nMoving into the next phase, I'm computing how well each zone's directional bearing from the suspected origin aligns with the prevailing wind direction on each day, creating a feature that captures this downwind alignment for every zone.\n\nNow I need to establish the lag specification parameters—the initial window size, range of possible lags, and tolerance thresholds—that will guide the cross-impact analysis between wind patterns and the zone response series. Then I'm partitioning both the weather data and each zone's incidence and alignment series into sliding windows across different plausible incubation lags to enable comparison.\n\nNext I'm computing a tolerance-based association measure like tolerance-Kendall's-tau across this window and lag grid to quantify how strongly wind conditions in one zone predict response patterns in downwind zones, producing a matrix indexed by zones with numeric values representing the lagged associations.\n\nThen I'm setting up a calibration loop where I iteratively adjust the window length, lag range, and tolerance parameters until the resulting impact matrix reveals a stable directional lag pattern—or confirms there isn't one—that's interpretable enough to test the airborne hypothesis. Within that loop, I'm visualizing the impact matrix as an ikat-style plot to inspect the time-lag patterns across zones. ield a stable, interpretable impact pattern by cross-checking any anomalies against the actual wind and incidence data. This judgment then feeds into a refinement loop where I adjust the window length, lag range, or tolerance parameters if needed to improve the matrix quality.\n\nI'm realizing the loop structure needs adjustment—the cross-impact computation should happen inside the calibration loop itself, not just once at the start, so that each iteration recalculates the impact matrix with the updated lag specifications. I need to compute the downwind alignment once before the loop since it doesn't depend on the lag spec, then set up the main loop to recompute the windows and impact matrix each iteration based on the evolving spec. The loop continues until the impact matrix stabilizes enough to evaluate the airborne transmission hypothesis. The refinement loop continues iteratively until the impact quality assessment indicates no further changes are needed, at which point we exit and move toward generating knowledge statements about airborne evidence using the final impact visualization and matrix.\n\nNow I'm defining a transformation to extract social context mentions from the illness events data, identifying shared locations, social connections, and transportation patterns that might indicate person-to-person transmission routes.\n\nThen I'm building a co-occurrence network from these social mentions, where nodes represent people and places, and edge weights capture how frequently they appear together across different illness events.\n\nNow I'm creating a force-directed visualization of this network so we can see the contact chains and mobility patterns among cases at a glance.\n\nAbstracting person-to-person patterns... I'm creating a map visualization that overlays the hotspot clusters directly onto water bodies and service-area boundaries to check whether cases cluster around water sources. Then I need to interpret this visual pattern to identify whether waterborne transmission explains the distribution. Defining the mechanism assessment checklist... Checking that all declared artifacts are used before reference, verifying feature value types like categorical and ordinal are valid, and confirming the mixed-type vector structure for symptom features works within the spec. Now I'm aligning the template with the actual transform sequence, using loop notation consistently for the extraction and wind analysis loops while avoiding unnecessary nesting. Writing the ATWL template... Checking that F_impact_matrix's type declaration aligns with its structure as a time-by-lag matrix per zone, which matches the pairwise similarity matrix pattern. P_spread_pattern is referenced later in Stage F, and it's properly declared earlier as an output from the abstract transform in Stage D. Now I need to verify whether V_wind_impact, which is declared inside the loop body, remains accessible to K_airborne_evidence after the loop completes.\n\nLooking at the example, artifacts defined within loop iterations like D_clusters and V_clusters are referenced later at Step 4 outside the loop, using their final state from the last iteration. This confirms that the pattern of consuming loop-body artifacts after the loop ends is valid in ATWL, which means my design using V_wind_impact and F_impact_matrix after L_wind_analysis follows the same established style.\n\nNow I'm verifying the remaining pieces: K_impact_quality stays confined to the loop, S_lag_spec follows the reassignment pattern where it's given initially then only modified inside the loop if refinement is needed. With those confirmed, I'm ready to finalize the workflow template string that sequences the transforms in order, starting with extracting symptom features, looping through assessment and lexicon refinement, then moving through the unit definitions, characterizations, and visualizations.\n\nContinuing with the full template: after the initial symptom processing and daily profiling, the workflow branches into geographic analysis—deriving places, computing timeseries and per-capita incidence, mapping and visualizing—then clustering zones and modeling growth patterns with residual analysis. It then examines downwind alignment through a loop of lag windows and cross-impact assessment, followed by social network analysis and water overlay visualization. I've got everything I need from the spec and attachments, so I'll proceed directly to producing the ATWL representation along with notes on the structural elements that became explicit in this formalization.\n\nI've read the ATWL specification and the example workflow carefully. No questions — I'll proceed directly to the ATWL representation of the Vastopolis workflow.\n\n```atwl\nworkflow vastopolis-outbreak-origin-and-transmission\n template: characterise (extract-symptom-features) ->\n loop(assess -> characterise (refine-lexicon)) ->\n define-unit (filter-illness-events) ->\n define-unit (daily-episodes) -> characterise (daily-profile) ->\n define-unit (cluster-days) -> contextualise (calendar) ->\n visualise -> abstract -> generate-knowledge ->\n define-unit (derive-places) -> characterise (place-timeseries) ->\n characterise (per-capita-incidence) -> contextualise (map) ->\n visualise -> abstract ->\n characterise (zone-incidence) -> define-unit (cluster-zones) ->\n contextualise (map) -> visualise -> build-model (growth) ->\n characterise (residuals) -> visualise -> abstract ->\n characterise (downwind-alignment) ->\n loop(define-unit (lag-windows) -> characterise (cross-impact) ->\n visualise -> assess) ->\n generate-knowledge ->\n characterise (social-mentions) -> define-unit (social-network) ->\n visualise -> abstract ->\n visualise (water-overlay) -> abstract ->\n generate-knowledge (mechanism-checklist) ->\n generate-knowledge (final-report)\n description: \"Visual analytics workflow for identifying the spatio-temporal\n origin of a flu-like outbreak in Vastopolis from geolocated microblogs,\n and for adjudicating among candidate transmission mechanisms (airborne,\n person-to-person, waterborne) using map, population, and wind data.\"\n\n# ============================================================================\n# INPUT ARTIFACTS\n# ============================================================================\n\nartifact D_microblogs : entities\n origin: given\n internal structure: elementary\n embedment: {space, time}\n features:\n - id: text_content\n value structure: atomic\n value type: text\n description: \"Raw message text\"\n description: \"Geolocated microblog messages posted from mobile devices\n over several days, each with timestamp, GPS coordinates, and text\n content\"\n\nartifact D_map_features : entities\n origin: given\n internal structure: elementary\n embedment: space\n features:\n - id: feature_type\n value structure: atomic\n value type: categorical\n description: \"Category of map feature: highway, hospital, landmark,\n water body\"\n description: \"Static geographic features of the Vastopolis metropolitan\n area, used as map context\"\n\nartifact D_zones : entities\n origin: given\n internal structure: region\n embedment: space\n features:\n - id: population\n value structure: atomic\n value type: numeric\n description: \"Resident population of the zone\"\n description: \"13 city zones of Vastopolis with population statistics\"\n\nartifact D_weather : entities\n origin: given\n internal structure: elementary\n embedment: time\n features:\n - id: wind_speed\n value structure: atomic\n value type: numeric\n description: \"Daily wind speed\"\n - id: wind_direction\n value structure: atomic\n value type: {numeric, spatial}\n description: \"Daily wind direction (bearing)\"\n description: \"Daily weather observations including wind speed and\n direction\"\n\nartifact D_calendar : entities\n origin: given\n internal structure: elementary\n embedment: time\n features:\n - id: date\n value structure: atomic\n value type: temporal\n description: \"Calendar date\"\n description: \"Calendar days spanning the observation period, used as\n arrangement context\"\n\nartifact S_symptom_lexicon : specification\n origin: given\n representation form: \"keyword lexicon\"\n description: \"Flu-related symptom terms and severity indicators (fever,\n cough, vomiting, hospital, death, etc.) used to seed text extraction\"\n\n# ============================================================================\n# STAGE A: EXTRACT AND VALIDATE ILLNESS-REPORT EVENTS FROM TEXT\n# ============================================================================\n\ntransform T_extract_symptoms :\n intent: characterise\n manner: \"extract (keyword/entity extraction of symptom and severity\n terms)\"\n input: D_microblogs, S_symptom_lexicon\n output: F_symptom_features\n actor: machine\n description: \"Extract symptom mentions, severity indicators\n (hospitalization, death), and embedded place references from message\n text\"\n\nartifact F_symptom_features : feature(D_microblogs)\n value structure: vector\n value type: {categorical, ordinal, text}\n description: \"Per-message symptom type(s), severity level, and any\n embedded place mentions\"\n\nloop L_extraction_validation:\n purpose: \"Validate and correct automatically extracted symptom/severity\n indicators against raw message text before trusting the derived event\n set\"\n until: \"Sampled false positive/negative rate in extracted indicators is\n acceptable to the analyst\"\n body:\n\n transform T_assess_extraction :\n intent: assess\n manner: \"sample and inspect raw text against extracted indicators\"\n input: F_symptom_features, D_microblogs\n output: K_extraction_quality\n actor: human\n description: \"Sample messages and check extracted symptom/severity\n labels against raw text for false positives (e.g., sarcastic\n 'sick of...') and false negatives\"\n\n artifact K_extraction_quality : knowledge(F_symptom_features)\n representation form: \"quality judgment\"\n description: \"Judgment of whether extraction lexicon/rules yield an\n acceptable false positive/negative rate\"\n\n if K_extraction_quality indicates refinement needed:\n then:\n transform T_refine_lexicon :\n intent: characterise\n manner: \"refine extraction lexicon/rules\"\n input: D_microblogs, S_symptom_lexicon, K_extraction_quality\n output: F_symptom_features_r, S_symptom_lexicon_r\n actor: human\n description: \"Adjust keyword lexicon or extraction rules based on\n observed errors and re-extract\"\n\n artifact F_symptom_features_r : feature(D_microblogs)\n value structure: vector\n value type: {categorical, ordinal, text}\n description: \"Updated per-message symptom/severity/place-mention\n indicators\"\n\n artifact S_symptom_lexicon_r : specification\n representation form: \"keyword lexicon\"\n description: \"Revised symptom lexicon\"\n\n assign:\n F_symptom_features := F_symptom_features_r\n S_symptom_lexicon := S_symptom_lexicon_r\n else:\n exit loop L_extraction_validation\n\nend loop L_extraction_validation\n\ntransform T_define_illness_events :\n intent: define-unit\n manner: \"filter messages with validated symptom/severity indicators\"\n input: D_microblogs, F_symptom_features\n output: D_illness_events\n actor: hybrid\n description: \"Retain only messages carrying validated illness-related\n indicators as geolocated, time-stamped illness-report events\"\n\nartifact D_illness_events : entities\n internal structure: elementary\n embedment: {space, time}\n features:\n - id: symptom_type\n value structure: atomic\n value type: categorical\n description: \"Symptom type(s) mentioned\"\n - id: severity\n value structure: atomic\n value type: ordinal\n description: \"Severity level (mild symptom vs.\n severe/hospitalization/death mention)\"\n - id: raw_text\n value structure: atomic\n value type: text\n description: \"Original message text retained for drill-down\"\n description: \"Geolocated, time-stamped illness-report events derived from\n validated microblog messages\"\n\n# ============================================================================\n# STAGE B: TEMPORAL OVERVIEW - ONSET DETECTION\n# ============================================================================\n\ntransform T_define_days :\n intent: define-unit\n manner: \"time-partitioning into per-zone daily episodes\"\n input: D_illness_events, D_zones\n output: D_days\n actor: machine\n description: \"Aggregate illness events into hourly/6-hour bins and group\n into daily episodes per zone\"\n\nartifact D_days : entities\n internal structure: episode\n embedment: {set, time}\n features:\n - id: hourly_counts\n value structure: vector\n value type: numeric\n description: \"Hourly (or 6-hour) event counts within the day, per\n zone\"\n description: \"Per-zone daily episodes of illness-event counts\"\n\ntransform T_characterise_daily_profile :\n intent: characterise\n manner: \"profile\"\n input: D_days\n output: F_daily_profile\n actor: machine\n description: \"Normalise hourly count vectors into comparable daily shape\n profiles\"\n\nartifact F_daily_profile : feature(D_days)\n value structure: vector\n value type: numeric\n representation form: \"daily count profile\"\n description: \"Normalized daily profile shape used for baseline-deviation\n clustering\"\n\ntransform T_cluster_days :\n intent: define-unit\n manner: \"cluster-by-similarity of daily profile shape\"\n input: D_days, F_daily_profile\n output: D_day_clusters, F_day_cluster_label\n actor: machine\n description: \"Cluster days by profile shape so that days deviating from\n the pre-outbreak baseline pattern are separated out\"\n\nartifact D_day_clusters : entities\n internal structure: group/cluster\n embedment: set\n description: \"Groups of days with similar profile shape (baseline vs.\n deviating clusters)\"\n\nartifact F_day_cluster_label : feature(D_days)\n value structure: atomic\n value type: categorical\n description: \"Cluster membership label (baseline vs. deviating) for each\n day\"\n\ntransform T_arrange_calendar :\n intent: contextualise\n manner: \"calendar-based\"\n input: D_days, D_calendar\n output: A_calendar\n actor: machine\n description: \"Position each per-zone daily episode in its corresponding\n calendar cell\"\n\nartifact A_calendar : arrangement(D_days)\n context: D_calendar\n principle: \"calendar(date, zone)\"\n description: \"Calendar-based arrangement of daily episodes per zone\"\n\ntransform T_vis_calendar :\n intent: visualise\n manner: \"coloured-marks\"\n input: A_calendar, F_day_cluster_label\n output: V_calendar_clusters\n actor: machine\n description: \"Calendar view showing cluster membership (baseline vs.\n deviating) of each day, per zone\"\n\nartifact V_calendar_clusters : visualisation(A_calendar, F_day_cluster_label)\n layout: \"calendar grid per zone\"\n form: \"coloured marks\"\n encoding: \"layout: from A_calendar (day -> calendar cell); colour: from\n F_day_cluster_label\"\n description: \"Visual overview for spotting onset day(s) and\n earliest-deviating zones\"\n\ntransform T_abstract_onset :\n intent: abstract\n manner: \"perception-and-interpretation\"\n input: V_calendar_clusters\n output: P_onset_pattern\n actor: human\n description: \"Identify the earliest day(s) and zone(s) whose profile\n breaks from the baseline pattern\"\n\nartifact P_onset_pattern : pattern(D_days)\n representation form: \"textual description\"\n description: \"Description of onset day(s) and earliest-deviating\n zone(s)\"\n\ntransform T_knowledge_onset :\n intent: generate-knowledge\n manner: \"formulate-statements\"\n input: P_onset_pattern\n output: K_onset_candidates\n actor: human\n description: \"Formulate candidate outbreak onset time window and\n earliest zone(s) as working hypothesis for spatial origin\"\n\nartifact K_onset_candidates : knowledge(D_days)\n representation form: \"statements\"\n description: \"Candidate onset time window and earliest-affected zone(s),\n to be confirmed against place-level evidence\"\n\n# ============================================================================\n# STAGE C: SPATIAL HOTSPOT / SIGNIFICANT-PLACE EXTRACTION\n# ============================================================================\n\ntransform T_define_places :\n intent: define-unit\n manner: \"derive-places (spatio-temporal density clustering)\"\n input: D_illness_events\n output: D_places, F_place_membership\n actor: machine\n description: \"Cluster illness events jointly by spatial and temporal\n proximity into candidate significant places, treating isolated events\n as noise\"\n\nartifact D_places : entities\n internal structure: group/cluster\n embedment: space\n features:\n - id: place_extent\n value structure: atomic\n value type: spatial\n description: \"Spatial hull/buffer delineating the place\"\n - id: onset_time\n value structure: atomic\n value type: temporal\n description: \"Earliest event time within the place cluster\"\n description: \"Candidate significant places (spatio-temporal event\n clusters) derived from illness events\"\n\nartifact F_place_membership : feature(D_illness_events)\n value structure: atomic\n value type: reference\n description: \"Assignment of each illness event to a place cluster (or\n noise)\"\n\ntransform T_characterise_place_timeseries :\n intent: characterise\n manner: \"aggregate\"\n input: D_places, D_illness_events, F_place_membership\n output: F_place_timeseries\n actor: machine\n description: \"Compute per-place time series of event counts\"\n\nartifact F_place_timeseries : feature(D_places)\n value structure: vector\n value type: numeric\n representation form: \"time series per place\"\n description: \"Event-count time series per candidate place\"\n\ntransform T_characterise_place_incidence :\n intent: characterise\n manner: \"normalise by population\"\n input: D_places, D_zones, F_place_timeseries\n output: F_place_incidence\n actor: machine\n description: \"Normalise place-level event counts by zone population to\n obtain per-capita incidence\"\n\nartifact F_place_incidence : feature(D_places)\n value structure: vector\n value type: numeric\n description: \"Per-capita incidence time series per place\"\n\ntransform T_arrange_map_places :\n intent: contextualise\n manner: \"map-based\"\n input: D_places, D_map_features\n output: A_map_places\n actor: machine\n description: \"Overlay candidate places on the map context (highways,\n hospitals, landmarks, water bodies)\"\n\nartifact A_map_places : arrangement(D_places)\n context: D_map_features\n principle: \"geographic coordinates\"\n description: \"Spatial arrangement of candidate places relative to map\n features\"\n\ntransform T_vis_map_hotspots :\n intent: visualise\n manner: \"coloured-marks\"\n input: A_map_places, F_place_incidence, D_map_features\n output: V_map_hotspots\n actor: machine\n description: \"Map view of candidate places sized/coloured by onset time\n and per-capita incidence, overlaid on landmarks and water bodies\"\n\nartifact V_map_hotspots : visualisation(A_map_places, F_place_incidence,\n D_map_features)\n layout: \"geographic map\"\n form: \"coloured marks with size/time encoding\"\n encoding: \"position: from A_map_places; colour/size: from\n F_place_incidence and onset_time; background: D_map_features\"\n description: \"Visual identification of the earliest and most severe\n place cluster(s) and their co-location with fixed landmarks\"\n\ntransform T_abstract_origin_candidate :\n intent: abstract\n manner: \"perception-and-interpretation\"\n input: V_map_hotspots\n output: P_origin_candidate\n actor: human\n description: \"Identify candidate origin place(s) and note whether they\n coincide with a specific fixed feature (e.g., reservoir, festival\n ground) versus diffuse residential spread\"\n\nartifact P_origin_candidate : pattern(D_places)\n representation form: \"textual description\"\n description: \"Candidate origin place(s), their co-location with map\n features, and earliest onset time\"\n\n# ============================================================================\n# STAGE D: SPATIO-TEMPORAL GROUPING AND GROWTH MODELLING ACROSS ZONES\n# ============================================================================\n\ntransform T_characterise_zone_incidence :\n intent: characterise\n manner: \"aggregate and normalise by population\"\n input: D_zones, D_illness_events\n output: F_zone_incidence\n actor: machine\n description: \"Compute per-capita incidence time series for each of the\n 13 zones\"\n\nartifact F_zone_incidence : feature(D_zones)\n value structure: vector\n value type: numeric\n representation form: \"time series per zone\"\n description: \"Daily per-capita incidence time series per zone\"\n\ntransform T_cluster_zones :\n intent: define-unit\n manner: \"cluster-by-similarity of incidence profile\"\n input: D_zones, F_zone_incidence\n output: D_zone_groups, F_zone_group_label\n actor: machine\n description: \"Group the 13 zones by similarity of their temporal\n incidence profile\"\n\nartifact D_zone_groups : entities\n internal structure: group/cluster\n embedment: space\n description: \"Groups of zones with similar temporal incidence profiles\"\n\nartifact F_zone_group_label : feature(D_zones)\n value structure: atomic\n value type: categorical\n description: \"Temporal-similarity group label for each zone\"\n\ntransform T_arrange_map_zones :\n intent: contextualise\n manner: \"map-based\"\n input: D_zones, D_map_features\n output: A_map_zones\n actor: machine\n description: \"Position zones on the map context, including the highway\n network\"\n\nartifact A_map_zones : arrangement(D_zones)\n context: D_map_features\n principle: \"geographic coordinates\"\n description: \"Spatial arrangement of zones relative to highways and\n other map features\"\n\ntransform T_vis_zone_groups :\n intent: visualise\n manner: \"coloured-marks\"\n input: A_map_zones, F_zone_group_label, D_map_features\n output: V_zone_groups_map\n actor: machine\n description: \"Map view of zones coloured by temporal-similarity group,\n overlaid on the highway network, to check spatial contiguity versus\n dispersion\"\n\nartifact V_zone_groups_map : visualisation(A_map_zones, F_zone_group_label,\n D_map_features)\n layout: \"geographic map\"\n form: \"coloured region marks\"\n encoding: \"position: from A_map_zones; colour: from F_zone_group_label;\n background: highway layer from D_map_features\"\n description: \"Visual check of whether temporally similar zones are\n spatially contiguous/highway-aligned or spatially disconnected\"\n\ntransform T_build_growth_model :\n intent: build-model\n manner: \"fit-growth-curve\"\n input: F_zone_incidence, D_zone_groups\n output: M_growth\n actor: machine\n description: \"Fit an exponential/logistic growth curve to each zone\n group's representative incidence curve\"\n\nartifact M_growth : model(F_zone_incidence, D_zone_groups)\n model type: \"growth model\"\n representation form: \"exponential/logistic curve parameters per group\"\n description: \"Simple growth model of outbreak onset/expansion per zone\n group\"\n\ntransform T_characterise_residuals :\n intent: characterise\n manner: \"compute-statistics (residuals)\"\n input: F_zone_incidence, M_growth\n output: F_growth_residuals\n actor: machine\n description: \"Compute residuals of observed incidence relative to the\n fitted group growth curve, to flag zones deviating from the dominant\n pattern\"\n\nartifact F_growth_residuals : feature(D_zones)\n value structure: vector\n value type: numeric\n description: \"Residual time series per zone relative to fitted growth\n model\"\n\ntransform T_vis_residuals :\n intent: visualise\n manner: \"line-graph / coloured-marks on map\"\n input: F_growth_residuals, A_map_zones\n output: V_residuals_map\n actor: machine\n description: \"Map and/or timeline view highlighting zones with large\n residuals (candidates for a distinct secondary source or delayed\n exposure)\"\n\nartifact V_residuals_map : visualisation(F_growth_residuals, A_map_zones)\n layout: \"geographic map / aligned timelines\"\n form: \"coloured marks / line graph\"\n encoding: \"colour or line deviation: from F_growth_residuals; position:\n from A_map_zones\"\n description: \"Highlights zones whose incidence deviates from the\n dominant growth pattern\"\n\ntransform T_abstract_spread_pattern :\n intent: abstract\n manner: \"perception-and-interpretation\"\n input: V_zone_groups_map, V_residuals_map, D_map_features\n output: P_spread_pattern\n actor: human\n description: \"Interpret whether zone grouping follows the\n highway/mobility network (favouring person-to-person spread) or is\n spatially disconnected (favouring a shared, non-contact exposure);\n flag deviating zones as candidate secondary sources\"\n\nartifact P_spread_pattern : pattern(D_zone_groups, F_growth_residuals)\n representation form: \"textual description\"\n description: \"Description of the dominant spread geometry\n (contiguous/highway-aligned vs. disconnected) and any deviating zones\"\n\n# ============================================================================\n# STAGE E: WIND-SPREAD CROSS-IMPACT ANALYSIS (AIRBORNE HYPOTHESIS)\n# ============================================================================\n\ntransform T_characterise_downwind_alignment :\n intent: characterise\n manner: \"compute directional alignment relative to wind\"\n input: D_zones, D_weather, P_origin_candidate\n output: F_downwind_alignment\n actor: machine\n description: \"For each zone and day, compute how well the zone's bearing\n from the candidate origin matches that day's wind direction\"\n\nartifact F_downwind_alignment : feature(D_zones)\n value structure: vector\n value type: numeric\n description: \"Daily downwind alignment score per zone relative to the\n candidate origin place\"\n\nartifact S_lag_spec : specification\n origin: given\n representation form: \"parameter settings\"\n description: \"Initial window length, lag range, and tolerance interval\n for cross-impact analysis between wind and incidence/alignment\n series\"\n\nloop L_wind_analysis:\n purpose: \"Compute and calibrate the wind-incidence cross-impact pattern\n to test the airborne transmission hypothesis\"\n until: \"Impact matrix is stable/interpretable enough to support a\n judgment on the airborne hypothesis\"\n body:\n\n transform T_define_lag_windows :\n intent: define-unit\n manner: \"time-partitioning into sliding windows\"\n input: D_weather, F_zone_incidence, S_lag_spec\n output: D_windows\n actor: machine\n description: \"Partition the wind series and each zone's response\n series into sliding comparison windows over a range of plausible\n incubation lags\"\n\n artifact D_windows : entities\n internal structure: episode\n embedment: time\n features:\n - id: lag\n value structure: atomic\n value type: numeric\n description: \"Lag offset applied when comparing base and\n response series in this window\"\n description: \"Sliding time windows used to compare the wind (base)\n series with each zone's response series at varying lags\"\n\n transform T_characterise_cross_impact :\n intent: characterise\n manner: \"compute lagged association (tolerance-based)\"\n input: D_windows, D_weather, F_zone_incidence, F_downwind_alignment,\n S_lag_spec\n output: F_impact_matrix\n actor: machine\n description: \"Compute a tolerance-based association measure (e.g.,\n tolerance-Kendall's-tau) between the wind base series and each\n zone's response series across the window/lag grid\"\n\n artifact F_impact_matrix : feature(D_zones)\n value structure: matrix\n value type: numeric\n representation form: \"time x lag impact matrix (Ikat-style)\"\n description: \"Per-zone matrix of association strength across time\n windows and lags\"\n\n transform T_vis_impact :\n intent: visualise\n manner: \"matrix-plot\"\n input: F_impact_matrix\n output: V_wind_impact\n actor: machine\n description: \"Ikat-style visualisation of the time x lag impact\n matrix for each zone (or aggregated downwind vs. upwind\n comparison)\"\n\n artifact V_wind_impact : visualisation(F_impact_matrix)\n layout: \"time x lag grid, per zone\"\n form: \"matrix plot\"\n encoding: \"cell colour: from F_impact_matrix association strength\"\n description: \"Visual display for inspecting whether downwind zones\n show a consistent positive impact at a plausible lag\"\n\n transform T_assess_impact :\n intent: assess\n manner: \"evaluate stability and interpretability of impact pattern\"\n input: V_wind_impact, D_weather, F_zone_incidence\n output: K_impact_quality\n actor: human\n description: \"Judge whether the current window/lag/tolerance\n settings yield a stable, interpretable impact pattern,\n cross-checking suspicious cells against the underlying wind and\n incidence series\"\n\n artifact K_impact_quality : knowledge(F_impact_matrix)\n representation form: \"quality judgment\"\n description: \"Judgment of whether the impact matrix is\n stable/interpretable or requires recalibration of parameters\"\n\n if K_impact_quality indicates refinement needed:\n then:\n transform T_refine_lag_spec :\n intent: generate-knowledge\n manner: \"adjust parameter settings\"\n input: K_impact_quality, S_lag_spec\n output: S_lag_spec_r\n actor: human\n description: \"Adjust window length, lag range, or tolerance\n based on assessment\"\n\n artifact S_lag_spec_r : specification\n representation form: \"parameter settings\"\n description: \"Revised window/lag/tolerance settings\"\n\n assign:\n S_lag_spec := S_lag_spec_r\n else:\n exit loop L_wind_analysis\n\nend loop L_wind_analysis\n\ntransform T_knowledge_airborne :\n intent: generate-knowledge\n manner: \"formulate-statements\"\n input: V_wind_impact, F_impact_matrix\n output: K_airborne_evidence\n actor: human\n description: \"Formulate a statement on whether downwind zones show a\n consistent lagged impact from wind at the candidate origin, supporting\n or refuting airborne transmission\"\n\nartifact K_airborne_evidence : knowledge(F_impact_matrix)\n representation form: \"statements\"\n description: \"Evidence for or against airborne transmission based on\n stable directional wind-lag association\"\n\n# ============================================================================\n# STAGE F: PERSON-TO-PERSON AND WATERBORNE HYPOTHESIS CHECKS\n# ============================================================================\n\ntransform T_characterise_social_mentions :\n intent: characterise\n manner: \"extract (co-location/social mentions from text)\"\n input: D_illness_events\n output: F_social_mentions\n actor: hybrid\n description: \"Extract mentions of shared social context (coworkers,\n family, shared venues, shared transit lines) from illness-event text\"\n\nartifact F_social_mentions : feature(D_illness_events)\n value structure: list\n value type: {text, categorical}\n description: \"Extracted social/co-location references per illness\n event\"\n\ntransform T_define_social_network :\n intent: define-unit\n manner: \"derive relational structure from co-occurrence mentions\"\n input: D_illness_events, F_social_mentions\n output: D_social_network\n actor: hybrid\n description: \"Build a light co-occurrence network of people/places\n mentioned together across illness events\"\n\nartifact D_social_network : entities\n internal structure: formation\n features:\n - id: edge_weight\n value structure: atomic\n value type: numeric\n description: \"Strength of co-occurrence link\"\n description: \"Co-occurrence network of persons/places mentioned together\n in illness reports (single relational structure)\"\n\ntransform T_vis_social_network :\n intent: visualise\n manner: \"node-link-diagram\"\n input: D_social_network\n output: V_social_network\n actor: machine\n description: \"Node-link visualisation of the social/co-location\n co-occurrence network\"\n\nartifact V_social_network : visualisation(D_social_network)\n layout: \"force-directed network layout\"\n form: \"node-link diagram\"\n encoding: \"edges: from D_social_network edge_weight\"\n description: \"Visualisation for inspecting chains of social/mobility\n contact among cases\"\n\ntransform T_abstract_p2p_pattern :\n intent: abstract\n manner: \"perception-and-interpretation\"\n input: V_social_network, V_zone_groups_map\n output: P_p2p_pattern\n actor: human\n description: \"Assess whether cases chain along social/mobility links and\n whether spatial growth tracks the highway/transit network rather than\n a single fixed landmark\"\n\nartifact P_p2p_pattern : pattern(D_social_network, D_zone_groups)\n representation form: \"textual description\"\n description: \"Description of evidence for/against person-to-person\n transmission via social and mobility chains\"\n\ntransform T_vis_water_overlay :\n intent: visualise\n manner: \"map-based overlay\"\n input: A_map_places, D_map_features\n output: V_water_overlay\n actor: machine\n description: \"Overlay origin and hotspot clusters directly on the\n water-body layer and any known water-service-area boundaries\"\n\nartifact V_water_overlay : visualisation(A_map_places, D_map_features)\n layout: \"geographic map\"\n form: \"coloured marks over water/service-area layer\"\n encoding: \"hotspot marks: from A_map_places; background: water\n bodies/service areas from D_map_features\"\n description: \"Visual check of whether hotspot clusters are coincident\n with water sources or service-area boundaries\"\n\ntransform T_abstract_waterborne_pattern :\n intent: abstract\n manner: \"perception-and-interpretation\"\n input: V_water_overlay, P_origin_candidate\n output: P_waterborne_pattern\n actor: human\n description: \"Assess whether the origin/hotspot clusters coincide with a\n water source and whether case distribution matches water-service areas\n rather than road proximity or social chains\"\n\nartifact P_waterborne_pattern : pattern(D_places)\n representation form: \"textual description\"\n description: \"Description of evidence for/against waterborne\n transmission\"\n\ntransform T_knowledge_mechanism_checklist :\n intent: generate-knowledge\n manner: \"formulate-statements (comparison checklist)\"\n input: K_airborne_evidence, P_p2p_pattern, P_waterborne_pattern,\n P_spread_pattern\n output: K_mechanism_assessment\n actor: human\n description: \"Compile a diagnostic checklist comparing the expected\n spatial/temporal/contextual signature of each transmission mechanism\n (airborne, person-to-person, waterborne) against the observed\n evidence\"\n\nartifact K_mechanism_assessment : knowledge(K_airborne_evidence,\n P_p2p_pattern, P_waterborne_pattern, P_spread_pattern)\n representation form: \"comparison checklist / statements\"\n description: \"Structured comparison of candidate transmission\n mechanisms against observed diagnostic signatures\"\n\n# ============================================================================\n# STAGE G: SYNTHESIS AND REPORTING\n# ============================================================================\n\ntransform T_synthesise_report :\n intent: generate-knowledge\n manner: \"write-summary\"\n input: K_onset_candidates, P_origin_candidate, K_mechanism_assessment\n output: K_final_report\n actor: human\n description: \"Synthesise the probable origin place and time window, the\n dominant spread pattern, and the best-supported transmission mechanism\n into an evidence-linked report for emergency management\"\n\nartifact K_final_report : knowledge(D_places, D_zone_groups,\n F_impact_matrix)\n representation form: \"statements / report\"\n description: \"Evidence-linked report on outbreak origin, spread pattern,\n and most probable transmission mechanism, to guide deployment of\n emergency management resources\"\n```\n\n## Notes on structural elements made explicit (vs. added)\n\n**Faithful translations (structure already implied in the natural-language design):**\n- The two iterative \"sample → correct → re-extract\" and \"calibrate → inspect → adjust\" processes (Stage A text validation; Stage E wind-lag calibration) were explicitly described as iterative in prose, so representing them as `loop` constructs with `assess` transforms and `if/exit` branches is a direct translation, not an addition.\n- The `hybrid` actor designation for text/relation extraction (Stage A illness-event filtering, Stage F social-mention extraction, Stage F social-network construction) reflects the explicitly stated human-correction-of-machine-extraction pattern from the original description (modeled on Jigsaw).\n- The `human` actor for all `abstract` and `generate-knowledge` steps, and `machine` for clustering/aggregation/model-fitting steps, follows directly from the natural-language emphasis on \"the analyst inspects... and interprets\" versus automated computation.\n\n**Elements I made explicit that were only loosely implied, and should be flagged as added structure:**\n1. **The general \"propose → visualize → validate → refine\" loop** mentioned once in Stage G as a cross-cutting principle was **not** modeled as a single overarching loop wrapping the whole workflow. I only formalized the two places where iteration was concretely described (Stages A and E). Stages B, C, D, and F are represented as **linear sequences** of transforms, even though in practice an analyst might revisit them — I did not fabricate additional loops there because the original text did not describe explicit refinement cycles for those stages.\n2. **Splitting Stage E's `S_lag_spec` refinement and recomputation into a single loop** (windows → cross-impact → visualise → assess → refine-spec) is a specific ATWL-loop realization of a process the natural-language description stated more loosely (\"calibrate...interactively\"). The precise loop body (recomputing `D_windows` and `F_impact_matrix` each iteration) is my interpretation of what \"calibration\" must mechanically involve, following the pattern of the example's `L_feature_refinement` loop; the original prose did not spell out this exact recomputation structure.\n3. **The `F_place_membership` and `F_downwind_alignment` intermediate feature artifacts**, and the explicit separation of `characterise` transforms for place-timeseries vs. per-capita-incidence, are finer-grained decompositions than the natural-language prose, which described these as a single conceptual step (\"compute a time series... normalize by population\"). I split them to fit ATWL's one-intent-per-transform convention.\n4. **The Stage F comparison-checklist artifact (`K_mechanism_assessment`)** was described in prose as a \"structure this stage as a comparison table/checklist\" — I formalized this as a distinct `generate-knowledge` transform/artifact, which is a reasonably direct translation but does add a discrete artifact boundary not explicitly named in the original text.\n5. I did **not** add any `build-model` steps beyond the growth-curve fit in Stage D (e.g., no additional classifier or simulation model), since the original design did not call for one elsewhere.\n\nNo actor distinctions, loops, or specification-refinement structures were invented wholesale where the original description gave a purely linear account — where I judged the prose to be linear (Stages B, C, D, F), I kept the ATWL representation linear as well.",
"role": "assistant"
}
]
}