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.
Methodology
The activities, roles, decision rights, records, handovers and feedback used to develop and change an architecture. Assessment distinguishes the method’s performance from the resulting architecture.
Framework and ASAF
A framework organises concerns and descriptions. A Simple Architectural Framework (ASAF) uses aspects, process areas and levels of abstraction. Teams map it to their own methodology’s terminology and activities.
Aspect
A concern examined across the architecture, such as Information, Security or Systems. Business architecture is a route through several aspects.
Process areas
Visioning, Transforming, Operating and Governing describe continuing work. They can overlap and repeat. The Process aspect instead describes the organisation’s activities, rules and handovers.
Levels of abstraction
Conceptual descriptions explain the main ideas. Logical descriptions specify the design without selecting an implementation. Physical descriptions name implementation details. Each level can be used in any process area; a Physical proposal can still be unbuilt.
Architecture cycle (or 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 checking, or learning reach.
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.
AI-assisted delivery
Artificial intelligence (AI) tools may assist 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 connected description of a service or solution across the relevant architectural aspects. The course-cancellation blueprint brings together purpose, people, work, information, systems, controls and operation. Its views share named objects, decisions and open choices.
Record, template and asset
A record retains information used in a decision or handover, such as a model, requirement or contract. A template helps create or maintain that record. Reusable assets include templates, examples and diagram sources. The templates pair blank records with completed examples.
Design state and edition
A design state describes an arrangement, such as the proposed manual trial or later software option. An edition identifies the website page or asset. An implementation release and the version of a running case have their own identities. One cannot stand in for another.
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
A described direction or design whose intended arrangement has not yet been agreed or implemented.
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.