Trust & Service Architecture
Public ingress, private operations, identity policy, workload roles, operational state, and configuration management.
Architecture Library
The system behind the systems.
This overview shows how TekForge separates public access, private operations, identity policy, service workloads, structured operational state, and configuration management. Workloads span virtualized and dedicated hosts, with isolation chosen by trust boundary and operational role. It focuses on the engineering decisions that make the environment understandable and supportable.
Architecture map
The current model shows the trust boundaries, workload roles, and operating layers that shape the environment.
Trust & Service Architecture
How public exposure, private operations, workload isolation, operational state, and configuration management fit together.
Access
Deliberately exposed services operate through controlled public edges.
Authorized users reach protected work through private access and policy.
Trust & policy
Trust zones and identity policy separate management, service, trusted-client, and untrusted workloads.
Workloads
Applications and services span virtualized and dedicated hosts according to operational role.
Internal, data, and support workloads are separated where lifecycle or recovery needs justify it.
Operating platforms
Local-first operational platform with shared authority and validated multi-device synchronization.
Intelligence and orchestration layer built above Norn, local models, and controlled tools.
Foundations
Repeatable configuration and policy enforcement.
Durable storage, recovery orchestration, and security observability remain distinct capabilities.
Trust boundaries
Access is separated before protected workload decisions are made.
Current capability
Norn is production-capable; SKALD and configuration management are active work.
Planned capability
Storage, recovery, and observability mature independently as requirements justify them.
What the diagram communicates
The model emphasizes explicit trust, controlled access, separated responsibilities, and an honest distinction between current capability and planned work.
Trust is explicit
- Public exposure is intentional and constrained
- Private operations remain separate from public service paths
- Network segmentation limits what each trust zone can reach
Workloads follow the requirement
- Isolation follows trust boundary and operational role, not a mandatory symmetric topology
- Virtualized and dedicated hosts coexist where each is appropriate
- Configuration, storage, recovery, and observability are distinct operational concerns
Supporting design records
The diagrams are the overview. These writeups capture the judgment, operating principles, and failure-response thinking underneath them.
Identity-first foundations
Why identity, boundaries, and attribution are treated as architecture rather than application settings.
Read the design note →Defaults and workarounds
How temporary access paths and setup choices quietly become policy when environments stop revisiting them.
Read the article →Incident response as an operating pattern
A practical response model built around containment, evidence, recovery, and documented decisions.
Read the SOP →