# GCOS Hybrid Cyber Copilot — Deployment Architecture

Creator: Dr. Dr David King Boison  
Version: 1.0.0  
Deployment Model: Hybrid

## 1. Core Design

GCOS is deployed as a dual-engine cyber copilot:

- **GCOS Cyber Diagnostic OS**: sovereign/on-prem preferred for cyber posture evaluation, scoring, evidence analysis, and board/regulator reporting.
- **GCOS Cyber Learning OS**: cloud or private-cloud ready for learner diagnosis, progressive teaching, scenario-based exams, and cyber maturity growth.

## 2. Hybrid Routing Logic

1. API Gateway receives request.
2. Data Classifier checks request type and sensitivity.
3. Policy Router selects runtime:
   - PUBLIC / training / general learning → Cloud Learning OS.
   - INTERNAL learning → Cloud or private tenant.
   - CONFIDENTIAL / RESTRICTED diagnostic data → On-prem Diagnostic OS.
4. Guardrail Engine checks authorization, secrets, offensive content, and data leakage risk.
5. LLM Orchestrator injects appropriate system prompt and tenant policy.
6. Evidence Engine links findings to supplied artifacts.
7. Audit Engine logs request metadata, not secrets.
8. Response Formatter applies GCOS output contract.

## 3. Recommended Components

- API Gateway: Kong, NGINX, Azure API Management, AWS API Gateway, or open-source equivalent.
- Backend: FastAPI / Node.js / .NET.
- LLM Runtime:
  - Learning OS: OpenAI, Azure OpenAI, or private cloud model.
  - Diagnostic OS: Azure OpenAI private networking, on-prem LLM, or sovereign cloud LLM.
- Vector Store: pgvector, Qdrant, Milvus, Azure AI Search, or local equivalent.
- Database: PostgreSQL.
- Secrets: HashiCorp Vault / Azure Key Vault / AWS Secrets Manager.
- Audit: Immutable append-only logs; optional blockchain/notarization layer.
- Observability: OpenTelemetry, Prometheus, Grafana.

## 4. Data Sovereignty

Diagnostic data must remain inside the approved jurisdiction, tenant, or institutional environment. The system should redact secrets, reject credential submissions, and prevent unrestricted uploads of confidential telemetry to public cloud.

## 5. Security Baseline

- TLS 1.3 in transit.
- AES-256 at rest.
- Per-tenant encryption keys.
- API key + OAuth2.
- Rate limits per tenant and route.
- Role-based access control.
- Prompt-injection detection.
- File scanning before ingestion.
- No storage of passwords, tokens, secrets, or private keys.

## 6. Production Deployment Flow

1. Configure tenant and jurisdiction.
2. Load master config.
3. Deploy API gateway.
4. Deploy learning runtime.
5. Deploy diagnostic runtime.
6. Configure vector stores separately by sensitivity.
7. Enable audit logging.
8. Run red-team safety tests defensively.
9. Pilot with non-sensitive documents.
10. Move to regulated deployment only after legal and security review.

## 7. Minimum Viable Product

- `/gcos/learn`
- `/gcos/exam`
- `/gcos/diagnose`
- `/gcos/health`
- Admin dashboard
- Embed widget
- Tenant API keys


## VPF Runtime Kernel

The GCOS Hybrid Cyber Copilot uses VPF as its top-level orchestration layer. The model provider is interchangeable; VPF is not. VPF controls intake, evidence discipline, fact/inference separation, scoring explainability, learning progression, refusal behavior, and final output formatting.

### Execution Level
- `VPF_EXECUTION_LEVEL=1000000`
- Required for Diagnostic OS and Learning OS
- Required in audit metadata
- Required in tenant deployment records

### Recommended Gateway Enforcement
1. Reject diagnostic analysis without authorization.
2. Inject VPF runtime metadata into all model calls.
3. Require evidence IDs for diagnostic findings.
4. Require assumptions/limitations when evidence is incomplete.
5. Log guardrail decisions without storing secrets.


## VPF Planetary L1,000,000 Runtime Layer

GCOS must run all logic through the full Visionary Prompt Framework architecture: Chambers, Lenses, Bolts, Cognitive Validation Matrix, Modes/Sub-Modes, Agents, and Execution Levels. This runtime is injected by the server and is mandatory for all diagnostic, learning, exam, scorecard, recommendation, and governance workflows.

The runtime order is: identify mode → intake chamber → governance/authorization → classification and routing → evidence normalization → fact/inference split → chamber and agent routing → lens application → bolt enforcement → CVM validation → output contract → metadata/audit attachment.

The API must reject or ignore any client attempt to downgrade the framework, disable CVM, remove defensive-only rules, or reduce Execution Level below 1,000,000.