1DevTeam R&D Program #1

Architectural reasoning scope and corrective PR cascades

1DevTeam's first formal R&D program studies architectural reasoning scope and corrective PR cascades in AI-assisted software development. The study examines whether mismatches between the scope applied to a software change and its actual architectural blast radius predict subsequent corrective work.

Interactive graph Technical evidence

Formal study title

Architectural Reasoning Scope and Corrective PR Cascades in AI-Assisted Software Development: A Longitudinal and Prospective Study of Ajenda AI

Primary research question

Does mismatch between the reasoning or change scope applied to a software modification and the actual architectural blast radius of that modification predict subsequent corrective pull-request cascades?

Scientific boundary

This study is an empirical investigation, not a product-validation exercise. Graph-assisted development, invariant-centered repair, G.R.A.F.T.+, and G.R.A.F.T.1st are not assumed to be superior in advance.

Positive, negative, null, and contradictory results remain valid research outcomes. Product objectives do not determine scientific conclusions, and preliminary observations remain revisable until the evidence supports a stronger classification.

Study epochs

Preserving the intervention boundary

The periods before, during, and after graph introduction remain distinct development conditions. Earlier work is not retroactively described as an immature form of graph assistance.

01
Pre-Graph
The architectural graph did not yet exist. Development relied on repository inspection, testing, traces, PR review, manual architectural reconstruction, and the existing PRIDE development discipline.
02
Graph Construction
The architecture graph and associated CI capabilities were introduced and expanded. The graph increasingly exposed source-backed structure, while blast radius, proof strategy, risk, and architectural judgment remained separate reasoning steps.
03
Graph-Assisted Development
Persistent graph state and increasingly fine-grained responsibility identity became available during active development. The receiving AI used that observed state to calculate impact, choose proof, and make architectural decisions.

Measurement

What the study measures

The objective is to distinguish successful local modification from system-level repair quality and subsequent corrective propagation.

01Reasoning scope and change scope applied to the repair.
02Architectural blast radius, including changed files, runtime surfaces, dependencies, invariants, and affected proof.
03Corrective PR propagation and whether later work repairs an introduced defect, exposes a latent defect, or extends an incomplete repair.
04Repair-unit type and the ownership layer at which the change is applied.
05Local proof versus system-level proof and the residual state intentionally left unresolved.
06Graph state and expected versus observed graph-state movement after repair.
07Test coverage, CI maturity, codebase maturity, model and tool capability, PR size, defect class, and related confounders.
08Where failures are detected: later corrective work, pre-merge proof, graph governance, or semantic enforcement.

Applied R&D relationship

G.R.A.F.T.+ and G.R.A.F.T.1st

The study can inform G.R.A.F.T.+ and G.R.A.F.T.1st, but those systems remain development outputs rather than evidence of the study's conclusion. Research may support their current design assumptions, narrow them, contradict them, or expose different mechanisms entirely.

Existing systems

Applied R&D output · in development

G.R.A.F.T.+

G.R.A.F.T.+ reconstructs a public GitHub repository at one SHA into evidence-linked facts and one downloadable pack so an external language model can reason over inventory, contracts, dependencies, routes, wiring, and intent. Residuals stay visible. It is a fact substrate, not a planner and not merge authority.

Public repository → reconstruct one SHA → download the fact pack → give the receipt and ASCII topology to an AI → let the AI calculate reach, proof, risk, and architecture.

Map a public repository →

Project-origin architecture

Applied R&D output · in development

G.R.A.F.T.1st

G.R.A.F.T.1st is intended to model the architecture of a software system before implementation begins. The objective is to represent contracts, nodes, models, ownership, dependencies, state, boundaries, and system interactions in a form that can be reasoned over before the first implementation decisions are committed to code. Its relationship to implementation quality remains a research and development question rather than an established conclusion. This lab is G.R.A.F.T.+ only.

Intended system → explicitly model the architectural problem → reason across the complete design → build against that model.

Intended future relationship

G.R.A.F.T.1st → intended architecture → implementation → G.R.A.F.T.+ → reconstructed architecture → drift analysis

This remains a development hypothesis, not a completed research finding.

Future R&D work

Entangled Software: Perceiving Emergent Behavior Before It Happens

Future R&D · collaborators and research support welcome

1DevTeam is developing a research direction for understanding how interactions among software components produce unexpected system-wide behavior. The proposed approach combines architecture mapping, continuous multiscale information-flow observation, and controlled experiments to detect how small changes propagate through a system.

Starting with fully characterized baseline systems, the study will introduce individual mechanisms against matched controls, repeat experiments, and investigate whether recurring mathematical relationships can predict interactions not yet observed. The goal is to develop evidence-based foresight into architectural change, emergent capabilities, and system-level risk.

We welcome conversations with research collaborators, systems engineers, academic partners, and organizations interested in supporting exploratory work through funding, compute resources, experimental infrastructure, or joint studies.

Read the research foundation →Discuss collaboration or support →

Proposed research, not a demonstrated predictive capability.

Research operating policy

Controls on interpretation

Scientific conclusions remain independent

The study is an empirical investigation, not a product-validation exercise. Positive, negative, null, and contradictory results remain valid research outcomes, and product objectives do not determine scientific conclusions.

Preserve the graph intervention boundary

The pre-graph period is coded as graph absent. Graph construction and graph-assisted development are separate epochs so the intervention is not retroactively projected onto earlier work.

Triangulate material findings

Material findings are evaluated across chronology, PR context, human directives, assistant-generated operational prompts, repository architecture, changed-file scope, CI and proof behavior, corrective relationships, graph state, and relevant confounders.

Separate instruction origin

Human directives and assistant-generated operational prompts are treated as distinct sources when evaluating whether workflow changes came from instruction differences or from a different reasoning environment.

Control competing explanations

CI maturity, model and tooling changes, codebase maturity, test coverage, repair-unit type, PR size, and defect class are treated as competing explanations rather than being silently attributed to graph assistance.

Current research status

Observations remain distinct from findings

Preliminary observations can be revised, contradicted, or rejected as additional evidence and causal coding are completed.

Preliminary qualitative note

Human directive style does not appear to explain the whole shift

Terse, verification-oriented human directives appear in both graph-absent and graph-assisted cases. The full prompt corpus is not yet quantitatively coded, so this remains a covariate under measurement rather than a frozen finding.

Observed workflow difference

Persistent architectural state changes the reasoning substrate

Before the graph existed, system structure had to be reconstructed repeatedly from code, tests, traces, and prior context. Graph-assisted work can expose persistent machine-readable identities and relationships; the receiving AI derives blast radius, proof obligations, risk, and architectural judgment from that observed reality.

Observed measurement capability

Repairs can be evaluated against residual system state

A green test suite is not the only available finish signal. A targeted repair can also be compared with expected graph-state movement, preservation of unrelated residual findings, and post-merge recertification.

Exploratory hypothesis

Graph assistance may move some failures earlier

One hypothesis under investigation is that graph-governed workflows may shift some failures from later corrective PRs into earlier semantic detection, proof selection, or governance review. This is distinct from claiming that graph assistance reduces failures overall.

Confounder control

Process discipline and CI improvement predate the graph

PRIDE-style requirements for complete reasoning predate the graph, while CI and proof infrastructure also matured over time. Neither can be credited to graph assistance without separate evidence.