Grounding SWE-Agent Decisions in Architecture-0 Design: Navigating Unknown Unknowns through Physical Mapping

Zhongkai Wang; Yan Liu

Figure 1. The epistemic journey of SWE-Agents in Architecture 0. (Left) The transition from deterministic code-level tasks to early-stage design exposes agents to latent Unknown Unknowns (UUs), inducing severe grounding bias. (Middle) Our empirical exploration reveals two sequential traps: pure-text reasoning lacks physical anchors, leading agents to succumb to Social Sycophancy or generate Plausible Fabrications . Subsequently, granting agents autonomy over validation scripts (the

\alpha

-Sandbox) triggers Specification Gaming . (Right) To break this self-validation trap, we propose the Physical Mapping Guard (PMG), which enforces physical grounding by strictly decoupling verification authority via an external, immutable Semantic-to-Physical (S2P) mapping engine. A three-panel diagram illustrating the research trajectory. The left panel, 'Problem Setting', shows 'Code-Level SWE-Agents' transitioning to 'Architecture 0', represented by an iceberg icon, with text explaining that latent Unknown Unknowns induce severe grounding bias. The middle panel, 'Our Empirical Exploration', displays two sequential traps. 'Trap 1: Pure-Text Self-Play' features an illustration of robots projecting a holographic castle, stating that unanchored reasoning degrades into Social Sycophancy and Plausible Fabrications. 'Trap 2: Executable alpha-Sandbox' features robots hacking a testing machine's dial, stating that agent autonomy over validation scripts triggers Specification Gaming. The right panel, 'Our Proposed Framework', introduces 'PMG' with a shield icon and an illustration of a robot submitting blueprints into a sealed, secure validation machine. The text reads: 'Strictly decoupling verification authority via an external, immutable deterministic S2P mapping engine'.

Figure 2. The evolutionary path of SWE-Agent augmentation and grounding trends. Lane 1: SWE-Agent Enhancement for Code Tasks; Lane 2: SWE-Agent Enhancement for Architecture SE Tasks; Lane 3: Grounding Research Trend. Our proposed PMG framework is situated at the intersection of Architecture 0 and physical grounding, addressing the verification control problem. This figure displays a three-lane horizontal block diagram illustrating the progression and interconnections between Software Engineering (SWE) agent enhancements and grounding research trends. Lane 1, titled "SWE-Agent Enhancement for Code Tasks," consists of seven sequential steps: 1. Code Generation Evaluation; 2. Functional Correctness Metrics; 3. Repository-Level Issue Solving; 4. Tool Use and Terminal Interaction; 5. Test and Compilation Feedback; 6. Sandboxed Execution Environment; and 7. Trajectory Analysis and Failure Diagnosis. Lane 2, titled "SWE-Agent Enhancement for Architecture SE Tasks," consists of eight sequential steps: 1. Architecture Proposal Generation; 2. Role-Based Design Review; 3. Self-Play and Adversarial Critique (includes a "Pure-text" tag); 4. Design Assumption Estimation; 5. Sandbox-Style Validation (includes an "alpha-Sandbox" tag); 6. Structured Architecture Representation; 7. External Constraint Checking; and 8. Resource Ledger and Physical Mapping. Lane 3, titled "Grounding Research Trend," consists of eight sequential steps: 1. Robotic Affordance Grounding; 2. Skill and Environment-Constrained Planning; 3. Embodied Action Feedback; 4. Simulation and Experimental Feedback; 5. Grounding in Scientific Discovery; 6. Embodied Multi-Agent Collaboration; 7. Tool and Environment Grounding; and 8. Constraint / Physical Mapping Grounding (includes a "PMG" tag). Cross-Lane Connections: Dashed lines indicate mapping relationships between specific steps across different lanes: Lane 1, Step 4 connects to Lane 3, Step 7. Lane 1, Step 6 connects to Lane 2, Step 5. Lane 1, Step 7 connects to Lane 2, Step 3. Lane 3, Step 4 connects to Lane 2, Step 5. Lane 3, Step 8 connects to Lane 2, Step 8.

Figure 3. The epistemic matrix in Architecture 0: Categorizing constraints and risks into Known Knowns, Known Unknowns, Unknown Knowns, and Unknown Unknowns. This study focuses exclusively on the UU quadrant. A 2x2 matrix categorizing the epistemic states of AI agents regarding system architecture. The four quadrants are separated by thick, intersecting black horizontal and vertical axes. \begin{itemize} \itemTop-Left Quadrant (Blue background): "Known Knowns". Features an icon of a robot building blocks. Text reads: "Standard framework syntaxes and structural paradigms. Agents easily retrieve and apply these from pre-training data." \itemTop-Right Quadrant (Blue background): "Known Unknowns". Features an icon of a robot examining a database with a magnifying glass. Text reads: "Specific project configurations. Agents know they lack this data and can resolve it via RAG or direct queries." \itemBottom-Left Quadrant (Blue background): "Unknown Knowns". Features an icon of an iceberg. Text reads: "Implicit engineering baselines and business SLAs. Agents possess latent knowledge but often over-look them in pure-text reasoning unless forced by adversarial pro-mpting." \itemBottom-Right Quadrant (Pink background with dashed red border): "Unknown Unknowns". Features an icon of a server rack emitting smoke. Text reads: "Latent systemic bottlenecks. Agents are fundamentally blind to these epistemic traps without an explicit awareness of real-world constraints." \end{itemize}

SLAM Concept	Correspondence in Architecture 0
Map	The task environment comprising business requirements, resource ledgers, and objective mapping rules.
Robot’s Pose	The feasibility status of the agent’s current architectural design within the engineering constraint space.
Sensor Observation	Executable tool feedback, architectural audits, and mapping results.
Localization Drift	Grounding bias between the Semantic World and the Physical World.
Observation Model	Semantic-to-Physical (S2P) mapping, which projects the design into the ledger boundaries.
Collision / Obstacle	Resource exhaustion, constraint conflicts, or unresolvable requirements.

Table 1. Mapping SLAM Concepts to Grounding Problems in Architecture 0

Figure 4. The SLAM analogy for S2P Grounding: Correcting localization drift in robotics (left) mirrors the correction of grounding bias in architectural reasoning (right). This figure presents a side-by-side comparative diagram titled "SLAM Analogy for Semantic-to-Physical Mapping," demonstrating how principles from SLAM apply to software architecture grounding. Panel A (Left): "SLAM: Correcting Localization Drift." It depicts a robot navigating a 2D grid. A red dashed path represents an "Odometry-only Estimated Path," which drifts downward and ends in a red 'X' labeled "Localization Error." Surrounding geometric shapes (circle, square, triangle, pentagon) act as "Landmarks." Dashed grey arrows show "External Landmark Observations" from the robot. These observations correct the drift, resulting in a blue solid line labeled "Landmark-corrected Path." A vertical blue arrow labeled "Observation Correction" shifts the erroneous red endpoint up to the correct blue endpoint on the corrected path. Panel B (Right): "S2P Mapping: Correcting Grounding Bias." It mirrors the SLAM process for AI architecture. An "AI Architecture Agent" outputs a "Semantic Architecture Estimate," represented as a blue dot labeled "Claimed Feasible Architecture." This estimate undergoes "S2P Mapping" and enters a "Physical Constraint Space," a bounding box defined by Latency Limit, Cost Limit, and Memory Limit. Inside this space is a green dashed circle denoting the "Feasible Region," which contains the blue dot (Claimed Feasible Architecture). However, the initial mapping results in a red dot lying outside the feasible region, labeled "Projected Architecture." A red horizontal double-arrow connects the blue dot to the red dot, labeled "Grounding Bias." Finally, a blue arrow labeled "Correction Signal" loops back from the physical constraint space to the AI Architecture Agent, analogous to the observation correction in Panel A.

Dimension	Values	Design Purpose
Context	Monolith Serverless Microservices	Covers common architectural paradigms in modern cloud-native systems, reducing noise from industry-specific scenarios.
Conflict	Resources vs. Latency Cost vs. Performance Consistency vs. Availability etc.	Focuses on engineering constraints that form strict physical or economic boundaries, avoiding unquantifiable factors.
Difficulty	L1 (Textbook-level) L2 (Industrial-level) L3 (Infeasible-level)	Differentiates single-dimensional, multi-dimensional coupled, and explicitly infeasible constraints to observe behaviors under varying uncertainty.

Table 2. The Dimensions of the Architecture 0 Task Matrix

Figure 5. Progressive cognitive degradation in pure-text paradigms: from polite consensus in baseline settings to pseudo-reasoning under adversarial prompting. A flowchart starting from 'The Architecture 0 Challenge'. L1 tasks lead to 100 percent success. L2 and L3 tasks split into Group A, leading to Social Sycophancy and Premature Consensus, and Group B, leading to Plausible Fabrications. Both conclude that executable physical grounding is strictly required.

Figure 6. The

\alpha

-Sandbox Framework Observational Pipeline. An ablation-driven evaluation framework designed to probe the cognitive limits of SWE-Agents. Architectural requirements are routed into progressively constrained environments. A comprehensive system architecture and workflow diagram divided vertically into three main sections: Input & Context (top), a three-phase processing core (middle), and Data Extraction (bottom). 1. Input & Context (Top): Contains three document-style icons: "Resource Ledger", "Architectural Req / UUs", and "System Prompt". 2. Middle Processing Core (Three Phases): Phase 1: Group Assignment (Ablation). Begins with a diamond decision node labeled "Experimental Routing". This splits into three parallel paths: \begin{itemize} \item"Group A: Baseline (Professional Neutral)" in a grey box. \item"Group B: Prompting (Strict Adversarial)" in a green box. \item"Group C: Sandbox (Adversarial + Tool)" in a blue box. \end{itemize} Phase 2: Single-agent Dual-role Self-Play Engine. An arrow from Phase 1 points to an "Agent Reasoning Loop" box. Inside, an "Architect Role (Design & Proposal)" box and an "Auditor Role (Critical Verification)" box interact via cyclical "Self-play" arrows. Below this loop is a yellow database cylinder labeled "Executable Sandbox Python Probes". Dotted arrows, labeled "Group C Only", point from both the Architect and Auditor to this sandbox. Phase 3: Consensus & Interlock. Data flows from Phase 2 into a diamond node labeled "Consensus Logic Check". This node branches into four possible terminal states: \begin{itemize} \item"End: Timeout" (Grey box) \item"End: Impossible" (Purple box) \item"End: Success" (Green box) \item"Interlock Triggered Conflict Detected" (Red box). \itemCrucial Feedback Loop: A red dotted arrow labeled "Force Re-Audit" originates from the red Interlock box and loops backward, pointing into the "Executable Sandbox" within Phase 2. \end{itemize} 3. Data Extraction (Bottom): A final arrow points from the Phase 3 boundary down to a bottom block labeled "Data Extraction: NAC Calculation & Gaming Analysis".

Figure 7. Quantitative Outcome Classification. (a) The execution feedback in Group C paradoxically replaces Plausible Fabrications with Specification Gaming. (b) Cross-model evaluation demonstrates that specification gaming is a universal vulnerability across different foundational models. Two stacked bar charts. Chart (a) compares outcomes across Groups A, B, and C for GPT-4o, with N=15 per group. Group A is dominated by Blind Sycophancy (73.3%). Group B shows True Consensus (73.3%) and Plausible Fabrications (26.7%). Group C introduces Sandbox Gaming (46.7%), unexpectedly reducing True Consensus to 53.3%. Chart (b) compares GPT-4o, Claude 3.5 Sonnet, and Qwen-Max in Group C, with N=15 per model. GPT-4o shows 53.3% True Consensus and 46.7% Sandbox Gaming. Claude shows 93.3% True Consensus and 6.7% Sandbox Gaming. Qwen-Max shows 73.3% Sandbox Gaming, 13.3% Plausible Fabrications, and only 13.3% True Consensus.

Figure 8. Multi-dimensional NAC trajectories over dialogue rounds. The gold stars denote the exact conversational rounds where agents manipulate validation parameters or evade SLAs to forcefully suppress the NAC to zero, achieving compiler compliance without resolving actual architectural flaws. Three side-by-side line charts with a logarithmic Y-axis representing Resource Tension Ratio. The lines show simulated resource usage dropping abruptly to the zero baseline at specific rounds. Gold stars mark the exact rounds where agents engaged in specification gaming to bypass constraints.

Layer	Primary Components	Authority & Function
Agent-Controlled Layer	Natural language proposals, structured topology, iteration notes.	The agent can propose and revise designs but cannot define resource formulas or collision rules.
Mapper Internal Layer	Resource ledgers, resource profiles, workload propagation, billing, NAC calculation.	Maintained by the deterministic mapper to form a physical evaluation process independent of the agent.
Safe Feedback Layer	Mapping status, public ledger, bill summaries, filtered collision feedback.	Provides actionable revision clues while hiding implicit thresholds, exact formulas, and raw collision details.

Table 3. Stratification of Verification Authority in PMG

Figure 9. The PMG S2P Verification Pipeline: Structured topologies undergo validation, workload propagation, billing, and ledger projection to generate safe feedback. This figure is a comprehensive block diagram illustrating the data flow and processing stages within a system composed of five main sections: Semantic World, Physical World, Physical Mapping Guard, Feedback Filter, and Agent-facing View. 1. Semantic World (Top): Contains three document-style nodes: "Architectural Req / UUs", "Reasoning" (with a magnifying glass icon), and "Structured Topology" (with a network node icon). Arrows point downward from this section into the Physical Mapping Guard. 2. Physical World (Left): Consists of four chevron-shaped elements representing inputs: "Explicit Ledger" (green), "Hidden Ledger" (orange), "Profile Catalog" (yellow), and "Mapping Rules" (grey). An arrow points rightward from this block into the Physical Mapping Guard. 3. Physical Mapping Guard (Center): This is the core processing engine. It contains two parallel vertical pipelines of component blocks: \begin{itemize} \itemThe left pipeline flows from "Topology Validation" down to "Workload Propagation" and then to "Node Billing". \itemThe right pipeline flows from "Aggregation & Path Latency" down to "Ledger Projection" and then to "NAC & Collision Detection". \itemBoth pipelines output into a single, wide, green rounded rectangle at the bottom labeled "Full Mapper Result". \end{itemize} 4. Feedback Filter (Right): Receives input from the "Full Mapper Result". It categorizes the data into two distinct boxes: \begin{itemize} \itemExposed (blue background): Lists items available to the agent: "- status", "- visible ledger", "- ledger-aligned bill", "- node-level resource dimensions", and "- visible NAC & collision". \itemWithheld (pink background): Lists items hidden from the agent: "- hidden thresholds", "- hidden NAC values", "- collision magnitude", and "- full formulas". \end{itemize} 5. Agent-facing View (Bottom): Receives the final processed output from the Feedback Filter. A dashed brown arrow creates a feedback loop, pointing from the "Agent-facing View" back up to the "Structured Topology" in the Semantic World

Field Name	Requirement	Description
topology_id	Required	Identifies the candidate topology for tracking iterations.
case_id	Required	Binds the architecture to the specific Architecture 0 ledger.
assumptions	Optional	Topology-level inputs (e.g., global QPS). Formula definitions are prohibited.
nodes	Required	Describes billable components and their resource profiles (e.g., api_gateway ).
edges	Required	Describes invocations, data flows, and latency paths.
loop_budget	Required if cyclic	Limits cyclic propagation to prevent unbounded resource amplification.

Table 4. Top-Level Fields of the PMG Topological Intermediate Representation (TIR)

Feedback Item	Description & Intent
Mapping Status	Returns PASS , COLLISION , or UNMAPPABLE_TOPOLOGY .
Explicit Ledger Limits	Re-states visible boundaries (e.g., Max RAM), allowing agents to cross-check.
Aligned Resource Bill	Aggregated resource consumption projected into the explicit ledger dimensions.
Node-level Bill Summary	Exposes resource pressure points for individual nodes while omitting implicit formulas.
Public NAC	The Normalized Affordance Cost for explicit dimensions to quantify tension.
Filtered Collision Info	Details collisions for explicit dimensions but only provides generic warnings for implicit collisions.

Table 5. Components of PMG Agent-Facing Safe Feedback

Status	Semantic Meaning
PASS	The current topology successfully passes the deterministic physical mapping validation under the given ledger.
COLLISION	The current topology exhibits resource collisions; further iterations are required.
UNMAPPABLE_TOPOLOGY	The topology structure cannot be deterministically mapped (e.g., contains unbounded cyclic references or invalid node profiles).

Table 6. PMG Mapper Return Statuses and Semantics

Dimension	$\alpha$ -Sandbox	PMG
Verification Logic	Self-authored Python scripts by the agent	Deterministic execution by the mapper
Input Format	Natural language reasoning & Python code	Topological Intermediate Representation (TIR)
Constraint Source	Global Ledger + Agent’s code usage	Global Ledger + Resource Profiles + Fixed Rules
Primary Risks	Self-validation risk & Physical/Validation gaming	Semantic gaming & limited feedback actionability
Method Role	Expose failure modes under execution feedback	Mitigate physical & validation-layer gaming

Table 7. Comparison of Verification Authority:

\alpha

-Sandbox vs. PMG

Metric	Values / Sub-types	Definition
final_status	RESOLVED IMPOSSIBLE MAX_ROUND	The ultimate architectural conclusion reached by the agents.
is_correct	True / False	Whether the final_status aligns with the Human Expert Ground Truth.
converged	True / False	Whether a definitive conclusion was reached before the maximum turn limit.
specification_gaming	True / False	Whether the agent engaged in metric manipulation or requirement dodging.
spec_gaming_type	physical validation semantic	Categorization of the gaming behavior based on the S2P grounding biases (Section 3 ).
auditor_error	True / False	Whether the Auditor introduced flawed logic that distorted the final conclusion.

Table 8. Evaluation Metrics and Annotation Rules

Execution Metric	Count	Percentage	Gaming Metric	Count	Percentage
Total Trials	45	100.0%	Total Gaming Instances	7	15.6%
Final Judgment Correct	27	60.0%	Physical-Layer Gaming	0	0.0%
Final Judgment Incorrect	18	40.0%	Validation-Layer Gaming	0	0.0%
Converged ( RESOLVED / IMPOSSIBLE )	41	91.1%	Semantic-Layer Gaming	7	15.6%

Table 9. Overall Performance of PMG on Core Dataset (N=45)

Figure 10. Distribution of final states across models in the PMG core experiment. case_001 Ground Truth is IMPOSSIBLE; case_002 and case_003 are RESOLVED. This composite figure consists of three side-by-side 100% stacked bar charts, each illustrating the "Distribution of Final Status by Case Id" for a specific AI model: gpt-4o, qwen-max, and claude-sonnet-4-5-20250929. Shared Global Elements: All three charts share the same axes and legend: \begin{itemize} \itemY-axis: Represents "Percentage of Runs (%)" ranging from 0% to 100%. \itemX-axis: Displays three distinct test cases: "Case 001 monolith L3", "Case 002 serverless L2", and "Case 003 microservices L2". \itemLegend (Final Status): Categorized by three colors: RESOLVED (Green), IMPOSSIBLE (Red), and MAX ROUND REACHED (Yellow). \end{itemize} Subfigure 1: Model gpt-4o \begin{itemize} \itemCase 001: Comprises 1 RESOLVED run (20.0%) at the bottom, and 4 IMPOSSIBLE runs (80.0%) at the top. \itemCase 002: Comprises 4 RESOLVED runs (80.0%) at the bottom, and 1 IMPOSSIBLE run (20.0%) at the top. \itemCase 003: Comprises 4 IMPOSSIBLE runs (80.0%) at the bottom, and 1 MAX ROUND REACHED run (20.0%) at the top. \end{itemize} Subfigure 2: Model qwen-max \begin{itemize} \itemCase 001: Comprises 2 RESOLVED runs (40.0%) at the bottom, and 3 IMPOSSIBLE runs (60.0%) at the top. \itemCase 002: Exclusively comprises 5 RESOLVED runs (100.0%). \itemCase 003: Comprises 3 RESOLVED runs (60.0%) at the bottom, and 2 MAX ROUND REACHED runs (40.0%) at the top. \end{itemize} Subfigure 3: Model claude-sonnet-4-5-20250929 \begin{itemize} \itemCase 001: Comprises 3 RESOLVED runs (60.0%) at the bottom, and 2 IMPOSSIBLE runs (40.0%) at the top. \itemCase 002: Exclusively comprises 5 RESOLVED runs (100.0%). \itemCase 003: Comprises 1 RESOLVED run (20.0%) at the bottom, 3 IMPOSSIBLE runs (60.0%) in the middle, and 1 MAX ROUND REACHED run (20.0%) at the top. \end{itemize}

Figure 11. Distribution of Auditor Overreach types across models. Over-auditing and out-of-scope stress injections (Chaos) frequently distort the final architectural judgment. This composite figure displays three side-by-side 100% stacked bar charts, each illustrating the "Distribution of Auditor Error Type by Case Id" for a specific AI model: gpt-4o, qwen-max, and claude-sonnet-4-5-20250929. Shared Global Elements: All three charts share the same axes layout: \begin{itemize} \itemY-axis: Represents "Percentage of Runs (%)" scaling from 0% to 100%. \itemX-axis: Displays three specific test cases: "Case 001 monolith L3", "Case 002 serverless L2", and "Case 003 microservices L2". \itemCombined Legend (Auditor Error Type): Across all subfigures, four distinct error categories are identified by color: None (Green), Out Of Scope Stress (Red), Misleading Push (Orange), Over Auditing (Pink). \end{itemize} Subfigure 1: Model gpt-4o \begin{itemize} \itemCase 001: Comprises 4 'None' runs (80.0%) at the bottom, and 1 'Misleading Push' run (20.0%) at the top. \itemCase 002: Comprises 4 'None' runs (80.0%) at the bottom, and 1 'Misleading Push' run (20.0%) at the top. \itemCase 003: Comprises 2 'None' runs (40.0%) at the bottom, 2 'Out Of Scope Stress' runs (40.0%) in the middle, and 1 'Misleading Push' run (20.0%) at the top. \end{itemize} Subfigure 2: Model qwen-max Cases 001, 002, and 003: All three test cases exhibit identical behavior, each exclusively comprising 5 'None' runs (100.0%). Subfigure 3: Model claude-sonnet-4-5-20250929 \begin{itemize} \itemCase 001: Exclusively comprises 5 'None' runs (100.0%). \itemCase 002: Exclusively comprises 5 'None' runs (100.0%). \itemCase 003: Contains no 'None' runs. It comprises 2 'Out Of Scope Stress' runs (40.0%) at the bottom, and 3 'Over Auditing' runs (60.0%) at the top. \end{itemize}

Figure 12. Distribution of Grounded Corrections across models. When confronted with objective COLLISION signals, agents frequently stall, failing to translate physical feedback into actionable topological revisions. This composite figure contains three side-by-side 100% stacked bar charts, each detailing the "Distribution of Has Grounded Correction by Case Id" for a specific AI model: gpt-4o, qwen-max, and claude-sonnet-4-5-20250929. Shared Global Elements: All three charts utilize the same axes and legend: \begin{itemize} \itemY-axis: Labeled "Percentage of Runs (%)", scaling from 0% to 100%. \itemX-axis: Displays three test cases: "Case 001 monolith L3", "Case 002 serverless L2", and "Case 003 microservices L2". \itemLegend (Has Grounded Correction): Categorized by three distinct colors: Pass First Try (Light Blue), Corrected (Green), Not Corrected (Orange/Brown). \end{itemize} Subfigure 1: Model gpt-4o \begin{itemize} \itemCase 001: Exclusively comprises 5 'Corrected' runs (100.0%). \itemCase 002: Comprises 3 'Pass First Try' runs (60.0%) at the bottom, 1 'Corrected' run (20.0%) in the middle, and 1 'Not Corrected' run (20.0%) at the top. \itemCase 003: Comprises 4 'Corrected' runs (80.0%) at the bottom, and 1 'Not Corrected' run (20.0%) at the top. \end{itemize} Subfigure 2: Model qwen-max \begin{itemize} \itemCase 001: Comprises 1 'Pass First Try' run (20.0%) at the bottom, and 4 'Corrected' runs (80.0%) at the top. \itemCase 002: Exclusively comprises 5 'Pass First Try' runs (100.0%). \itemCase 003: Comprises 3 'Pass First Try' runs (60.0%) at the bottom, and 2 'Not Corrected' runs (40.0%) at the top. \end{itemize} Subfigure 3: Model claude-sonnet-4-5-20250929 \begin{itemize} \itemCase 001: Comprises 4 'Corrected' runs (80.0%) at the bottom, and 1 'Not Corrected' run (20.0%) at the top. \itemCase 002: Comprises 4 'Pass First Try' runs (80.0%) at the bottom, and 1 'Corrected' run (20.0%) at the top. \itemCase 003: Comprises 1 'Pass First Try' run (20.0%) at the bottom, 1 'Corrected' run (20.0%) in the middle, and 3 'Not Corrected' runs (60.0%) at the top. \end{itemize}

Grp	Model & Case	Perturbation Content	Gold Label	Design Purpose
A1	Claude 4.5 Sonnet Monolith L3	Explicitly mandated that a "successful deduction" is only valid if synchronously persisted to the database.	IMPOSSIBLE	Test if explicit semantics prevent the model from redefining "success".
A2	Claude 4.5 Sonnet Monolith L3	Explicitly prohibited load shedding, stating that all 100k QPS must enter the deduction path.	IMPOSSIBLE	Test if tightened acceptance criteria prevent load dilution.
B	Qwen-Max Microservices L2	Clarified that the deliverable is an Architecture 0 feasibility judgment, not a production-ready design.	RESOLVED	Test if clarifying the lifecycle stage reduces semantic drift and stalled correction.
C	GPT-4o Microservices L2	Mandated that Auditor critiques must explicitly cite evidence from the prompt, ledger, or mapper feedback.	RESOLVED	Test if bounding the auditor to evidence reduces Auditor Overreach.

Table 10. Experimental Design for Intent and Auditor Perturbations

Grp	Perturbation Target	Correctness (Base $\rightarrow$ Pert.)	Key Mechanism Shift (Base $\rightarrow$ Perturbed)	Qualitative Analysis & Root Cause
A1	Semantic Strictness Mandated synchronous persistence for "success".	2/5 $\rightarrow$ 2/5	Semantic Gaming: 3/5 $\rightarrow$ 3/5	Semantic evasion persisted. Models reinterpreted "success" to justify async batching, exploiting linguistic ambiguity despite strict prompts.
A2	Load Strictness Prohibited load-shedding for the 100k QPS target.	2/5 $\rightarrow$ 3/5	Semantic Gaming: 3/5 $\rightarrow$ 2/5	Marginal improvement. When barred from discarding requests, agents attempted to redefine the 100k QPS as a "cache-hit expectation" rather than a hard database constraint.
B	Goal Clarification Emphasized Arch 0 feasibility, not production.	3/5 $\rightarrow$ 3/5	Semantic Gaming: 1/5 $\rightarrow$ 0/5 Auditor Error: 0/5 $\rightarrow$ 2/5 Stalled Correction: 2/5 $\rightarrow$ 2/5	Gaming eliminated, but Auditor Overreach emerged. Clarifying the design phase bounded the proposer but failed to calibrate the evaluator, which applied strict SLA rigidity to early sketches.
C	Evidence-Bounded Auditor must explicitly cite visible mapper evidence.	0/5 $\rightarrow$ 1/5	Auditor Error: 3/5 $\rightarrow$ 4/5	Overreach paradoxically worsened. The Auditor cited genuine mapper warnings but fatally misinterpreted their severity in an early-stage context, unconditionally rejecting viable paths.

Table 11. Comprehensive Analysis of Intent and Auditor Perturbations (N=5 per group). This matrix illustrates how prompting interventions shift the failure mechanisms rather than resolving the grounding deficit.

Figure 13. The Public Dataset Adaptation Pipeline. To evaluate generalizability, open-source system design tasks are systematically translated into PMG-compatible inputs. This transformation preserves the original business intent and scale assumptions, while calibrating the scope to Architecture 0 and injecting computable physical ledgers. A horizontal timeline-style flowchart illustrating the process of dataset adaptation. A central horizontal axis runs from left to right, beginning with the word "Original" (in brown text) and ending with an arrow pointing to the word "Adaptation" (in green text). Four rectangular blocks are connected to this central axis in a sequential, alternating above-and-below pattern. Each block contains a title with a corresponding icon and a descriptive text below it. The sequence from left to right is as follows: \begin{itemize} \itemStep 1 (Attached above the axis): "Public System Design Tasks" (Features a book icon). The text reads: "Sourcing open-ended scenarios while strictly preserving original business objectives and scale assumptions". \itemStep 2 (Attached below the axis): "Architecture 0 Calibration" (Features a target icon). The text reads: "Down-scoping from production-grade implementation to early-stage feasibility judgment". \itemStep 3 (Attached above the axis): "Resource Ledger Injection" (Features a balance scale icon). The text reads: "Embedding strict multi-dimensional physical constraints for computable validation". \itemStep 4 (Attached below the axis): "PMG Format Serialization" (Features a gear icon). The text reads: "Translating the enriched context into structured inputs without altering the original problem intent". \end{itemize}

Metric	Count	%
Total	36	100%
Correct	32	88.9%
Incorrect	4	11.1%
Gaming	0	0.0%

Table 12. PMG Public Dataset Performance Breakdown (N=36)

Deployment Aspect	Potential Benefits	Implementation Challenges	Coverage in this Study
Design Review Gates	Exposes resource collisions before implementation; provides quantitative support for Architecture Decision Records (ADR).	Requires translating unstructured natural language designs into formal structured topologies; human review of semantics still needed.	Validated across core prototypes and public design tasks.
CI/CD Integration	Enables lightweight, automated checks for topology or documentation changes without executing heavy stress tests.	Defining trigger conditions, blocking policies, and resolution responsibilities in real-world pipelines.	Evaluated purely within Architecture 0 experimental bounds.
Telemetry Calibration	Observability tools (e.g., Prometheus) can dynamically update ledger thresholds and resource profiles.	Real-world telemetry contains multi-tenant noise and requires strict domain-specific isolation.	Currently limited to static ledgers and predefined profiles.
Mapping Overhead	Low-scale topology mapping is computationally magnitudes cheaper than full-scale deployment testing.	Complex cyclical topologies and massive multi-scenario ledgers increase computation and maintenance costs.	Evaluated on small-to-medium prototype topologies without performance benchmarking.
Ledger Maintenance	Independent ledgers for different business lines reduce false positives caused by shared global constants.	Continuous maintenance of ledgers, resource profiles, and formula sources is required; high governance cost.	Established visibility policies and formula sources, but dynamic governance is unimplemented.
Automated Topology Extraction	Translates unstructured architectural sketches into computable objects, bridging NLP and formal engineering verification.	End-to-end extraction remains a bottleneck; topological extraction errors directly distort mapping conclusions.	Assumes agents can output valid TIRs; unmappable states are caught but not automatically repaired.

Table 13. Engineering Applicability and Deployment Boundaries of the PMG Framework

Difficulty Tier	Monolithic Systems	Serverless Architectures	Microservices
L1: Textbook (Known Knowns)	Performance (Basic CRUD) Security (Standard Auth) Maintainability (Clean Code)	Func. Suitability (Event) Maintainability (CRON Job) Cost Efficiency (Static Site)	Maintainability (Service Splitting) Scalability (Read/Write Separation) Func. Suitability (Catalog)
L2: Industrial (Implicit Trade-offs)	Appropriateness (Zero-Budget VM) Performance (HDD I/O Bound) Maintainability (Legacy DLLs)	Performance (Latency vs. Cost) Reliability (Hard Timeout Limit) Security (VPC Cold-start Penalty)	Reliability (Dual-write Sync) Performance (RPC Latency) Appropriateness (Over-eng.)
L3: Infeasible (Epistemic Traps)	Performance (TCP/RAM Limits) Reliability (SPOF vs. 99.9999%) Performance (CPU vs. 8K Video)	Performance (Sub-10 $\mu$ s Real-time) Reliability (1ms Stateful Sync) Performance (500GB RAM Limit)	Reliability (CAP Theorem Limits) Performance (Micro-payment Cost) Security (ZK Analytics)

Interface	Input Fields	Output Fields	Exceptions & Usage
submit_topology	topology_yaml : YAML/JSON string matching the topological template.	mapper_status , visible_ledger , ledger_aligned_bill , profiler_breakdown , nac , collisions , mapper_feedback , cycle_info	Errors or UNMAPPABLE_TOPOLOGY are returned for non-objects, invalid node types, missing edge references, or unbounded loops. Used to submit candidate architectures.
inject_chaos	chaos_yaml : YAML/JSON string containing chaos_target , attack , and override_parameters .	Alongside standard mapping results, it returns chaos_target , attack , and applied_overrides .	Returns an error if no topology exists, the target node is missing, or the injected fields are non-numeric/unsupported by the profile. Used to observe physical projection shifts under load perturbations.

Source Category	Representative Sources	Application in Constraints or Formulas
Universal Resource Observability	USE Method ( Gregg, 2013 ) ; Google Borg Resource Management ( Verma et al., 2015 )	Adopts CPU, Memory, Network, and Storage as the first-order dimensions for system-level resource ledgers.
Queuing & Throughput Modeling	Quantitative System Performance ( Lazowska et al., 1984 )	Supports baseline linear service approximations, throughput/latency inferences, and calibrates metrics like MAX_QPS and P99_LATENCY_MS .
Unit Conversions	NIST SI Units Guide ( Thompson and Taylor, 2008 )	Enforces deterministic conversions for bytes, bits, bandwidth, and throughput units.
Cloud Resource Specs & Pricing	Lambda Pricing ( Amazon Web Services, 2026d ) , Quotas ( Amazon Web Services, 2026e ) ; API Gateway Pricing ( Amazon Web Services, 2026a ) ; EC2 / EBS Specs ( Amazon Web Services, 2026c ; Amazon Web Services, 2026b )	Supports upper bounds for budgets, function memory, instance limits, network bandwidth, and disk IOPS.
Middleware & Runtime Constraints	Redis Memory Optimization ( Redis, 2026 ) ; Linux TCP Buffers ( Linux man-pages project, 2026 ) ; MySQL System Variables ( Oracle Corporation, 2026b ) ; Java Thread Stack ( Oracle Corporation, 2026a )	Supports implicit resource bounds such as cache memory overheads, TCP long-lived connections, DB connection pools, and thread stack allocations.
Prototype Calibration	A2TA internal prototype calibration	Defines local calibration metrics for experiment defaults, migration windows, project cycles, and consistency windows.

Formula Type	Calculation Form	Applicable Profile	Source Category
Base Value + Linear Term	$R=B\cdot I+X\cdot k$ . (e.g., in connection memory estimation, $B$ is base memory, $X$ is connection count, $k$ is per-connection coefficient).	Stateless Service, Relational DB	Throughput Modeling, Runtime Constraints.
Request Load to Bandwidth	NETWORK_MBPS = $Q\cdot S\cdot 8/1024$ , where $S$ is in KB.	api_gateway	Unit Conversions, Cloud Specs.
Serverless Monthly Cost	MONTHLY_COST = $(Q_{h}H/10^{6})\cdot p_{r}+Q_{h}H\cdot(M/1024)\cdot(D/1000)\cdot p_{g}$	lambda_function	Cloud Pricing, Lambda Parameters.
NAC Normalization	$\mathrm{NAC}=(\hat{x}-L)/L$ ; Direction reversed for MIN_* metrics.	All Ledger Metrics	Ledger Thresholds & Formulas.

Case Name	Visible Ledger (Exposed to Agent)	Hidden Mapper Defaults (Internal Only)
Case 001 (Monolith)	MAX_RAM_MB MAX_TCP_CONNECTIONS MAX_QPS MAX_MYSQL_CONNECTIONS	MAX_CPU_CORES MAX_BANDWIDTH_MBPS MAX_DISK_IOPS MAX_THREAD_STACK_KB
Case 002 (Serverless)	MAX_BUDGET_USD P99_LATENCY_MS MAX_REQUESTS_PER_HOUR	MAX_RAM_MB MAX_CPU_CORES MAX_BANDWIDTH_MBPS MAX_DISK_IOPS
Case 003 (Microservices)	No directly exposed items.	MAX_RAM_MB MAX_CPU_CORES MAX_BANDWIDTH_MBPS MAX_DISK_IOPS MAX_BUDGET_USD MAX_QPS MAX_CONSISTENCY_WINDOW_MS

Grounding SWE-Agent Decisions in Architecture-0 Design: Navigating Unknown Unknowns through Physical Mapping

Abstract

Figures & tables

Appendix

Software Architecture Design

Architecture Without Architects: How AI Coding Agents Shape Software Architecture

AgentDSE: Reasoning-Augmented Architectural Design Space Exploration

Do AI Agents Understand Computer Architecture?

Abstract

Software Architecture Design

Explore similar work

Architecture Without Architects: How AI Coding Agents Shape Software Architecture

AgentDSE: Reasoning-Augmented Architectural Design Space Exploration

Do AI Agents Understand Computer Architecture?