Architecture
The decisions and responsibilities that connect a service’s purpose, organisation, domain meaning, information, software, technology, teams, delivery, operation, support and assurance. Implementation and operation can return learning that changes those decisions.
Architecture loop
A recurring question, the people or tools allowed to answer it, and a result that may change later work. For example, an operations loop may return a failed recovery to the component design.
Portfolio-learning loop
The wider loop that decides whether a lesson from one delivery slice should change a shared asset, the system blueprint, a project direction or the portfolio itself.
Delivery dial
One setting that changes how an architecture loop runs: cadence, batch size, coordination, decision authority, automation and required proof, or the reach of new learning.
Delivery profile
The combined dial settings across the active loops. A profile explains how delivery behaves more precisely than a label such as waterfall, agile or agent-assisted.
Agent-assisted delivery
A delivery profile in which software agents perform authorised research, modelling, implementation, checking or documentation tasks. People still set the purpose and authority, review consequential decisions and accept the result when human judgement is required.
Logical component
A named responsibility with defined interactions, ownership and failure behaviour. A logical component does not have to be a separately deployed service.
System blueprint
A reusable map of logical components and the questions used to assess them. It describes responsibility, information movement, failure and recovery before a team selects products or deployment units.
Contract
An agreed description of what one role may request, what another role returns or reports, and how refusal, failure, repetition and change are handled.
Business language
A small language that gives stable, reviewable form to business meaning such as facts, work, decisions, rules, obligations or time. Some business languages may execute; others may describe information or policy without running.
REXX
The language family from which cREXX takes its name and relevant syntax and behaviour. Reusing the CREXX execution stack would not make CoreLang or another business language a REXX dialect.
LLVM
Compiler infrastructure that could support a later native-code backend experiment. It is not a current CoreLang backend or committed dependency.
Knowledge, retrieval and source grounding
The responsibility for reconciling source material, preserving where a claim came from and returning relevant passages, accepted claims, ambiguity, conflicts and gaps to a person or agent.
AI orchestration and tool execution
The responsibility for connecting model calls, retrieval, scripts, external tools and human-input steps during a computational execution and showing its progress. It is different from owning long-running human work, deadlines and recovery.
Implemented
Working code or published material exists and has a named authoritative source. The label applies only to the named capability and does not imply production readiness.
Experimental
Something works, has deliberate limits and is still being evaluated.
Working proof of concept
An experimental implementation that answers a specific feasibility question. Its stated limits prevent it from being treated as a production capability.
In development
Active implementation or content work exists, but the described capability is not yet usable as a complete result.
Proposed
The direction has been described, but the capability, contract or composition does not yet exist.
Later research
A possible future experiment that is not current delivery work or a committed dependency.
Historical
Material retained to explain how the work developed. It is not a current recommendation merely because it remains available.