architecture\_framework: Viable Systems Model inspired Orthogonal Architecture Dimensions
---
# INTENT.md — helix-forge
> \*\*HelixForge envisions a world where software capabilities evolve with understanding, not guesswork.\*\*
## 1\. Repository intent
`helix-forge` exists to make **HelixForge** executable: a capability-first development ecosystem where real-world demands are discovered in natural language, shaped into reusable software capabilities, and delivered through validated architecture and implementation artifacts.
HelixForge treats software creation as a forge rather than a factory. A capability is not merely coded; it is refined through dialogue, structural modeling, validation, implementation, feedback, and reuse. The repository should therefore preserve both strands of the HelixForge double helix:
1.**Human understanding** — discovery, intent, problem framing, language, ownership, value, and fitness.
The purpose of this repository is to turn intent into structure, structure into capability, and capability into lasting progress.
## 2\. Vision alignment
HelixForge empowers a global ecosystem of users, builders, and investors to collaboratively forge reusable software capabilities from real-world problems. It intertwines the natural-language art of discovery with the precise science of delivery, accumulating a battle-tested repository of composable intelligence that accelerates innovation for all.
This repository should advance that vision by ensuring that every meaningful contribution can answer the following questions:
* **What human or organizational intent does this serve?**
* **What reusable capability does it strengthen or create?**
* **Where does it belong in the Orthogonal Architecture Dimensions?**
* **Which Viable Systems Model function does it support?**
* **How is its correctness, safety, and usefulness validated?**
* **How does it improve the capability repository rather than merely add code?**
## 3\. Operating thesis
HelixForge is built on the belief that software capabilities evolve best when discovery and delivery are part of one continuous system.
Discovery without delivery produces insight that may never become useful. Delivery without discovery produces software that may work but may not matter. HelixForge connects them through an architecture-aware process where demands mature into capabilities, capabilities become contracts and realizations, and realizations are validated against both human intent and machine-checkable standards.
The repository should therefore prefer work that:
* explores problems before prescribing solutions;
* captures capability intent before implementation detail;
* expresses architecture using controlled vocabulary;
* keeps independent dimensions orthogonal instead of mixing concerns;
* uses executable schemas and semantic rules as truth-bearing artifacts;
* treats AI assistance as governed, observable, and architecturally placed;
* improves reuse, composability, and accumulated capability value.
## 4\. Primary outcomes
The repository is successful when it supports these outcomes:
### 4.1 Capability discovery
HelixForge must help users, builders, and investors describe problems, demands, constraints, and opportunities in natural language while progressively clarifying scope, ownership, value, and architectural fit.
### 4.2 Capability modeling
HelixForge must model capabilities as stable architectural units. A capability should have a purpose, boundary, contract, quality expectations, ownership, and relationship to other capabilities.
### 4.3 Capability realization
HelixForge must support implementation artifacts that realize capabilities through services, applications, platform services, integrations, automations, data stores, policies, and intelligence components.
### 4.4 Capability validation
HelixForge must validate architecture descriptions structurally and semantically using the Orthogonal Architecture Standard and its semantic rule profile.
### 4.5 Capability evolution
HelixForge must preserve feedback, learning, and architectural evidence so that capabilities improve through use rather than merely accumulate as static assets.
## 5\. Architectural foundation
HelixForge uses the **Orthogonal Architecture Standard** and an **OAS-compatible Orthogonal Architecture Dimensions information architecture**. The standard describes architectures as elements, placements, relations, principles, sources, and metadata.
The architectural foundation has three layers:
1.**Controlled vocabulary** — stable codes, names, verbs, and explanations for architecture dimensions and viable-system functions.
2.**Structural validation** — JSON Schema validation for the shape of architecture documents.
3.**Semantic validation** — architectural rules that check whether the model is meaningful, not merely syntactically valid.
The current standard reference is **Orthogonal Architecture Standard Schema v1.0.1**. Architecture documents should use:
```yaml
standard: OrthogonalArchitectureStandard
version: "1.0.1"
```
## 6\. Orthogonal Architecture Dimensions
HelixForge uses six independent dimensions. A single architectural element may be placed in multiple dimensions, but each placement must remain clear about which concern it expresses.
> Vocabulary note: the codes, short labels, verbs, and explanations are taken from the current OAD workbook. Minor obvious spelling is normalized in this prose, while the controlled codes remain unchanged.
### 6.1 Plane dimension
The Plane dimension describes operational responsibility.
|S1|Infrastructure|Infrastructure Substrate|carry|Defines the physical or cloud infrastructure|Cloud accounts, network foundations, compute nodes, operating systems, container runtimes|
|S2|Runtime|Cluster Runtime|run|Defines the orchestration runtime|Kubernetes scheduler, service discovery, ingress, admission controllers, service mesh, operators|
## 7\. Viable Systems Model inspired information architecture
HelixForge uses a Viable Systems Model inspired subsystem vocabulary to describe what each architectural element does for the living system. These VSM-inspired functions should be used to classify capabilities, elements, relations, validation rules, and repository concerns.
Code context matters: the Stack dimension uses `S1` through `S5` as placement levels, while VSM also uses `System 1` through `System 5` as viable-system tags. Use OAD codes inside dimensional `placements`; use VSM mappings inside OAS `vsm\_tags`. The workbook abbreviations such as `OPS`, `SYN`, and `CTL` are vocabulary labels; they do not replace the OAS `vsm\_tags` enum. `ENV` describes boundary/environment concerns and should be represented through metadata or an explicit extension if it is used outside the current OAS enum.
|Code|Short|Name|Verb|Explanation|VSM mapping|
|-|-|-|-|-|-|
|OPS|Operations|Operations \& Activities|does|Do the primary work|System 1|
|SYN|Synchronization|Synchronization \& Coordination|aligns|Prevent friction, oscillation, and local conflict|System 2|
|CTL|Control|Internal Control \& Regulation|governs|Manage current performance, resources, priorities, and constraints|System 3|
|AUD|Audit|Audit \& Monitoring|verifies|Check what is really happening|System 3\*|
|INT|Intelligence|Intelligence \& Adaptation|scans|Sense the environment and future|System 4|
|POL|Policy|Policy \& Identity|defines|Define identity, values, and ultimate direction|System 5|
|ENV|Environment|Boundary \& Surface|interacts|Provides interfaces, adapters, sensors, and actors|Environment|
### 7.1 VSM usage intent
* **OPS** marks the operational work of software capabilities and runtime value delivery.
* **SYN** marks coordination mechanisms that reduce friction between capabilities, services, teams, or workflows.
* **CTL** marks internal control, resource regulation, policy enforcement, and current-state management.
* **AUD** marks observability, monitoring, evidence collection, and independent checking.
* **INT** marks sensing, forecasting, learning, reasoning, adaptation, and future-state exploration.
* **POL** marks identity, direction, governance, values, and ultimate constraints.
* **ENV** marks the boundary between HelixForge and users, external systems, markets, investors, builders, and real-world problem contexts.
## 8\. OAS model commitments
Architecture descriptions in `helix-forge` should be compatible with the Orthogonal Architecture Standard.
### 8.1 Architecture documents
An OAS architecture document should contain:
*`standard` — the constant `OrthogonalArchitectureStandard`;
*`version` — a semantic version string;
*`architecture.id` — a stable identifier;
*`architecture.name` — a human-readable architecture name;
*`architecture.description` — an explanation of architectural purpose;
*`architecture.dimensions` — the six Orthogonal Architecture Dimensions;
*`architecture.elements` — capability, service, platform, policy, automation, and intelligence elements;
*`architecture.relations` — typed relationships between elements;
*`architecture.principles` — architectural principles relevant to the model;
*`architecture.sources` — source references when applicable;
*`architecture.metadata` — tool and repository metadata.
### 8.2 Element types
OAS-compatible element types are:
```text
Capability
Service
Application
PlatformService
DataStore
ControlComponent
ManagementInterface
Integration
Policy
Automation
IntelligenceComponent
```
Every element must have a stable `id`, `name`, `type`, and at least one dimensional `placement`.
### 8.3 Relation types
OAS-compatible relation types are:
```text
realizes
depends\_on
composes
exposes
governs
observes
hosted\_on
isolated\_by
augmented\_by
```
Relations should be used to explain architectural meaning, not merely technical adjacency. In particular:
*`realizes` connects an implementation to a capability;
*`depends\_on` expresses operational or architectural dependency;
*`composes` expresses higher-order assembly;
*`exposes` expresses an available surface or interface;
*`governs` expresses control, policy, or regulation;
*`observes` expresses audit, telemetry, or monitoring;
*`hosted\_on` connects runtime elements to stack substrate;
*`isolated\_by` explains tenancy or separation;
*`augmented\_by` connects an element to intelligence support.
### 8.4 Placement intent
Placements should answer: **where does this element belong by architectural concern?**
A `Service` might be placed at `Logic/L2`, `Plane/P1`, `Stack/S5`, and `Capability/C3`. A `Capability` might be placed at `Logic/L1` and `Capability/C5`. A `ControlComponent` should be placed in `Plane/P2`. An `IntelligenceComponent` should be placed in `Intelligence/I1` through `I5` and governed according to its autonomy.
## 9\. Semantic validation posture
HelixForge should treat semantic validation as architecture hygiene. A document can be structurally valid and still architecturally weak; semantic validation closes that gap.
The repository should support two validation profiles:
* **Draft profile** — suitable for exploration, discovery, and early modeling. Warnings are allowed when intent is still forming.
* **Production profile** — suitable for published or operational models. Key warnings become errors.
### 9.1 Normative semantic rules
The OAS semantic rule profile should be treated as the baseline for architecture validation:
|Rule|Intent|
|-|-|
|R1|Every `Service` must include `Logic/L2` and `Plane/P1` placements.|
|R2|Every `Capability` must include `Logic/L1` and one of `Capability/C1`, `Capability/C4`, or `Capability/C5`.|
|R3|Every `ControlComponent` must include `Plane/P2`.|
|R4|Every `ManagementInterface` must include `Plane/P3`.|
|R5|Every `IntelligenceComponent` must include an `Intelligence/I1` through `I5` placement.|
|R6|Every `Service` or `Application` should realize at least one `Capability`; production models should require this.|
|R7|Every `Intelligence/I5` element must be governed through a path to a `ControlComponent`.|
|R8|Every `Service`, `Application`, and `PlatformService` should reference `Q2` observability; production models should require this.|
|R9|Every `ControlComponent`, `ManagementInterface`, and `IntelligenceComponent` must reference `Q1` and `Q7`.|
|R10|Every hostable runtime element should have a `Stack` placement or `hosted\_on` relation; production models should require this.|
|R11|A `realizes` relation must connect a `Service` or `Application` to a `Capability`.|
|R12|A `governs` relation must originate from a `ControlComponent` or `Policy` and target a governed element.|
|R13|An `augmented\_by` relation must point to an `IntelligenceComponent`.|
|R14|Duplicate placements with the same dimension and level are forbidden.|
|R15|`Intelligence/I4` and `Intelligence/I5` elements should link to a control, management, or policy element; production models should require this.|
|R16|Only control, management, or policy elements should be placed directly in `Plane/P2` or `Plane/P3`.|
### 9.2 Validator behavior
A HelixForge validator should process models in four phases:
1.**Structural validation** against the OAS JSON Schema.
2.**Semantic indexing** of elements, placements, relations, sources, targets, and quality requirements.
3.**Semantic checks** using the rule profile.
4.**Report output** containing errors, warnings, and informational findings.
Production validation should upgrade R6, R8, R10, and R15 from warnings to errors.
## 10\. AI and intelligence governance
HelixForge may use deterministic automation, language interaction, reasoning systems, assisted fitting, and agentic delegation. These are architectural elements, not magic exceptions.
Any AI-assisted component must be placed in the Intelligence dimension and governed according to its autonomy:
*`I1` deterministic automation may execute scripted or rule-based actions.
*`I2` language interaction may translate between users and system models.
*`I3` knowledge and reasoning may infer, classify, recommend, or explain.
*`I4` assisted fitting may propose or configure system changes under governance.
*`I5` agentic delegation may act autonomously only within explicit policy, control-plane, and audit boundaries.
AI must not bypass the control plane. Agentic behavior must be observable, policy-bound, reversible where possible, and traceable to capability intent.
## 11\. Design principles
1.**Capability first.** Capabilities are stable intent; services and applications are realizations.
2.**Discovery and delivery co-evolve.** Natural language understanding and formal implementation must inform each other continuously.
3.**Dimensions stay orthogonal.** Plane, Stack, Quality, Logic, Intelligence, and Capability describe different concerns and must not be collapsed into one hierarchy.
4.**Validation is part of design.** Schemas and semantic rules are design instruments, not after-the-fact checks.
5.**Governance before autonomy.** Intelligence components must operate through control, management, policy, and audit structures.
6.**Reuse over accumulation.** The repository should grow by strengthening composable capabilities, not by collecting disconnected artifacts.
7.**Evidence over assertion.** Runtime behavior, telemetry, tests, contracts, and validation reports should back claims of readiness.
8.**Environment matters.** Users, builders, investors, external systems, markets, and real-world problems are part of the viable system boundary.
9.**Security from inception.** Secret custody, tenant isolation, and workload identity are architectural commitments, not production afterthoughts. Capabilities that handle sensitive material should declare path ownership, policy scope, and delivery boundaries early.
|Platform secret custody|Defines how multi-tenant secret ownership, workload delivery, and operator custody align across HelixForge, NetKingdom, and Coulomb. See `docs/OpenBaoIntroduction.md`.|
