Goose Project Introduction

The emergence of AI has not simplified systems; instead, it has systematically exposed structural issues in engineering architecture for the first time.

In the past, the core task of engineering systems was capability construction: building stable, efficient, and scalable distributed systems around foundational capabilities such as retrieval, ranking, storage, and scheduling. This paradigm relies on the assumption that capabilities are stable, changes are local, and system complexity can be managed through modularization and layering.

However, as AI becomes deeply integrated into business systems, the nature of what the system is responsible for has fundamentally changed:

The system is no longer merely a carrier of capabilities, but has begun to host continuously evolving decision processes.

From a more abstract perspective, this marks a paradigm shift in system architecture:

From “capability-driven systems,”
to “expression-driven systems,”
and further toward “decision-modelable systems.”

Because commercial systems must satisfy three fundamental requirements:

Decisions must be reproducible (otherwise they cannot be evaluated)
Strategies must be comparable (otherwise they cannot be optimized)
Systems must be governable (otherwise they cannot scale)

Correspondingly, at the architectural level, three key changes emerge:

First, compositions are no longer scattered, but converge into a unified structure.
Second, strategies are no longer embedded in implementation, but elevated to the Business Expression Layer for adjustment.
Third, execution no longer needs to understand business logic, but only needs to faithfully execute the expression.

I. Problems and Contradictions

1.1 The Nature of the Problem: From Capability Organization to Decision Organization

In traditional systems, various capabilities (such as tokenization, semantic understanding, entity recognition, retrieval, and ranking) are typically implemented as modular components and orchestrated through fixed pipelines. The key characteristics of this model are:

• Execution paths are relatively fixed
• Capability boundaries are clearly defined
• Changes occur mainly locally
• The overall system structure remains stable

Under this premise, engineering efforts focus primarily on performance, scalability, and reliability.

However, in AI-driven scenarios, the nature of change shifts:

• A single request no longer corresponds to a fixed execution path
• Multiple capabilities must be dynamically composed under different objectives
• Multiple objectives (user experience, business value, risk control, etc.) coexist with dynamically changing weights
• Strategies vary across users, contexts, and time

In other words, the system is no longer “invoking capabilities,” but instead:

Performing a decision process that dynamically composes capabilities based on objectives and context.

The capabilities themselves have not changed; what has changed is how they are organized.

1.2 Structural Contradiction: Change Enters the Core of the System

Traditional architectures implicitly assume that:

• Capabilities are stable entities
• Changes are local
• Composition is an implementation detail

In AI scenarios, this assumption is broken:

• Capabilities become composable units
• Composition becomes core logic
• Change becomes a driving factor of the system

When composition logic becomes central but is not explicitly expressed, the system inevitably exhibits the following behavior:

Changes propagate implicitly and eventually lead to uncontrollable growth in complexity.

This manifests as:

• Strategy logic scattered across multiple services and execution paths
• Business logic spanning multiple system boundaries
• Modifying a single strategy requires coordinating multiple modules
• System behavior becomes difficult to understand and reason about holistically
• Debugging relies on full-chain tracing

The system gradually evolves from a “structured system” into a “historically accumulated system.”

1.3 Core Missing Piece: The Business Expression Layer

From an architectural perspective, the root cause is not insufficient capability, but rather the absence of a critical abstraction layer:

The business expression layer

Traditional systems include two types of abstractions:

• Capability abstraction (modules/services)
• Execution abstraction (scheduling/computation/storage)

However, they lack a third essential abstraction:

An explicit representation of the business logic itself and how capabilities are composed

As a result, the most critical part—capability composition logic—only exists implicitly:

• Scattered across code
• Hidden in configuration
• Embedded within invocation chains

This leads to a fundamental problem:

Capabilities can be executed, but compositions cannot be expressed; changes can occur, but cannot be systematically constrained.

More importantly, implicit existence introduces not just efficiency issues, but structural ones:

• Composition logic is dispersed across code, configuration, and execution chains
• Different modules handle portions of decision-making independently
• Strategy changes require cross-system coordination
• System behavior cannot be modeled holistically
• Evolution depends on human understanding rather than structural constraints

This structural issue is particularly evident in projects like kmcmake. Many open-source projects contain thousands of lines in CMakeLists.txt, not because the functionality is inherently complex, but because composition logic is scattered across numerous if, option, and include constructs, governed by implicit conventions. kmcmake achieves similar build objectives with significantly less configuration not by “writing less CMake,” but by first introducing an explicit expression model: consolidating targets, dependencies, tests, installation, and packaging rules into a unified representation, and then letting the execution layer operate based on that expression. For example, interfaces like kmcmake_cc_test(...) and kmcmake_cc_test_ext(...) encapsulate test composition rules in a declarative manner, avoiding the dispersion of strategy across multiple script fragments. In the context of this document, this directly reflects the principles of “compositions are unified, strategies are not embedded, and execution follows expression.”

The system can only adapt to change by continuously modifying implementations, rather than absorbing change at the structural level.

1.4 From Capability Systems to Decision Systems

In this context, the system must evolve:

Capability Systems (Traditional Paradigm)

• Core goal: provide stable capabilities
• Structure: fixed paths, clear modules
• Change: localized adjustments
• Optimization focus: performance and scalability

Decision Systems (AI Paradigm)

• Core goal: dynamically organize capabilities to make decisions
• Structure: dynamic paths, composition-driven
• Change: system-wide impact
• Optimization focus: strategy expression and composition control

The essence of a decision system is no longer “what to do,” but:

How to compose existing capabilities under different constraints to produce optimal outcomes.

Thus, the core problem becomes:

How to describe, organize, and control the process of capability composition.

II. Goose’s Approach

2.1 Core Idea of Goose: Introducing the Business Expression Layer

Goose does not aim to introduce new foundational capabilities, but to fill a missing structural layer:

The business expression layer

In Goose, business logic is no longer implicitly embedded in code and execution chains, but elevated into an explicitly describable structure.

Its core carrier is:

SQL IR (Intermediate Representation)

The key is not SQL itself, but IR, whose role is to:

• Provide a unified representation of business logic
• Explicitly describe relationships between capabilities
• Decouple strategies from implementation
• Move change from the code layer to the expression layer

Through this layer, the system gains three key capabilities:

1. Composability becomes explicit
   Relationships between capabilities are no longer implicit but structurally described

2. Changes become constrained
   Strategy changes are managed at the expression layer rather than directly affecting implementations

3. Execution becomes decoupled
   The execution layer does not need to understand business logic; it only executes based on expressions, ensuring structural stability

2.2 Changes in System Architecture

With the introduction of the business expression layer, the system architecture evolves:

• Business logic shifts from “implementation in code” to “structured expression in the expression layer”
• Capabilities shift from “invoked objects” to “composable units”
• The system shifts from “execution-oriented” to “expression-driven”

This forms a new layered model:

• Business expression layer (describes composition)
• Execution and scheduling layer (handles execution)
• Capability layer (provides foundational capabilities)

The business expression layer becomes the critical bridge connecting “change” and “system.”

2.3 Goose’s Position: A Unified Expression and Control Layer

In larger systems (such as complex business ecosystems or multi-system architectures), Goose operates as a higher-level abstraction:

A unified expression and coordination control layer

Its responsibilities include:

• Mapping business requirements into structured expressions
• Translating expressions into executable paths
• Establishing consistent composition semantics across multiple systems and capabilities
• Constraining the impact of changes within the expression layer

Therefore, Goose is not a single subsystem, but a cross-system structural coordinator.

III. Validation and Implementation

3.1 The Significance of gnef: Minimal Validation of Structural Feasibility

gnef can be viewed as a preliminary slice of the Goose system, covering the earliest and most sensitive stages of decision-making and semantic processing.

Its significance lies not in functionality itself, but in validating:

Whether unified expression can still constrain system behavior in the most composition-intensive and change-sensitive parts of the system.

The results demonstrate:

• Capability composition can be explicitly expressed
• Changes can be constrained to the expression layer
• Execution remains structurally stable
• A clear mapping can be established between expression and execution

This confirms that the business expression layer is not only theoretically sound, but also practically implementable.

As a preliminary validation slice of the Goose system, gnef has completed internal invocation verification, and its verifiable behavior directly supports the feasibility of the business expression layer.

First, during gnef invocation, semantic processing capability compositions (tokenization, entity recognition, and initial intent analysis) are all described structurally via SQL IR. Invocation logs allow tracking of each composition definition and modification without tracing underlying code.

Second, the output structure of gnef remains stable and consistent. Even when upstream strategies change (e.g., shifting from keyword matching to intent-centric understanding), the output format remains unchanged. Adjustments only occur at the SQL IR layer, without affecting downstream execution chains.

Third, gnef supports rapid strategy switching. Differences in outputs for the same input under different strategies can be directly identified through SQL IR comparisons, eliminating the need for full-chain code debugging. This behavior has been repeatedly validated in internal tests.

3.2 The Essence of Goose

In summary, Goose is not a traditional system component, but rather a system architecture paradigm for the AI era, centered on:

Replacing implicit composition with explicit expression, and managing complexity through structured representation.

It addresses not a single-point problem, but a fundamental one:

How to ensure that systems remain understandable, controllable, and evolvable in AI-driven dynamic business environments.

3.3 Practical Examples (From Concept to Execution)

To avoid remaining purely conceptual, here are two practical examples.

Example A: Strategy Switching in E-commerce Search (“Low-price demand” vs “High-end preference”)

Business context: For the same query “phone case,” user intent varies significantly. Some users are price-sensitive, while others prioritize brand and quality.
Traditional approaches often implement separate pipelines and route at the service layer, leading to code and configuration bloat as strategies increase.

With Goose + gnef, the entry point remains unified, and strategy switching occurs at the SQL IR layer:

pragma initialize_gnef_default;
select nlp_process('iphone 16 pro max phone case', 1); -- low-price strategy
select nlp_process('iphone 16 pro max phone case', 3); -- high-end strategy

In this pattern, the invocation entry remains unchanged, strategy selection is completed through parameters, and the output structure remains stable and comparable. The engineering implication is straightforward: strategy changes are confined to the Business Expression Layer, without requiring changes to downstream execution pipelines.

Example B: Content Distribution (“Strong intent” vs “Exploratory intent”)

Business context: Content platforms adopt different intent strategies for highly active users versus cold-start users. Highly active users benefit from strong intent paths, while cold-start users require exploratory strategies.

With Goose + gnef, strategy switching can be achieved via named strategies at a unified entry point:

pragma initialize_gnef_default;
select nlp_process('how to choose running shoes for beginners', 'intent_strong');
select nlp_process('how to choose running shoes for beginners', 'intent_explore');

Here, the same input can flow through different strategies while preserving a consistent output schema for A/B comparison. Changes stay localized in strategy configuration and do not invade downstream execution systems. As a result, strategy experimentation and rollout share a unified path, which materially reduces iteration cost.

3.4 Implementation-Level Capabilities of Goose (Not a Concept List)

The value of Goose lies not in proposing concepts, but in providing executable implementations. At the implementation level, four key capabilities emerge:

1. Unified entry point with composable function mechanisms
2. Decoupling of the Business Expression Layer and the execution layer
3. Stable output contracts under strategy changes
4. Traceability and governance of invocation, strategy, and output relationships

Together, these form a closed-loop system:

Express → Configure → Execute → Compare → Trace

IV. Conclusion

AI does not introduce new foundational capabilities; instead, it changes the relationships between capabilities, making composition the central concern of systems.

Traditional systems hide complexity, whereas Goose:

Makes complexity explicit through structured expression and controls it at the Business Expression Layer.

When capabilities can be expressed, compositions can be modeled, and changes can be constrained, systems gain the ability to evolve sustainably.

Goose aims to provide such a structural layer, enabling systems to transition from being overwhelmed by complexity to actively managing it.