Presented is a novel framework for interactive systems architecture definition at early design stages. It incorporates graph-theoretic data structures, entity relationships, and algorithms that enable the systems architect to operate interactively and simultaneously in different domains. It explicitly captures the "zigzagging" of the functional reasoning process, including not only allocated, but also the derived functions. A prototype software tool, AirCADia Architect, was implemented, which allowed the framework to be demonstrated to and tried hands-on by practicing aircraft systems architects. The tool enables architects to effectively express their ideas when interactively synthesizing new architectures, while still retaining control over the process. The proposed approach was especially acknowledged as the way forward for rationale capture. K E Y W O R D S architecture definition, systems engineering 1 INTRODUCTION The ability to innovate is considered one of the key factors for success in the globally competitive world of today. This is particularly relevant in the design of complex systems, such as aircraft, where the requisite subsystems, for example, environmental control, flight control, etc., account for about one-third of the total empty weight and cost. 1 Innovation in aircraft subsystems design can bring forth significant competitive advantages, such as improved fuel consumption, reduced maintenance costs, and higher reliability. The work reported in this paper is related to innovative systems architecting and originates from a topical European research project, "Thermal Overall Integrated Conception of Aircraft" (TOICA). 2,3 Specifically, the authors contributed to one of the research objectives of TOICA: the development of methods and tools enabling systems architects to discover, define, assess, and evaluate (systems) architectures. Within this wider context, the scope of the research described herein has been restricted to the process of conceptual systems architecture definition, within the requirements (R), functional (F), and logical (L) domains. The term requirements domain refers to the activities involving requirements engineering and management. The functional domain is concerned with the functional decomposition and analysis, and the logical domain deals with the specification of solutions and their interfaces. In the systems engineering community, solutions are also referred to as forms, means, or artifacts, and include both components and subsystems. Also, logical solutions are sometimes referredto as physical solutions. In this paper, we shall distinguish between logical and physical domains, where the former is assumed to be concerned mainly with the interconnectivity between components and subsystems, while the latter with spatial layout and geometry. In a recent publication, 4 we presented data structures underpinning basic operations that take place in the F-L domains. Here, we extend that work to include requirements and the notion of a computational (behavioral) domain. The latt...