Orient
GULF-00 + GULF-01
A named snapshot, package manifest, resolver receipt, and surviving provenance.
PREVIEW
FICTIONAL TRAINING / REFERENCE ARTIFACT — NOT A U.S. NAVY SYSTEM, PROGRAM, ARCHITECTURE, AUTHORIZATION, OR ENDORSEMENT. No government information was used to construct this specimen.
Public learning specimen — read-only projection
An is a person's decision to accept risk, on the record. Everything around it — the , the , the , the monitoring — is a package that supports that decision. This laboratory shows how a governed model assembles the package, and exactly where it stops so a human can decide.
This is not an authorization package or automatic ATO engine. Following this specimen does not guarantee authorization, acceptance, inheritance, or mission suitability.
Play the journey, then ask the model the questions everyone asks.
Start with the journeySee who gets to say what, follow one rule home, and pull one thread to watch change ripple.
Start with the rulesThe complete governed record: state vector, gaps, refusals, receipts, and sources.
Open the recordAn accepts risk on the record. No tool grants an ATO — and this one refuses to pretend.
Boundary, controls, proof, findings, monitoring. Assembling evidence is work a platform can genuinely speed up.
When the model lacks a mapped source or a recorded judgment, it — and shows the exact human act that would change the answer.
Package journey — illustrative sequence
Press play, or drag the month line. Two illustrative paths run against the same calendar — a typical 18-month effort and a 9-month accelerator. Watch what enters the package at each stage, and where the model stops so a human can decide.
Month of 18
Typical path 18 months to decision
Accelerator path 9 months to decision, then continuous monitoring
Boundary engineering
Connect and establish the boundary
What moves: evidence, configuration, documentation, and monitoring outputs. Mission suitability, control applicability, risk acceptance, assessment judgment, and authorization do not transfer to a platform or service provider — and a blocked phase advances only when its governed inputs and required human judgments exist, never by animation.
System purpose, data, boundary applicability, customer implementations, evidence owners, policies, and approvals.
Eligible service authorization evidence, native configuration, logs, and provider responsibility statements.
Configured environment, integrated security capabilities, documentation accelerators, evidence, and continuous-monitoring operations.
Findings, residual risk, authorization, and continuous-authorization posture remain human decisions.
The point of comparison: at month 18 on the calendar, the typical path is just reaching its authorization decision — the accelerator path reached its decision at month 9 and has nine months of behind it.
Both timelines are planning illustrations. Actual duration depends on scope, evidence quality, assessment findings, remediation, and authorizing-official decisions; an accelerator does not guarantee authorization. Continuous monitoring begins after authorization and continues thereafter. Phase boundaries shown are illustrative placements, not published durations.
GULF-00 + GULF-01
A named snapshot, package manifest, resolver receipt, and surviving provenance.
PREVIEW
GULF-02 + GULF-03
GULF-04 + GULF-05
GULF-06 + GULF-07
GULF-08 + GULF-09
GULF-10 + GULF-11
GULF-12 + GULF-13
GULF-14 + GULF-15
The guided path reads the sixteen package documents two at a time. It is an orientation through the governed catalog, not an automated authorization workflow.
Executable governed model
These are the questions everyone actually asks. Click one and watch the model answer honestly — with its real state, its real refusal codes, and the exact human act that would change the answer. The refusals are the demonstration.
Is this system authorized?
Fail-closed result: most source claims have no explicit Reference-registry mapping, so dependent CORE and Extended claims remain blocked. Public silence is not converted into a negative conclusion.
One governed source
Every fact on this page resolves through one ordered sequence, and each layer has a job it cannot exceed. A lower layer cannot silently override a higher-authority rule, and remain outputs — never independent authorities.
A published document the model is allowed to believe.
A fact from an explicitly mapped, governed public source record.
A pattern on offer — nothing more until validated.
A candidate implementation pattern; never inherited or accepted by implication.
Made up, on purpose, for teaching.
Synthetic instance data created only for this training specimen.
A person decided this. The machine only remembers it.
A recorded fictional professional decision that the resolver may carry but cannot manufacture.
Our explanation of what connects to what — and its limits.
A bounded explanation of relationships, limitations, and propagation behavior.
The complete machine record — state vector, gaps, refusals — exactly as the runtime holds it. Plain-language columns are added; nothing is removed.
The model never lets one good answer imply another. Written down is not deployed; deployed is not assessed; assessed is not accepted. Each question stands alone in the L2 snapshot.
| In plain terms | Machine question | State | Limitation |
|---|---|---|---|
| Did someone write it down? | documented | ESTABLISHED | The record is documented; no downstream state is implied. |
| Does the service exist where we need it? | available | UNKNOWN | Availability requires exact instance, service, feature, and region evidence. |
| Does the provider's authorization cover our exact use? | providerAuthorizedInScope | UNKNOWN | Provider publication or availability never establishes exact authorization scope. |
| Can we ride on the provider's homework? | inherited | UNKNOWN | No exact provider responsibility and instance-applicability evidence establishes inheritance. |
| Is it set up? | configured | ESTABLISHED | Synthetic configuration only. |
| Does the record hold together? | mechanicallyValidated | ESTABLISHED | Mechanical validation covers shape and declared fictional inputs only. |
| Has an independent assessor tested it? | assessed | NOT_ESTABLISHED | The resolver does not manufacture an assessment conclusion. |
| Has someone with authority accepted the risk? | accepted | NOT_ESTABLISHED | No authorized human acceptance or risk-response judgment exists. |
| Is it right for this mission? | missionSuitable | UNKNOWN | No authorized mission-suitability judgment exists. |
A gap is a question the runtime cannot yet answer. Twenty wait on public evidence, four wait on a recorded human judgment, one waits on a complete instance.
A refusal is the model declining to conclude. Each one names its reason and stands until the missing evidence or judgment exists.
One control, end to end
Take one familiar rule — accounts must be managed, NIST AC-2 — and follow it through every layer. Watch what each layer is allowed to contribute, and where the trail stops at a person.
NIST publishes the requirement; the framework gives it a seat in the model.
NIST-AC-2 is the external requirement identifier. The federal RMF-style CORE concept remains CTRL-005.
A reusable identity pattern — RBAC, MFA, privileged access management — waits as a candidate, nothing more.
AZGOV-FRH.IDENTITY.ENTRA-RBAC-MFA-PIM — the bounded pattern was admitted only after applicability validation.
The specimen selects the pattern and points at a synthetic piece of evidence.
INST-IDENTITY-001 selects the pattern and EVID-FIX-IDENTITY-001 supplies a synthetic evidence pointer.
Someone — fictional here, real in practice — records the applicability call. The machine only remembers it.
JUDG-APPL-IDENTITY-001 records APPLICABLE_TO_FICTIONAL_EXERCISE. The resolver did not create that judgment.
The model can now carry the approved applicability. Tested and accepted remain open, because no one has tested or accepted anything.
RES-IDENTITY-001 carries the approved fictional applicability. Assessed and accepted remain not established.
| In plain terms | Machine question | State | Limitation |
|---|---|---|---|
| Did someone write it down? | documented | ESTABLISHED | Public reference-pattern documentation only |
| Does the service exist where we need it? | available | UNKNOWN | No real region or subscription is in scope |
| Does the provider's authorization cover our exact use? | providerAuthorizedInScope | UNKNOWN | Exact service, feature, and region scope not established |
| Can we ride on the provider's homework? | inherited | UNKNOWN | No provider control-responsibility evidence admitted |
| Is it set up? | configured | ESTABLISHED | Synthetic configuration only |
| Does the record hold together? | mechanicallyValidated | ESTABLISHED | Reference integrity and synthetic fixture checks only |
| Has an independent assessor tested it? | assessed | NOT_ESTABLISHED | No assessment procedure or result is admitted |
| Has someone with authority accepted the risk? | accepted | NOT_ESTABLISHED | No authorized acceptance judgment exists |
| Is it right for this mission? | missionSuitable | UNKNOWN | No mission-suitability judgment exists |
EVID-FIX-IDENTITY-001
Evidence is a pointer with an integrity fingerprint — if the thing it points at changes, it stops counting.
RES-FINDING-001
The representative fictional external-connection inventory is incomplete. A person recorded the problem — and only a person may decide how bad it is.
The finding was recorded by fictional human judgment. Severity, acceptance, and authorization consequence were not generated.
Change a fictional assumption
Assumption: the fictional identity selection or its synthetic evidence changes. One small change — and the honest cost is visible: 65 dependency paths re-checked, 6 people who must look again, 15 documents stale until they do. Invalidate the resolved value and re-run applicability and human-review gates before regenerating affected projections. Nothing regenerates itself past a human gate.
The kinds of change that pull this thread.
The documents that immediately stop being trustworthy.
Receipt 68de8d49b42932b16028b4cdd3558ca054a2e5c343781d0203e88e269e8e9ee3
The receipt enumerates effects only. It creates no new snapshot, projection, professional judgment, or authorization decision.
Build a package from the model
The package is sixteen documents, GULF-00 through GULF-15. In this empty specimen, one previews and fifteen refuse to render — correctly — because rendering them would require evidence or judgment the specimen doesn't hold. Every projection, previewed or refused, carries the required fictional marking in full, exactly as it appears in the banner at the top of this page.
| Package | Projection | Status | Refusal |
|---|---|---|---|
| GULF-00 | Package manifest and receipts | PREVIEW_ONLY | None — preview only |
| GULF-01 | Resolved model and provenance | REFUSED | REFUSE-AMBIGUOUS-L2-RESOLVED-VALUE-MAPPING |
| GULF-02 | Source and freshness projection | REFUSED | REFUSE-PROJECTION-NOT-DECLARED |
| GULF-03 | System identity, roles, and context | REFUSED | REFUSE-PROJECTION-NOT-DECLARED |
| GULF-04 | Security categorization | REFUSED | REFUSE-PROJECTION-NOT-DECLARED |
| GULF-05 | Boundary, flows, connections, and PPS | REFUSED | REFUSE-PROJECTION-NOT-DECLARED |
| GULF-06 | Architecture and inventories | REFUSED | REFUSE-PROJECTION-NOT-DECLARED |
| GULF-07 | System security plan | REFUSED | REFUSE-AMBIGUOUS-L2-RESOLVED-VALUE-MAPPING · REFUSE-CONTROLLED-IL5-EVIDENCE-GAP · REFUSE-INCOMPLETE-CONTROL-POPULATION |
| GULF-08 | Control responsibility and implementation matrix | REFUSED | REFUSE-PROJECTION-NOT-DECLARED |
| GULF-09 | Evidence catalog and lineage | REFUSED | REFUSE-PROJECTION-NOT-DECLARED |
| GULF-10 | Security assessment plan | REFUSED | REFUSE-PROJECTION-NOT-DECLARED |
| GULF-11 | Security assessment report | REFUSED | REFUSE-PROJECTION-NOT-DECLARED |
| GULF-12 | POA&M | REFUSED | REFUSE-PROJECTION-NOT-DECLARED |
| GULF-13 | Continuous monitoring | REFUSED | REFUSE-PROJECTION-NOT-DECLARED |
| GULF-14 | Risk, conditions, and decision briefing | REFUSED | REFUSE-PROJECTION-NOT-DECLARED |
| GULF-15 | Existing human authorization decision view | REFUSED | REFUSE-AMBIGUOUS-L2-RESOLVED-VALUE-MAPPING · REFUSE-CONTROLLED-IL5-EVIDENCE-GAP · REFUSE-MISSING-OFFICIAL-DECISION |
The L2 snapshot is the value authority for these receipts. A missing or ambiguous provenance join refuses instead of silently reusing the example snapshot.
Eight controls is a teaching slice, not a security plan.
The eight-control-style representative slice is not a complete system security plan or control population.
Public documents can't prove a controlled environment.
Public evidence cannot establish exact current service scope, instance isolation, boundary/connection acceptance, or authorization.
No one has decided — so there is nothing to print.
No authorized human authorization-decision record exists; the resolver and projection engine cannot create one.
OSCAL
The envelope is proven to travel: a schema-valid, lossless 1.2.3 test envelope is verified for transport only; semantic package compatibility is not established. What it may never do is impersonate an authorization — package export remains refused, because no format converts assembly into authority. The FedRAMP OSCAL 1.2.2 reference is a vendored control-catalog version, not a package consumer contract.
Sources
The model currently believes exactly three public documents — each mapped, dated, and bounded. Nineteen more claims exist, and every one stays withheld until it earns a registry mapping. Freshness is recalculated by that registry as of 2026-08-30T23:59:59Z; embedded GULF freshness is never trusted. Belief is expensive here, on purpose.
National Institute of Standards and Technology — NIST SP 800-37 Rev. 2 — verified 2026-08-24 — current
Supports: NIST SP 800-37 Rev. 2 defines the federal Risk Management Framework lifecycle and authorization-step context used by this bounded CORE.
Boundary: The publication does not authorize this fictional instance and does not make the GULF kernel universal outside a federal RMF-style context.
Defense Information Systems Agency — publisher-controlled current edition — verified 2026-08-29 — current
Supports: The public DISA cloud-computing SRG package supplies bounded DoD cloud requirements and mission-owner applicability concepts.
Boundary: The public package is not an exact current provider authorization letter, system assessment, mission authorization, or complete controlled implementation recipe.
Microsoft — continuously maintained documentation — verified 2026-08-24 — current
Supports: Microsoft publishes impact-level-5 isolation guidance for Azure Government workloads.
Boundary: Provider guidance does not establish exact current service scope, instance isolation, DoD authorization, GULF authorization, or mission suitability.
Each identifier below has no explicit mapping to the governed public Reference source registry. Embedded GULF freshness and source text are not published.
Words on this page