Definitions for 1DevTeam software, development systems, architecture, and research terminology. Implemented behavior, development objectives, hypotheses, and unresolved questions remain explicitly separated.
32 of 32 canonical entries are available across Systems, Architecture, Research, and Glossary.
Reference chapter
Development systems and software that address distinct parts of the work: process discipline, project-context transfer, persistent architecture, product execution, and applied R&D outputs.
Systems
Used in practice
A development-process discipline for reliable AI-assisted engineering.
PRIDE defines the actions required for complete reading, sufficient context, system-level reasoning, correct implementation scope, testing, verification, documentation, and review. Its working metric is PRIDE = Proper Actions ÷ Total Actions, with a target of 95% or greater proper actions.
Read expanded reference →Systems
Snapshot v10 used in practice
A project-context transfer system used during Ajenda development.
Snapshot packages structured project state so a language model can begin work with substantially more repository context already available. Captured state can include Git status, file inventory and hashes, routes, dependencies and imports, tests, parse results, environment and configuration structure, and related project evidence. Snapshot reduces repeated project reconstruction; it does not replace repository inspection or architecture reasoning.
Read expanded reference →Systems
Active development and CI capability
A persistent machine-readable model of Ajenda architecture and change relationships.
The graph represents software entities and relationships including modules, selected functions, decision ownership, dependencies, tests, invariants, architecture roles, and selected semantic boundaries. It is used in Ajenda development and CI for impact analysis, proof selection, completeness auditing, architecture decisions, semantic checks, and selected function-level diagnosis. It is development infrastructure, not customer-facing Ajenda runtime functionality.
Read expanded reference →Systems
Private development · locally operational
Structured execution software for missions, plans, tasks, approvals, and controlled actions.
Ajenda converts objectives into durable mission state and controlled execution. Its architecture separates interpretation, planning, authority, capability selection, review, execution, recovery, and outcome recording so understanding an instruction does not silently grant permission to act.
Systems
R&D / in development
An R&D system concept for reconstructing and exposing the architecture of existing software.
Grafted Plus is intended to extract and map architectural truth from an existing system into a machine-reasonable representation so an external language model can reason across ownership, dependencies, invariants, state, data paths, runtime boundaries, blast radius, and proof obligations without repeatedly rebuilding the architecture from isolated files.
Systems
R&D / in development
An R&D system concept for modeling intended architecture before substantial implementation begins.
Grafted First is intended to represent the complete intended system—components, models, contracts, invariants, dependencies, constraints, state, data relationships, boundaries, and interacting variables—before implementation. An external language model can then reason over the explicit design and guide implementation against it. Comparative effectiveness remains a research question.
Reference chapter
Terms for reasoning beyond the file being edited, including ownership, dependencies, invariants, blast radius, graph relationships, and the proof surface surrounding a change.
Architecture
The set of system surfaces that can be materially affected by a software change.
Architectural blast radius can include components, contracts, invariants, runtime surfaces, tests, state relationships, authority boundaries, data paths, integrations, and downstream behavior. It is broader than the set of files directly modified by a change. The study compares reasoning and change scope with this broader affected surface.
Read expanded reference →Architecture
Identification of the component or function that actually owns a behavioral decision.
Decision ownership is used to distinguish the architectural owner of behavior from files that merely observe, call, wrap, or compensate for it. In graph-assisted Ajenda work, selected function nodes can carry decision-role metadata so repair analysis can move from a visible symptom toward the function or contract that owns the decision.
Read expanded reference →Architecture
A condition that must remain true across relevant system states or operations.
Invariants can govern state ownership, authority, data access, concurrency, execution ordering, recovery, or other architectural behavior. A locally passing change remains incomplete if it violates a relevant invariant elsewhere in the affected system.
Architecture
Graph-assisted determination of nodes, tests, and system surfaces affected by a proposed change.
Ajenda graph tooling can start from changed or selected nodes and traverse machine-readable relationships to identify affected architecture and candidate proof obligations. Impact analysis is used as evidence for change scope; it does not by itself prove that every affected runtime behavior has been validated.
Architecture
Selection of tests and checks required to support a specific architecture change.
Graph-aware proof selection uses architecture state and impact information to determine which tests, invariants, semantic checks, or other verification surfaces should run for a change. It extends beyond the immediate test closest to the edited file.
Read expanded reference →Architecture
Execution of a targeted proof set selected from change and architecture information.
Ajenda uses graph-aware proof information to support selective-CI reasoning and shadow execution. The purpose is to reduce irrelevant proof while preserving evidence required by the affected architecture. Selectivity is constrained by graph completeness and the quality of mapped relationships.
Architecture
An audit of whether required architecture entities and relationships are represented sufficiently for graph-governed reasoning.
Completeness auditing identifies missing mappings, topology gaps, and known historical findings instead of treating graph presence as proof of complete architectural coverage. A passing completeness audit can preserve acknowledged residual findings rather than hiding them.
Architecture
A directed graph relationship indicating that one represented function calls another.
The relationship is used for selected function-level dependency and impact reasoning. It describes a represented call relationship in the canonical graph; it should not be interpreted as a complete dynamic execution trace.
Architecture
A graph relationship connecting a test to a represented function it directly exercises.
Direct function-test edges make selected proof relationships explicit in the architecture graph and can support impact analysis and targeted verification. They represent mapped direct relationships, not every possible indirect test effect.
Architecture
A graph relationship connecting a represented function to the module or file that defines it.
The relationship preserves the distinction between function-level decision nodes and their source-code container, allowing analysis to move between architectural ownership and concrete repository location.
Reference chapter
Units used in 1DevTeam R&D Program #1 to separate measurement, observations, intervention periods, and findings without promoting preliminary patterns into conclusions.
Research
A sequence of subsequent pull requests associated with correcting, completing, or responding to prior software changes.
The study examines corrective propagation without assuming that every later PR was caused by the immediately preceding PR. Coding distinguishes introduced defects from previously latent defects that a change merely exposed and considers causal relationships, chronology, repair unit, proof behavior, and competing explanations.
Read expanded reference →Research
The portion of the system included in the analysis used to understand and plan a software change.
Reasoning scope can be narrower or broader than the actual architecture affected by a change. The primary study asks whether mismatch between reasoning or change scope and architectural blast radius predicts subsequent corrective PR cascades.
Read expanded reference →Research
The implementation surface actually modified to produce a software change.
Change scope is evaluated against architectural blast radius rather than treated as sufficient simply because a local test passes. A change can be technically valid at one layer while remaining incomplete relative to the contracts, invariants, or downstream behavior affected by the repair.
Research
The abstraction level at which a software defect or required correction is represented and repaired.
Study coding can distinguish local symptom, component contract, cross-boundary contract, shared invariant, and system-wide invariant repair units. A shift in repair-unit abstraction is a candidate mechanism under study, not evidence by itself that one development condition is superior.
Research
The study epoch in which the architectural graph did not exist.
Architecture had to be reconstructed from source code, tests, runtime traces, PR history, review context, and existing development discipline. This period is coded as graph absent—not as an implicit, primitive, or immature graph.
Research
The study epoch during which graph capabilities were being built and calibrated.
This period separates graph creation from later graph-assisted development so the intervention boundary remains explicit. Capabilities introduced across this period include architecture representation, semantic overlays, impact analysis, invariant mapping, proof selection, and governance controls.
Research
The study epoch in which active repair work can materially use persistent graph state.
Graph-assisted work can use graph-derived impact analysis, invariant checks, proof selection, architecture decisions, and post-repair graph-state comparison. The study does not assume that this condition is superior; codebase maturity, CI maturity, model and tooling changes, test coverage, PR size, repair unit, and defect class remain competing explanations.
Research
A research proposition tracked before final adjudication.
A candidate finding is not a finished result. It can accumulate evidence, become provisionally supported, be contradicted, be rejected, or later be adjudicated as supported. This separation prevents preliminary observations from being presented as settled scientific conclusions.
Reference chapter
Supporting terms used across Ajenda, the development method, architecture work, and the research program.
Glossary
A durable Ajenda unit that represents an objective and its structured execution state.
A mission can contain planning, tasks, authority state, approvals, execution progress, outcomes, and recovery information. Treating missions as durable state distinguishes Ajenda execution from transient conversational context.
Glossary
A boundary separating interpretation or planning from permission to perform an external action.
Ajenda treats understanding a request and having authority to execute it as separate concerns. Capability checks, policy, approvals, and explicit execution controls can therefore govern actions independently from language interpretation.
Glossary
Execution routed through explicit capability, authority, policy, review, and failure-handling boundaries.
Controlled execution is intended to preserve the distinction between deciding what should happen and authorizing software to perform the action. The exact controls depend on the operation and system context.
Glossary
Recorded state and outcomes that make system actions inspectable after execution.
Execution evidence can include mission state, approvals, selected capabilities, actions, state transitions, errors, recovery behavior, and resulting outcomes. It provides an inspectable record rather than relying only on conversational claims about what occurred.
Glossary
Analysis that includes relevant dependencies, contracts, state, authority, invariants, failure paths, and downstream effects.
Whole-system reasoning does not require inspecting every file for every change. It requires reasoning scope to cover the architecture materially affected by the change and to identify unresolved information instead of silently substituting assumptions.
Glossary
An explicit model of what a software system is designed to become.
Within the Grafted First concept, intended architecture includes components, contracts, invariants, dependencies, constraints, state, data relationships, ownership, and boundaries modeled before substantial implementation.
Glossary
A machine-reasonable representation extracted from an existing software system.
Within the Grafted Plus concept, reconstructed architecture is intended to reflect the actual system rather than the design originally intended for it. The quality of that reconstruction depends on the evidence extracted and the completeness of the mapping.
Glossary
Difference between intended system architecture and reconstructed actual architecture.
A future Grafted workflow may compare an intended architecture produced at project origin with an architecture reconstructed after implementation. This comparison remains a development hypothesis rather than an established research result.
Evidence boundary
Implemented behavior is described as implemented. Development objectives remain objectives. Research hypotheses remain hypotheses. Unknowns remain unresolved until evidence supports a stronger classification.
The wiki is a reference layer for the work, not a substitute for the underlying artifacts, repository evidence, study records, or implementation itself.
