Document Control
| Attribute | Controlled value |
|---|
| Title | GAISSF™ v1.0 Reference Architecture |
| Document ID | GAISSF-IMP-013 |
| Purpose | Provide reusable architectural blueprints and security patterns for GAISSF implementation |
| Primary audience | Enterprise architects, security architects, AI architects, platform engineers, MLOps, DevSecOps, safety engineers, governance leads and assessors |
| Dependencies | GAISSF-NOR-001 through GAISSF-NOR-008 and GAISSF-IMP-009 through GAISSF-IMP-012 |
| Classification | Informative implementation guidance |
| Precedence | GAISSF-NOR-001 and GAISSF-NOR-004 prevail |
| Distribution | Public — Website and GitHub |
Legal and Reliance Notice
© 2026 ODA3 Pvt Ltd. Published market-facing by ODA3 Institute.
GAISSF™ is used as a framework mark. Third-party names and marks remain the property of their respective owners.
The reference designs are illustrative and shall be adapted to system context, threat model, sector, jurisdiction and safety requirements.
Use of this architecture does not establish GAISSF conformance, certification eligibility, legal compliance or system safety.
Foreword
A reference architecture helps organizations implement GAISSF consistently without prescribing a single technology stack. The designs in this document organize control placement, trust boundaries, telemetry, evidence, human oversight and fail-safe behavior across common AI deployment models.
1. Purpose and Scope
This document defines reusable architectural patterns for enterprise AI services, generative-AI applications, retrieval-augmented generation, agentic systems, externally hosted model services, private-model platforms, edge deployments and physical-AI systems.
The patterns are implementation-independent. Organizations should select, combine and tailor them based on system criticality, autonomy, data sensitivity, supplier dependence, deployment model and applicable safety obligations.
2. Architecture Principles
| Principle | Architectural implication |
|---|
| Explicit trust boundaries | Every transition between users, applications, models, tools, data, suppliers and physical actions is identified and controlled. |
| Least privilege by capability | Permissions are scoped to models, tools, actions, data, memory and environments—not only user identities. |
| Separation of control and data planes | Governance, policy and approval functions are separated from operational data and inference flows. |
| Evidence by design | Architecture generates attributable logs, decisions, tests and state records required for assurance. |
| Fail securely and safely | Failures produce contained, observable and recoverable states; physical systems enter a defined safe state. |
| Human authority for consequential actions | High-impact actions require approval, review, override or escalation appropriate to risk. |
| Versioned and reproducible components | Models, data, prompts, policies, tools and configurations are identifiable and recoverable. |
| Supplier boundaries remain visible | Inherited controls and external dependencies are represented explicitly rather than treated as internal. |
| Monitoring is independent where feasible | Critical telemetry and control-health verification are not solely dependent on the component being monitored. |
3. Logical Reference Architecture
3.1 Layered architecture
| Governance and Assurance Plane
Inventory • risk • policy • exceptions • approvals • evidence • audit • certification records |
|---|
| Security and Policy Enforcement Plane
Identity • authorization • AI gateway • policy engine • content controls • transaction approval |
| Experience and Channel Layer
Web • mobile • API • chat • voice • operator console • embedded interface |
| Application and Orchestration Layer
Business logic • prompt orchestration • agents • memory • tool routing • workflow state |
| Model Service Layer
Model routing • inference endpoints • local models • hosted models • evaluation wrappers |
| Data and Knowledge Layer
Training data • retrieval stores • vector databases • feature stores • operational records |
| Platform and Infrastructure Layer
Cloud • containers • networks • secrets • endpoints • accelerators • edge compute |
| Physical Actuation and Environment Layer
Robotics • vehicles • machinery • sensors • actuators • human environment |
3.2 Cross-cutting services
| Service | Purpose | Evidence generated |
|---|
| Identity and access | Authenticate users, services, agents, tools and administrators | Access decisions, role changes, privileged sessions |
| Policy decision point | Evaluate contextual policy before model, data or tool use | Policy version and decision log |
| Telemetry pipeline | Collect security, behavior, safety and control-health events | Immutable or protected event records |
| Configuration registry | Maintain approved model, prompt, tool and policy versions | Release and change history |
| Evidence service | Index and protect artifacts linked to GAISSF controls | Manifest, hashes, signatures and custody records |
| Evaluation service | Run regression, adversarial, safety and performance tests | Evaluation reports and failed-result records |
| Incident integration | Create, route and track AI-related incidents and near misses | Tickets, timelines and corrective actions |
4. Security Zones and Trust Boundaries
| Zone | Typical components | Required boundary controls |
|---|
| Z0 — Public/untrusted | Internet users, public data, external prompts and files | Input validation, rate limiting, abuse detection and isolation |
| Z1 — User interaction | Authenticated users, channels and operator consoles | Identity, session control, disclosure and user-level policy |
| Z2 — Application | Business logic, APIs, orchestration and workflow state | Service identity, authorization, secure coding and transaction control |
| Z3 — AI mediation | AI gateway, prompt policy, model router and output controls | Policy enforcement, model allowlists, logging and content safeguards |
| Z4 — Model execution | Hosted or private inference endpoints | Model identity, version pinning, network restriction and monitoring |
| Z5 — Data and memory | Vector stores, datasets, memory, logs and feature stores | Data classification, access, lineage, poisoning controls and retention |
| Z6 — Tool/action | Plugins, enterprise APIs, code execution and external actions | Per-tool permissions, approval, sandboxing and rollback |
| Z7 — Assurance | Test harnesses, evidence repositories and monitoring systems | Independence, integrity, restricted write access and traceability |
| Z8 — Physical control | Sensors, controllers, actuators and safety systems | Command authentication, safety interlocks, fail-safe and override |
5. Core Data Flows
| Flow | Architecture controls |
|---|
| User input to application | Authentication, validation, malware scanning, rate limits and purpose constraints |
| Application to model | Prompt policy, context minimization, model routing, version pinning and request logging |
| Application to retrieval | Query authorization, tenant isolation, data classification and provenance filters |
| Model output to user | Output validation, content safety, disclosure, confidence/limitation handling and logging |
| Agent to tool | Capability authorization, parameter constraints, transaction approval and action recording |
| System to supplier model | Encrypted transport, data-use restrictions, provider controls and response validation |
| Telemetry to assurance plane | Protected transport, timestamping, integrity and access segregation |
| AI decision to physical actuator | Deterministic safety gate, command authentication, bounds checking and safe-state logic |
6. Pattern A — Enterprise AI Gateway
6.1 Blueprint
| User and Application Channels
Approved clients and service identities |
|---|
| Enterprise AI Gateway
Authentication • rate limits • prompt policy • model allowlist • logging |
| Safety and Security Services
Input scanning • DLP • content safety • abuse detection • policy decisions |
| Model Router
Selects approved private or external model endpoints |
| Model Providers
Private models • cloud models • specialized models |
| Evidence and Monitoring
Requests • policy decisions • model versions • outputs • incidents |
6.2 Suitable use
Centralized control of multiple AI applications and model providers, particularly where organizations need consistent policy, logging, supplier control and evidence.
6.3 Key risks and controls
| Risk | Architectural control |
|---|
| Gateway becomes single point of failure | High availability, graceful degradation and bypass prevention |
| Sensitive context reaches external model | Data classification, redaction, routing rules and contractual restrictions |
| Model substitution | Provider and model allowlists with cryptographic or registry verification |
| Policy drift | Versioned policy deployment and independent conformance checks |
| Incomplete application coverage | Network and identity controls preventing direct unsanctioned model access |
7. Pattern B — Retrieval-Augmented Generation
7.1 Blueprint
| Authenticated User
Identity, role and purpose context |
|---|
| RAG Application
Query handling, context assembly and response workflow |
| Retrieval Policy Layer
Authorization, tenant isolation, source filtering and relevance constraints |
| Knowledge Stores
Approved documents, vector indexes and source metadata |
| Model Service
Inference using bounded retrieved context |
| Citation and Output Layer
Source attribution, content controls and user disclosure |
| Evidence Layer
Query, sources, model version, output and user feedback |
7.2 Key controls
| Concern | Pattern control |
|---|
| Unauthorized retrieval | Document-level and attribute-based access controls before retrieval |
| Poisoned knowledge | Source approval, integrity checks, lineage and change review |
| Cross-tenant leakage | Separate indexes or enforced tenant filters with negative testing |
| Unsupported answer | Citation requirement, confidence handling and abstention behavior |
| Stale knowledge | Freshness metadata, expiry and re-index controls |
| Prompt injection in documents | Content scanning, instruction isolation and tool-policy enforcement |
10. Pattern E — External Model Service
| Boundary concern | Reference control pattern |
|---|
| Provider identity and service version | Approved provider registry, endpoint verification and contract record |
| Data disclosure | Pre-send classification, minimization, redaction and routing |
| Provider change | Contractual notification, behavioral monitoring and fallback |
| Availability | Multi-provider routing, queueing, degradation or approved outage behavior |
| Response integrity | Schema validation, content controls and anomaly detection |
| Evidence limitations | Record unavailable provider internals and inherited-control assumptions |
| Exit strategy | Portable prompts, test suites, data and alternate endpoint capability |
11. Pattern F — Edge and Offline AI
| Architecture area | Reference design |
|---|
| Model package | Signed, versioned and verified before activation |
| Local data | Encrypted storage, minimization and controlled synchronization |
| Policy | Locally enforceable controls when central services are unavailable |
| Telemetry | Buffered, integrity-protected events with later synchronization |
| Update | Authenticated, rollback-capable and staged software/model update |
| Degraded operation | Documented behavior during network, sensor or service loss |
| Physical access | Tamper resistance, secure boot and maintenance authentication |
12. Pattern G — Physical AI Safety Architecture
12.1 Blueprint
| Mission/Application Layer
Requested goals and operational tasks |
|---|
| AI Decision Layer
Perception, planning and learned control |
| Deterministic Safety Supervisor
Independent limits, collision rules and operational envelope |
| Command Authentication Layer
Authorized, bounded and rate-limited actuation commands |
| Low-Level Controller
Deterministic control and actuator feedback |
| Sensors and Actuators
Validated sensing, calibration, fault detection and actuation |
| Human Override and Emergency Stop
Independent, accessible and regularly tested |
| Safety Evidence
Simulation • HIL • event telemetry • override tests • incident reconstruction |
12.2 Safety separation
Where practicable, critical safety constraints should be enforced by a deterministic or independently assured supervisor that does not rely solely on the same learned component whose behavior it constrains.
| Failure scenario | Architectural response |
|---|
| Loss of model confidence | Reduce capability, request human control or enter safe state |
| Sensor inconsistency | Fault detection, sensor voting and restricted operation |
| Unsafe planned action | Independent safety supervisor blocks command |
| Communication loss | Local safe-state logic |
| Unauthorized command | Authentication failure and command rejection |
| Override failure | Redundant independent emergency-stop path |
13. Governance and Assurance Plane
| Capability | Architecture component | Control outcome |
|---|
| Inventory | System/model/data/tool registry | Complete and current scope |
| Risk | Risk and impact register | Documented treatment and ownership |
| Policy | Versioned policy repository and decision engine | Consistent enforcement |
| Exceptions | Time-bound exception workflow | Visible residual risk |
| Evidence | Protected evidence repository | Traceable and reviewable operation |
| Testing | Independent evaluation and VTS integration | Repeatable assurance |
| Change | Release and impact-management service | Controlled architecture evolution |
| Certification | Scope, findings and claim-management records | Accurate external representation |
14. Observability and Evidence Architecture
| Event category | Minimum attributes |
|---|
| Identity | Actor, agent, service, role and authentication context |
| Request | Time, system, purpose, channel and data classification |
| Policy decision | Policy version, decision, reason and obligations |
| Model invocation | Provider, model/version, configuration and latency |
| Retrieval | Sources, permissions, index version and result identifiers |
| Agent action | Plan step, tool, parameters, approval and outcome |
| Output | Response identifier, controls applied and delivery channel |
| Safety event | Hazard, sensor state, command, block, override and safe state |
| Change | Component, old/new version, approver and release |
| Evidence integrity | Hash, signature, timestamp and repository location |
15. Resilience and Recovery Patterns
| Failure | Resilience pattern |
|---|
| Model endpoint outage | Fallback model, queue, user notification or controlled service degradation |
| Policy service outage | Fail closed for high-risk actions; cached signed policy for approved low-risk use |
| Retrieval outage | Abstain or use clearly identified reduced-function mode |
| Monitoring outage | Pause expansion, restrict consequential actions or revert |
| Supplier behavior change | Canary comparison, anomaly detection and provider switch |
| Data corruption | Integrity verification, restore and re-index from approved sources |
| Agent runaway | Step limit, circuit breaker, credential revocation and state rollback |
| Physical control failure | Independent safe state, emergency stop and incident evidence |
16. Architecture Decision Records
Material architecture decisions should be documented using an Architecture Decision Record (ADR).
| ADR field | Required content |
|---|
| Decision ID | Unique identifier |
| Context | System, risk and constraints |
| Decision | Selected architecture or pattern |
| Alternatives | Options considered |
| Rationale | Why the decision was selected |
| GAISSF controls | Affected control IDs |
| Assumptions | Supplier, data, user and operating assumptions |
| Consequences | Benefits, limitations and new risks |
| Evidence | Design review and approval artifacts |
| Review trigger | Events requiring reconsideration |
17. Architecture Review Method
- Confirm system purpose, users, affected persons and consequence level.
- Map components, data flows and trust boundaries.
- Identify applicable GAISSF controls and sector obligations.
- Review identity, authorization, policy and human-oversight placement.
- Review model, data, agent, supplier and physical-safety boundaries.
- Evaluate failure, containment, rollback and safe-state behavior.
- Confirm telemetry, evidence and incident reconstruction capability.
- Record gaps, assumptions and approved decisions.
18. Reference Architecture Selection Guide
| System characteristic | Recommended starting pattern |
|---|
| Many applications and providers | Enterprise AI Gateway |
| Knowledge-grounded assistant | Retrieval-Augmented Generation |
| Autonomous or multi-step tool use | Agentic AI with Tool Use |
| Organization trains or hosts models | Private Model Platform |
| Predominantly third-party model APIs | External Model Service |
| Intermittent connectivity or embedded device | Edge and Offline AI |
| Robotics, vehicles, machinery or actuators | Physical AI Safety Architecture |
19. Architecture Anti-Patterns
| Anti-pattern | Risk | Corrective pattern |
|---|
| Direct application-to-model access | Policy bypass and fragmented evidence | Mediated gateway or controlled service layer |
| Shared unrestricted agent credentials | Unbounded and unattributable actions | Per-agent identity and capability authorization |
| Retrieval authorization after search | Unauthorized content may enter context | Authorize before retrieval |
| Logging only user prompts | Insufficient reconstruction | Log policy, model, sources, tools, state and outcomes |
| Safety logic inside learned model only | Common-mode failure | Independent deterministic safety supervisor |
| Unversioned prompts and policies | Non-reproducible behavior | Controlled configuration registry |
| Provider treated as internal trust zone | Inherited risks become invisible | Explicit supplier boundary |
| Monitoring with unrestricted write access | Evidence tampering risk | Segregated assurance plane |
20. Limitations
- The patterns do not represent every valid architecture.
- A reference pattern does not determine the applicability of individual controls.
- The diagrams are logical and do not define network topology or product configuration.
- Sector safety standards may require architectures not shown here.
- Architecture alone does not demonstrate operating effectiveness.
21. Notably Absent
- No mandated vendor, cloud provider, model or product.
- No assumption that centralized architecture is always preferable.
- No universal requirement to retain full prompt or output content where privacy or law prohibits it.
- No claim that an AI gateway alone establishes GAISSF conformance.
- No substitution for specialist safety architecture in physical AI.
- No guarantee that architectural controls eliminate emergent behavior or unknown threats.
Annex A — Architecture Inventory Template
| Field | Entry |
|---|
| System name | |
| Purpose | |
| Owner | |
| Users | |
| Model services | |
| Data stores | |
| Agents and tools | |
| Suppliers | |
| Trust boundaries | |
| Physical interfaces | |
| Monitoring | |
| Evidence repository | |
| Applicable controls | |
Annex B — Trust Boundary Record
| Boundary ID | Source zone | Destination zone | Assets | Threats | Controls | Telemetry | Owner |
|---|
| | | | | | | |
| | | | | | | |
| | | | | | | |
Annex C — Architecture Decision Record Template
| Field | Entry |
|---|
| Decision ID | |
| Title | |
| Context | |
| Decision | |
| Alternatives | |
| Rationale | |
| GAISSF controls | |
| Assumptions | |
| Consequences | |
| Evidence | |
| Approval | |
| Review trigger | |
Annex D — Architecture Review Checklist
☐ Scope and component inventory complete
☐ Trust boundaries documented
☐ Model and provider versions controlled
☐ Data lineage and access enforced
☐ Agent and tool permissions bounded
☐ Human approval and override defined
☐ Failure and rollback paths tested
☐ Physical safe state defined where applicable
☐ Telemetry supports incident reconstruction
☐ Evidence repository protected
☐ Supplier boundaries and assumptions recorded
☐ Architecture decisions approved
Annex E — Source Traceability
| Architecture subject | Controlled source |
|---|
| Normative requirements | GAISSF-NOR-001 |
| Control records | GAISSF-NOR-004 |
| Terminology | GAISSF-NOR-005 |
| References | GAISSF-NOR-006 |
| Release and decisions | GAISSF-NOR-007 and GAISSF-NOR-008 |
| Adoption planning | GAISSF-IMP-009 |
| Operational workflows and evidence | GAISSF-IMP-010 |
| Deployment and rollback | GAISSF-IMP-011 |
| Migration and crosswalk treatment | GAISSF-IMP-012 |
Annex F — Publication Record
| Version | Date | Change | Status |
|---|
| 1.0 | 29 June 2026 | Initial reference architecture for GAISSF v1.0 | Final Publication v1.0 |
Controlled Profile Reconciliation Notice
The Foundational profile comprises 52 controls across all nine domains, as enumerated in the controlled conformance profile. Seven controls are excluded from that profile; the exclusions are not equivalent to excluding the D9 domain.
Any earlier wording that described the Foundational profile as D1-D8 only or treated the entire D9 domain as excluded is superseded by this statement and the controlled conformance profile.
Architecture Control Catalogue
| Control plane | Required capabilities | Failure considerations |
|---|
| Identity | User, service, agent and administrator identity; strong authentication | Credential theft, shared identity, orphaned access |
| Authorization | Contextual policy for model, data, tool and transaction | Privilege escalation, policy bypass |
| AI mediation | Input, model routing, output and usage policy | Direct endpoint bypass, policy drift |
| Data protection | Classification, lineage, access, retention and leakage prevention | Poisoning, unauthorized retrieval, cross-tenant leakage |
| Execution isolation | Sandboxing, network restrictions and resource limits | Escape, lateral movement, uncontrolled code |
| Safety | Independent constraints, override and safe state | Common-mode failure, unavailable override |
| Observability | Protected logs, traces, state and decisions | Blind spots, tampering, missing context |
| Resilience | Fallback, degradation, rollback and continuity | Unsafe fallback, stale recovery state |
Deployment Topology Variants
| Topology | Advantages | Risks and controls |
|---|
| Centralized gateway | Consistent policy and evidence | Concentration risk; require HA and bypass prevention |
| Federated gateways | Local autonomy and jurisdiction fit | Policy drift; require common standards and assurance |
| Private isolated platform | Data and model control | Operational complexity; require specialist competence |
| Managed external service | Speed and scalability | Supplier opacity; require contracts, monitoring and exit |
| Edge/embedded | Low latency and offline operation | Update, physical access and telemetry constraints |
| Hybrid physical AI | Integrated decision and actuation | Safety separation and deterministic supervisor required |
Threat Modelling Procedure
- Define assets, users, affected persons and unacceptable outcomes.
- Map components, data flows, trust boundaries and suppliers.
- Identify misuse, attack, failure and hazard scenarios.
- Place preventive, detective, corrective and recovery controls.
- Define evidence and monitoring for each material scenario.
- Review after material change and incident.
Nonfunctional Requirements
| Quality | Architecture requirement |
|---|
| Security | Least privilege, isolation, integrity and attack resistance |
| Safety | Bounded behavior, independent constraints and safe state |
| Privacy | Minimization, separation, retention and user rights |
| Reliability | Defined availability, error handling and recovery |
| Observability | Attributable and protected decision/event records |
| Portability | Controlled exit from suppliers and model substitution |
| Maintainability | Versioned components, automated tests and documented dependencies |
Sample Architecture Review Findings
| Finding | Risk | Recommended treatment |
|---|
| Applications call provider directly | Policy and evidence bypass | Route through approved mediation or enforce endpoint policy |
| Agent uses shared admin token | Unbounded actions and poor attribution | Issue scoped per-agent credentials |
| RAG filter applied after retrieval | Unauthorized data enters context | Authorize before retrieval |
| Safety override depends on AI controller | Common-mode failure | Implement independent override path |
| Monitoring logs are editable by operators | Evidence tampering | Use segregated protected telemetry store |
Publication Completeness and Intended Use
This full publication edition of GAISSF-IMP-013 is designed to stand on its own for its stated role: comprehensive implementation-independent architecture blueprint. It includes purpose, scope, governance, operating guidance, evidence expectations, limitations, decision criteria and reusable records appropriate to that role.
Completeness does not mean that the document replaces the normative control statements, applicable law, sector-specific engineering, organizational procedures or professional judgement. Cross-referenced GAISSF documents remain part of the controlled document system.
| Completeness dimension | Treatment in this edition |
|---|
| Normative alignment | Reconciled to the authoritative 59-control baseline and controlled profile structure. |
| Operational usability | Includes roles, workflows, gates, evidence, metrics, escalation and examples where relevant. |
| Traceability | Identifies dependencies and preserves the distinction between requirements, guidance and examples. |
| Limitations | States what the document does not establish or guarantee. |
| Maintenance | Includes review triggers, change control and publication status. |
Legal and Regulatory Integration
GAISSF provides an operational security, safety, governance and evidence framework. It does not determine which laws apply, establish statutory compliance, create a legal safe harbour, define a legal standard of care, replace competent legal advice, or guarantee that evidence collected for GAISSF purposes will satisfy a regulator, court or other authority. Organizations should maintain a jurisdiction-specific legal and regulatory obligations register and map applicable obligations to their GAISSF scope, controls, evidence, reporting processes and decision authorities.
Legal and regulatory interface requirements
- Identify applicable jurisdictions, regulators, sector rules, contractual duties and internal legal authorities before relying on this guide.
- Maintain a controlled obligations register, reporting-clock register, retention schedule, legal-hold process and conflicts-of-obligation procedure.
- Treat statutory, regulatory and contractual analysis as a parallel workstream to GAISSF implementation and assurance.
- Record the legal basis, responsible owner, scope, decision, evidence, deadline and review date for each material obligation.
- Do not represent GAISSF conformance, maturity or certification as legal approval, permission to operate, immunity from enforcement or proof that harm cannot occur.
How to use this document
| Reader | Recommended use |
|---|
| Executive or board reader | Review purpose, decision rights, legal and regulatory integration, limitations and Notably Absent sections. |
| Program or control owner | Use workflows, templates, gates, evidence fields and escalation criteria as implementation aids. |
| Engineering or operations team | Translate guidance into system-specific procedures, configurations, runbooks and testable acceptance criteria. |
| Legal, privacy or compliance team | Validate jurisdiction-specific obligations, deadlines, retention, disclosure, privilege and regulator-facing requirements. |
| Assessor or auditor | Use the document as informative context only; test claims against the authoritative normative sources and applicable assessment criteria. |
See Also
- GAISSF-IMP-010 for implementation workflows.
- GAISSF-IMP-011 for deployment.
- GAISSF-IMP-017 for evidence architecture.
Architecture-specific regulatory enhancements
Data residency and cross-border transfer control pattern
| Control point | Architectural capability |
|---|
| Classification | Data category, subject, jurisdiction and restriction attributes. |
| Policy | Approved processing regions, transfer mechanisms and supplier locations. |
| Routing | Region-aware allow, deny, redact, tokenize or local-process decisions. |
| Key custody | Region-appropriate encryption and controlled key access. |
| Telemetry | Regional stores, minimized fields and controlled cross-region aggregation. |
| Support access | Time-bound, approved and logged cross-border administrative access. |
| Evidence | Transfer decision, policy version, destination, legal basis and exception record. |
The architecture shall enforce the organization’s approved transfer policy. It shall not assume that every transfer to a non-adequate jurisdiction is prohibited or that one jurisdiction’s localization rule applies universally.
Deterministic legal-policy gateway
Consequential agentic and physical actions should pass through an auditable policy decision point capable of deny, allow, require approval, restrict data, substitute a permitted route, log and escalate, or place the system in a safe state.
Decision-record and explanation telemetry
| Record element | Content |
|---|
| Identity | System, model, policy, tool and transaction identifiers. |
| Context | Input, relevant retrieved sources and approved context. |
| Decision basis | Material rules, factors, reason codes or explanation artifact where appropriate. |
| Action | Output, tool call, physical command and downstream effect. |
| Human involvement | Review, override, approval and escalation. |
| Limitations | Confidence, unavailable telemetry, protected fields and withholding rationale. |
| Integrity | Timestamp, provenance, version linkage and tamper evidence. |
Threat model and technology categories
Threat modelling may use STRIDE, PASTA or another documented method appropriate to the system. The minimum record should include component, asset, threat, attack or failure path, consequence, control, evidence, owner and residual risk. Technology examples shall remain illustrative and non-endorsing.
Notably Absent — legal and regulatory boundary
- No universal prohibition on all cross-border data transfers.
- No requirement to expose raw model internals where a meaningful and lawful decision record can be provided by other means.
- No claim that a logical architecture or named technology establishes conformance.
Publication revision record
| Revision | Disposition |
|---|
| R2 — Regulatory and practitioner refinement | Added legal and regulatory integration, preservation, reporting, decision-record, public-claim and usability guidance. No normative GAISSF control was added, removed, renamed or amended. |
| Authority boundary | GAISSF-NOR-001, GAISSF-NOR-004 and controlled profile records remain authoritative. |
