Beyond Private Access — Part III / Module II — Part 1 of 4

The Flow Atlas — Census Unit, Endpoint Anatomy, and Storage Surfaces

From Service Surface to Material Exact Flow: The First OCI Census Block

Alessandro Moccia | Oracle Cloud Infrastructure

Technical edition — 8September 2026. Document reference date — 8September 2026.

Evidence rule. Each source supports only the behavior and scope it actually describes. The Flow Atlas distinguishes seven classes: ORACLE-DOCUMENTED, capabilities and behaviors stated in Oracle documentation; ORACLE-REFERENCE-ARCHITECTURE, topologies published by Oracle Architecture Center or another Oracle-owned source; PROJECT-OBSERVED, results from author-executed tests under identified configurations and conditions; ORACLE-ENGINEERING-CONFIRMED, results subsequently confirmed with Oracle specialist engineering; ENGINEERING-INFERENCE, conclusions derived from stated premises; TEST-REQUIRED, properties still to be demonstrated in the target environment; OPEN-GAP, missing information or unresolved ambiguity. A result may carry multiple evidence references, each with its own class: observation and confirmation are not two executions of the same test. A property is never transferred by analogy to another service, API surface, plane, region, endpoint form, identity mode, or address family.

Scope of conclusions. The Flow Atlas is a dated census. Every technical statement must identify the exact surface, the relevant date, and the evidence class. A reference architecture describes a topology; it is not a universal support contract. Where general documentation, runtime catalog state, and experimental evidence have different granularities, the record preserves that difference: it does not replace field-verified behavior with an inference drawn from broader wording.

Scope. Exact-flow census in Oracle Cloud Infrastructure: flow identity, plane decomposition, endpoint identity, semantic target, stable Flow ID, ownership, discriminator locality, collector applicability, and the sources from which the Flow Atlas is compiled. Enforcement verdicts, managed-lifecycle closure, and the assurance calculus are deliberately kept separate from the census.

Editorial continuity. Precursor — OCI Zero Trust Architecture · Beyond Private Access — Part I of III · Beyond Private Access — Part II / Module I · Beyond Private Access — Part II / Module II · Beyond Private Access — Part III / Module I.

Executive abstract

The previous module established the truth conditions for this Part III. It argued and defended a position: the unit of security truth in a cloud estate is not the product, subnet, appliance, or landing zone, but the exact material flow; and a control earns credit for a property only when it traverses that flow, observes the discriminator that defines the property, can express the corresponding rule, applies it fail-closed, remains compatible with protocol, trust, and lifecycle constraints, stays within a supported placement, and is backed by evidence that is still valid.

That contract presupposes an object it did not build: the inventory of things to which it applies. Module II builds that inventory, and nothing else. Module I states the obligation in one line that should remain unsoftened: Module II owes a dated Flow Atlas, not a product list.

The operational consequence is deliberately uncomfortable: the number of rows to census cannot be derived from the number of exposed endpoints alone. It is the number of material exact flows that emerge once endpoint is separated from target, product from its planes, source from principal, and published capability from the dependency actually observed. That difference is precisely where undeclared dependencies, surfaces left active after migration, content flows that take a different path from the management plane, and outbound calls emitted by managed services under identities different from the workload identity reside. A configuration review cannot discover a row that the census never created.

0. From the Claim-Admissibility Contract to the Flow Atlas

Visual references: Figure F44; Table 17.

Module II is not introduced as an independent new treatise. It resumes exactly where Module I deliberately stopped: once the unit of security truth and the conditions under which a claim is admissible have been established, the set of objects to which those rules must be applied still has to be built.

Part III was designed as a sequence of six distinct obligations. The first fixed the assurance contract; the second must build the census; the third will evaluate the real decision power of the controls; the fourth will isolate the provider-managed portion and its lifecycle; the fifth will produce the verdict calculus; the sixth will make the model adoptable and continuously revalidatable. This separation is not an editorial device. It prevents a property from being attributed before the object on which that property is supposed to hold has even been defined.

Table 17 — The Six Modules of Part III and What Each One Closes

For publication, this single Module II is serialized into four substantial parts. The split is editorial and does not alter the technical object: there is one Flow Atlas, one Flow ID namespace, one progressive numbering scheme for figures and tables, and above all one proof obligation. The size of the four publications is not predetermined by a word quota; the split occurs only when a technical block is complete enough to stand independently, with the same argumentative, visual, and evidentiary density used in the OCI Functions Security Engineering series.

Three results from Module I become operational premises here. First, a product name is never a sufficient scope: the unit remains the material exact flow, defined by source process and population, principal and credential, operation and plane, service and resource target, endpoint and address family, forwarding path, discriminator, ownership, and evidence surface. Second, evidence classes are not interchangeable: published capability, regional runtime state, workload dependency, and provider-managed dependency describe different objects and must remain separate. Third, a property is not inherited because products, planes, or endpoints look similar: every row must carry its own evidentiary perimeter.

From those premises, Module II asks:

What are all the material exact flows that actually exist in the OCI estate, plane by plane and service family by service family, and for each one what are the exact endpoint, protocol, semantic target, discriminator and its locality, owner, authorization domain, forwarding family, available collector, and regional state at the census date?

This is far broader than asking "which services does the organization use?". A single product can produce management flows, runtime flows, content flows, invocation flows, browser surfaces, provider-managed dependencies, and telemetry flows. The same semantic target can appear through different endpoint contracts and reachability families: an Oracle public service FQDN may be reached through Internet/public routing or privately through a Service Gateway; a PSA-capable service API may be reached through the private IP of a PSA endpoint; a resource may expose a native/resource Private Endpoint; a mediated front door introduces another exact flow. The same operation may be executed by a customer workload, a managed agent, a service principal, or another cloud. Each of those differences may alter the security meaning of the row.

The Flow Atlas therefore keeps endpoint contract and reachability/forwarding family as distinct coordinates. Regional Oracle service FQDN, namespace-specific FQDN, instance-specific FQDN, PSA endpoint, and native/resource Private Endpoint describe the destination surface. Internet/public routing, Service Gateway, PSA, private VCN routing, FastConnect/VPN + DRG, or a managed backend describe how a source reaches that surface. Service Gateway makes the separation especially clear: it privately routes to the service's public service endpoint over Oracle fabric without turning that endpoint into a Private Endpoint. The row preserves both coordinates without converting them into a verdict.

The same discipline applies to lifecycle and evidence. Module II records who owns a managed dependency and which collectors may potentially observe it; it does not conclude that the lifecycle is closed or that the evidence is sufficient. Keeping those layers separate does not weaken the census. It makes the census reusable: Module III receives an object that does not already contain the verdict it is supposed to calculate; Module IV receives ownership and provider-managed dependencies without finding them already "closed"; and Module V can build its calculus without first dismantling scores introduced too early.

Representation locality. A diagram that expresses a path must distinguish Region, VCN, subnet, gateway, attachment, and managed service surface. An on-premises client or a client in another cloud does not belong inside the OCI Region. A DRG and its attachments are not a subnet; a Private Endpoint inside a VCN is not the whole managed service. Traffic arrows identify initiator and destination; a logical relationship must not be read as continuation of the network path.

Figure F44 — From claim-admissibility contract to the dated Flow Atlas.

The diagram makes the methodological handoff between Module I and Module II explicit: the former defines when a future claim may be defended; the latter builds the dated record to which those rules will be applied. endpoint_contract/FQDN_class, reachability_family, semantic_target, authority, collector, evidence scope, and date remain separate coordinates. The pipeline arrows express methodological dependency, not network traffic. Module II produces no PASS/FAIL, security score, enforcement credit, or lifecycle closure.

0.1 Centralized inspection: scope of the endpoint figures

Figures F44–F58 isolate endpoint, protocol, and service surface. The absence of a firewall from one of those views does not prescribe a network without inspection. The real path retains the control points defined by the foundation; the two context figures show those controls without duplicating the endpoint atlas.

The design requirement is centralized inspection of selected customer flows, with source preservation and symmetric return routing. This property is not obtained merely by placing a firewall in the hub. Oracle documents both transit toward OSN through an inspection private IP and a FortiGate reference architecture with return traffic traversing the appliance. Private access to Oracle services; FortiGate reference architecture.

SGW, PSA, and NAT Gateway are alternative branches, not serial appliances. Reaching a service, traversing the firewall, and being able to discriminate the application target remain separate properties. A private route and no-SNAT, by themselves, do not constitute an anti-exfiltration guarantee.

0.2 One environment, internal and external inspection domains

The general view represents one environment and its DRG. The spokes are projects or application domains within that same environment; Development, Test, and Production are not three spokes of this view. Network compartments and resource compartments express administrative ownership that is distinct from VCN/subnet boundaries.

The internal DMZ inspects ingress from on-premises and private communications among resources included in scope. The external DMZ governs Internet exposure and selected egress. Each domain may contain a firewall pair with trust/untrust interfaces in private subnets of its own VCN. The design does not require every connection to traverse both domains; the path is assigned per flow. A separate backup domain remains outside these figures.

A private path may traverse the same DRG before and after the firewall, using decisions associated with different attachments. Traffic within the same VCN also requires intra-VCN routing when it must traverse the inspection point: the default route alone does not automatically intercept local communications. VCN route tables.

0.3 Two passes through the same firewall

The double traversal of the same centralized firewall from on-premises was tested and is operational in the project deployment. That evidence must not be downgraded to a hypothesis. It does not, however, prove every possible implementation of the intermediary proxy.

The additional variant with a source-preserving proxy in a separate private subnet of the same hub VCN as the firewall has not been tested: it was considered plausible in the interaction with Oracle specialist engineering, with deployment validation still required. The two states remain distinct: FIELD-TESTED for the existing double traversal; PROPOSED VARIANT — TEST REQUIRED for this proxy composition.

The following scheme describes the proposed variant. On-premises reaches the proxy private IP; the proxy selects the OSN destination and must preserve the client IP on the upstream connection. The firewall cluster is the same in both passes; two firewalls are not introduced merely for diagrammatic convenience.

PROPOSED SOURCE-PRESERVING PROXY VARIANT — TEST REQUIRED
Forward path
On-premises client
  -> FastConnect private connectivity / DRG
  -> Central firewall: pass 1
  -> Private source-preserving proxy
  -> SAME central firewall: pass 2
  -> Service Gateway
  -> Oracle Services Network

Return path
Oracle Services Network
  -> Service Gateway
  -> SAME central firewall: return pass 1
  -> Private source-preserving proxy
  -> SAME central firewall: return pass 2
  -> DRG / FastConnect private connectivity
  -> On-premises client

PROPOSED SOURCE-PRESERVING PROXY VARIANT — TEST REQUIRED
Forward path
On-premises client
  -> FastConnect private connectivity / DRG
  -> Central firewall: pass 1
  -> Private source-preserving proxy
  -> SAME central firewall: pass 2
  -> Service Gateway
  -> Oracle Services Network

Return path
Oracle Services Network
  -> Service Gateway
  -> SAME central firewall: return pass 1
  -> Private source-preserving proxy
  -> SAME central firewall: return pass 2
  -> DRG / FastConnect private connectivity
  -> On-premises client

The first pass authorizes and inspects access to the proxy; the second applies policy to the upstream destination. The two transport connections and their respective sessions remain distinct even when they preserve the same source address. The service response must reach the proxy before being forwarded definitively toward on-premises.

The proxy is not an Oracle requirement for every OSN access pattern. In this scenario it satisfies the requirement not to send packets whose destination is a public IP from on-premises over the private link. Where that constraint does not exist, direct on-premises → firewall → SGW transit is a separate Oracle-documented case. Private access to Oracle services.

0.4 Source preservation without SNAT

In this foundation the firewall does not perform Source Network Address Translation (SNAT). This requirement avoids replacing the original source with the appliance address at downstream observation points. Source address and the VCN context used by the service are nevertheless different coordinates: no-SNAT alone does not prove which Network Source will be recognized by each API.

The proxy in the source-preserving case must also retain the original IP on its upstream connection. Removing a NAT rule from an ordinary explicit proxy is not sufficient: the proxy must use a mode that actually emits the client source and must have a coherent return path. Squid documents tproxy for this behavior; HAProxy documents transparent proxying with usesrc clientip. Those capabilities do not automatically validate the complete OCI composition. Squid TPROXY; HAProxy transparent proxying.

The result must not be attributed to the label "Squid" or "TLS passthrough" alone. The proxy mode, the address actually emitted on the upstream connection, and the return to the proxy must be verified. Preserving an application header containing the client IP is not equivalent to preserving that network property.

The remaining validation concerns the source-preserving proxy variant: configured routes, source IP observed on the upstream leg, and return paths for both connections. It does not concern the already validated ability of the deployment to traverse the same firewall twice. The result of the first case is not transferred to the untested variant.

0.5 Return-path steering and application mediation

In the source-preserving variant, both return legs have the on-premises client as their IP destination, yet they require different next hops: the SGW → firewall return must reach the proxy; the proxy → firewall return must continue toward the DRG. The proxy next hop does not change the packet destination IP, which remains the client. A single destination-based lookup in the same routing context cannot distinguish the two legs: there is no rule that becomes "overwritten" on the second pass; rather, one routing decision is insufficient to represent both paths.

F-H02 must therefore associate each leg with the firewall ingress interface, internal forwarding decision, egress VNIC, effective OCI route table, and next hop. The discussed profile separates contexts by means of appropriate VNICs/subnets and routes. Per-resource routing is an alternative that must be verified for the traffic actually being forwarded: the private IP used as an ingress target does not automatically select the subsequent route table. OCI routes govern the relevant egress; the forwarding decision inside the firewall is a different layer. VCN route tables; Per-resource routing.

The model does not claim that two VNICs are the only possible mechanism, nor that they are sufficient without configuring the appliance and proxy. Firewall policy routes may use ingress context; the specific selection must be verified on the adopted profile, without introducing SNAT as a shortcut for return-path engineering. FortiGate policy routes.

The FortiGate reference architecture documents an SGW-associated route table that steers return traffic toward the firewall's floating trust private IP. The proxy case must extend that return by inserting the proxy on the correct leg; copying the no-proxy route is not sufficient. OCI routes and appliance-internal routes are different objects. FortiGate reference architecture.

A private API Gateway may likewise be protected on both client and backend paths using the applicable routes and controls. The double-inspection principle remains, but the IP-preservation contract of a transparent TCP proxy is not automatically transferred to API Gateway. The documentation describes a gateway-to-HTTP/HTTPS-backend connection: source, principal, and backend logs must be censused separately. API Gateway HTTP back ends.

Any call to a Function authorizer is a distinct authorization dependency; it is not the payload path to OIC. The census records the connections actually configured, not a generic "proxy/API Gateway" arrow with indistinguishable properties.

0.6 Private targets, service egress and Internet

For a VM that directly calls an OSN service with no intermediary proxy, the selected path is spoke → DRG → centralized firewall → SGW → service. No-SNAT at the firewall remains the requirement. A public service address does not imply traversal of the public Internet: SGW uses Oracle fabric. Private access to Oracle services.

For OIC runtime, the integration URL and SGW path are preserved; no runtime PSA is invented. Authentication, authorization, and the service allowlist remain controls that are distinct from firewall acceptance. SGW/PSA service matrix.

For a private resource, the branch continues to its VCN and corresponding Private Endpoint. With PSA, the name must resolve to the private IP of the endpoint for the specific service API: the customer path traverses the required firewall and reaches PSA, without appending an SGW after it. DNS, routing, and return behavior must be validated together. Private Service Access.

The Internet branch traverses the selected inspection point and a NAT Gateway, which is distinct from SGW and PSA. NAT Gateway translates the address for Internet access; this does not authorize introducing SNAT on the firewall or proxy in violation of the foundation requirement.

An implementation constraint remains: Oracle limits direct use of a NAT Gateway to resources in its own VCN. A branch with remote sources whose addresses are preserved is therefore not declared valid by analogy with SGW. In the absence of a verified solution compatible with the no-SNAT requirement, that branch remains a deployment gap; it is not "fixed" by introducing unauthorized translations. NAT Gateway.

0.7 Public ingress and identified managed-flow exceptions

The reference Internet-ingress path is IGW → L7 Load Balancer with regional WAF in a public subnet → external-DMZ firewall on the designated private subnets → private backend. The Load Balancer backend connection is distinct from the client connection. Responses belonging to the public session follow their corresponding return path; they are not new outbound connections to be sent through the NAT Gateway. OCI DMZ concepts.

A separate variant, illustrated by Oracle Learn in October 2024, places OCI Network Firewall before the Load Balancer/WAF by using gateway ingress routing: IGW → OCI Network Firewall → L7 Load Balancer with regional WAF → application. The variant preserves the placement and return behavior of the tutorial; it is not concatenated with the LB-first profile used by the foundation. Network Firewall before Load Balancer (2024).

For the specific non-deterministic Oracle-managed dependencies identified in the project, the compatibility path is different: resource or node in the service VCN → SGW in that same VCN → OSN, with no centralized firewall interposed. ExaDB-D and OKE are examples of affected dependencies; they are not labels that authorize bypass for all application traffic associated with those products.

The separation must exist in the effective routes. An OSN rule toward a local SGW applies to traffic within its routing scope; it does not recognize an Oracle process. The DRG is not attributed a capability to choose a route based on OWN-B or OWN-C. If customer and managed traffic share the same route selection, the census records the limitation and residual risk. VCN route tables.

0.8 Figure contracts and evidence boundaries

F-H01 shows one environment, the relevant inspection domains, and the alternative SGW/PSA/NAT branches. F-H02 shows the paths, including double traversal of the same firewall: repeated graphical instances of the same appliance are identified as such and are not counted as two clusters. The tested pattern and the untested proxy variant carry different badges; the return matrix is a requirement of the variant, not a new test result. Labels are in English; customer names, addresses, and identifiers are not reproduced.

Figure F-H01. Centralized inspection context: private connectivity, public ingress and alternative service-egress paths.

Figure F-H02. Tested double traversal and proposed source-preserving proxy variant: distinct evidence states and return-routing contexts.

F51 remains separate and unchanged: in the ADB Private Endpoint deployment used for the author tests, subsequently confirmed with Oracle specialist engineering, SQL*Net uses the PE and is rejected via SGW; HTTPS with Allow public access follows the SGW-VCN conditions illustrated in the figure. The additional firewall neither replaces the service-side admission check nor changes the observed test result.

The network context ends here. The following sections return to the object of this module: endpoints, planes, discriminators, and material exact flows. The centralized topology clarifies where inspection is applied; it does not assign the same security property to every service.

1. Endpoint Identity and Flow Identity Are Not the Same

1.1 Two Requests Seen Differently by Two Controls

Consider two outbound HTTPS requests from the same private subnet to objectstorage.<region>.oraclecloud.com. Same destination address, same port 443, same Server Name Indication value presented during the handshake. One is signed by the workload's technical identity and targets a bucket in the tenancy. The other is signed with a different credential and targets a bucket owned by another organization.

To a Layer-4 observer, the two requests are the same object. To the destination service, they are two different authorization objects evaluated against different principals, with outcomes the network observer will never know.

The estate's endpoint inventory contains one row. Reality contains two, with potentially opposite verdicts. A program that stops at the first row has therefore certified the second without ever seeing it.

This is not an Object Storage curiosity. It is the normal form of almost every managed service, for a structural reason: target selection occurs where the protocol places it, and the protocol almost always places it deeper than where the network observes.

1.2 The Pattern, Repeated

Container registry. The host is regional — in the form <region-key>.ocir.io — and identifies service and region. The real target is the namespace/repository/tag-or-digest tuple, which lives in the request path and in the manifests exchanged after the handshake. A push to the organization's repository and a push to a repository in another tenancy are the same object at Layer 4 and different objects to the service, which evaluates them using different credentials.

Artifact registry. Here the separation is even sharper because it involves two different planes rather than two targets within the same plane: repository administration and content transfer are independent surfaces. Forcing a private path on the administration surface does nothing for the content if the content is transferred through another path.

Integration platform. The design-time surface is regional and carries the instance as a parameter; the runtime surface is instance-specific in the hostname. They place identity in different protocol locations within the same product: on the first, the operation target is inside the request; on the second, it is in the name. The product itself acknowledges the distinction by exposing separate allowlist rules for the two surfaces — documentary confirmation that they are two flows, not one.

Managed database. The private address identifies the instance. The real operation target may also include the listener service name, database user, role, and — for still finer claims — the executed statement. Those elements belong to protocol semantics and database authority: merely terminating or decrypting the transport does not automatically turn them into policy attributes of a generic network PEP. In the Flow Atlas they remain distinct discriminators, each with its own locality.

Managed inference service. The deployment endpoint identifies the deployment. A call emitted by that deployment toward an external resource — a tool, data source, or third-party API — is a different flow with a different origin, different principal, and often a different authorization domain. It is not the flow shown by the deployment diagram, and an endpoint inventory will not show it at all.

Data replication. The management console and the deployment's native endpoint are distinct surfaces, while the source and target connections used by the deployment are additional flows toward systems that may sit outside the estate and under completely different authorities.

1.3 Endpoint and Target Are Two Fields, Not One

The first census rule follows directly from those examples, and it is a schema rule, not a style preference:

The row records endpoint identity and semantic target identity as separate fields. Always, even when they happen to coincide.

They seldom coincide. Where they diverge, the endpoint becomes less informative as a description of the target: the name may identify only service and region, while repository, bucket, resource OCID, database service, or tool target remain deeper in the protocol. The Flow Atlas records that divergence without prematurely turning it into a judgment about control effectiveness.

The second separation is equally binding: endpoint contract and reachability family are not the same coordinate. A Service Gateway does not create a private endpoint for a service. Oracle documents that, with SGW, the request continues to use the service's public endpoint while the packet is routed privately to Oracle Services Network over Oracle fabric. PSA instead creates a VNIC-like Private Service Access endpoint with a dedicated private IP and an FQDN associated with one specific service API; the client continues to use the expected service FQDN and private DNS resolution maps it to the PSA endpoint. A native or resource Private Endpoint is a third contract: the service materializes a private IP/FQDN for a specific resource or specific surface. The row therefore cannot use one ambiguous private/public field; it must retain at least endpoint_contract/FQDN_class and reachability_family as independent attributes.

This separation prevents two mirror-image errors. The first is calling a request to an Oracle public service FQDN a "public path" merely because the endpoint remains public in the service contract: if the request originates in a VCN and is routed through Service Gateway, the path does not traverse the Internet. The second is calling every private access mechanism a "private endpoint": a PSA endpoint and a native Private Endpoint are different resources and contracts, with different scopes and targets. The supported-services matrix further confirms that support is assigned to the exact service/API surface: OCI Container Registry, Artifacts and Container Images API, and Functions Service invocation have PSA support; Generic Artifacts Content API and Functions Service API are sibling surfaces with a different answer. The project's historical regional runtime snapshot makes the same distinction concrete through the container-registry, artifacts, functions-invocation, and object-storage entries.

1.4 Row Multiplication Is an Estate Property

The practical result is a real multiplication of rows relative to an endpoint inventory.

An endpoint inventory and an exact-flow census count different objects. One inventory entry can produce multiple flow rows when the plane, endpoint contract, forwarding family, process population, or credential changes. There is no universal multiplier: variants are derived from the estate, correlated, and deduplicated according to the materiality criterion defined in Chapter 3. The final count is not estimated from the number of products.

That multiplication is not artificial inflation: each row corresponds to a different security statement that can be true or false independently of the others. The multiplier is measured service family by service family because each plane and endpoint form may introduce a different source, authority, target, and evidence surface.

Oracle sources: Container Registry overview; Artifact Registry overview; Design-time and runtime URLs; Integration allowlist; Request signatures.

Figure 45 — Exact surfaces: hostname, target and access contract.

The selected rows compare eight surfaces through name, visible discriminator, deeper target, and access contract for that same row. OIC design-time and runtime remain separate; outbound networking does not become an inbound property. For Functions, the Function OCID remains in the request path and is not inferred from host/SNI alone. The ADB SQL box preserves the author's test results for the Private Endpoint deployment with Allow public access, referring to F51; it does not transfer control-plane PSA capability to the SQL connection. NOT LISTED describes the documentary matrix, not a measured rejection. The complete census is in T21–T22, sibling APIs are decomposed in F49/F55, and intermediate firewalls are covered by F-H01/F-H02. Oracle sources: SGW/PSA supported services; Runtime and design-time URLs; Invoking Functions; Generic Artifacts Content endpoint.

2. A Product Is Not a Flow

The second rule follows from the first but is more radical because it removes from the vocabulary the phrases most commonly used to communicate cloud architectures.

A product exposes planes: sets of operations that share authorization authority, protocol surface, and network model. Planes within the same product may have opposite localities, different endpoint forms, different availability of private paths, different lifecycles, and different owners. Statements such as the Function is private, the database is private, or the integration is behind the gateway are therefore not convenient shorthand. They are statements that can be true on one surface and false on another surface of the same product, and there is no way to know which one applies without decomposing the product.

2.1 Recurring Planes in OCI

The plane types that recur in OCI form the minimum decomposition grid. Not every service exposes every plane and, more importantly, surfaces within the same product do not automatically share endpoints, authority, or protocol semantics.

Table 18 — Plane Taxonomy

The grid is operational: each plane can produce material exact flows with its own endpoint, protocol, discriminator, and authority. As a first approximation, the number of rows for a product is the number of planes it exposes multiplied by the number of endpoint forms exposed by each plane.

2.2 Functions: Management, Invocation, and Application Networking Are Distinct

OCI Functions condenses at least four exact surfaces with different contracts under one product name. The management plane creates and modifies Applications and Functions through the Functions Service API. The invocation plane executes the Function on the invocation surface. The content flow concerns OCIR and the image. Runtime egress originates instead from the subnets associated with the Application and governs what the code reaches while it executes.

The private-access distinction is especially instructive today. The current Oracle SGW/PSA matrix assigns Service Gateway = yes to both the Functions Service API and Functions Service invocation, but assigns PSA only to invocation; the project's historical regional snapshot accordingly contains the functions-invocation entry, not the management API. The statement "Functions supports PSA" is therefore incomplete: which plane? is part of the claim.

The Application subnet is a different axis again. It is not a client-addressable private ingress endpoint for the Function; it describes placement and private connectivity for the runtime. Invocation retains its own endpoint contract. When a private API Gateway uses a Function as backend, Oracle further documents the managed backend path through Service Gateway; the fact that the direct invocation surface is PSA-capable does not authorize rewriting that contract by analogy.

The Flow Atlas must therefore create distinct rows, at minimum, for management, direct invocation, mediated invocation, image pull, and runtime egress. Each row carries its own endpoint/FQDN contract and reachability family.

Oracle sources: Functions private access; API Gateway function backends; SGW/PSA supported services.

2.3 Managed Kubernetes: Seven Distinct Surfaces

The cluster is the case in which decomposition produces the largest number of surfaces, and it is also the case most often communicated as though the architecture were one object.

The cluster control-plane endpoint has its own reachability and authorization, and public and private forms are distinct rows. The primary VNICs of worker nodes govern node traffic toward services on which the nodes themselves depend. Secondary VNICs of pods govern workload traffic, and node pools support multiple secondary-VNIC profiles: subnet, network security group, and addressing profile may therefore differ by profile inside the same cluster. The load-balanced service path exposes workloads outside the cluster. An ingress controller or request-layer tier adds a mediation surface with its own rules. Node egress toward services — registry, Object Storage, telemetry, identity service — is an entire flow family, often the largest and least thoroughly censused. And pod-to-pod traffic is another surface that must be recorded separately: two pods scheduled on the same worker node may exchange traffic that does not traverse the network fabric on which VCN controls are evaluated.

The consequence is direct: scheduling is a census input. Two communicating pods produce one row or two depending on where the cluster has placed them, with different denial authorities and different collectors. A census that records one convenient row has recorded only the convenient case. That difference does not yet produce a verdict; it does, however, produce two rows because the network surfaces and candidate control points do not coincide.

Oracle sources: Kubernetes Engine security reference; ZPR with Kubernetes Engine; Generic VNIC attachments.

2.4 Database: Native Private Endpoint, Public Twin, and Protocol Remain Separate Rows

Autonomous Database Serverless shows why endpoint, protocol, and forwarding family cannot be compressed into one ADB via SGW row. In the deployment analyzed here, the database has a Private Endpoint and the Allow public access option enabled in the Control Plane. That option makes the public surface available for using HTTPS/web URLs through Oracle Services Network and Service Gateway; it does not make the SQL*Net/TCPS path equivalent to the web path.

Tests executed by the author and subsequently confirmed with Oracle specialist engineering distinguish three conditions. SQL*Net/TCPS uses the Private Endpoint private hostname/private IP and does not traverse Service Gateway, even when using the gateway in the same VCN. HTTPS/web, by contrast, can use the public access URL through Service Gateway, but the gateway traversed must belong to the same VCN associated with the Private Endpoint. Adding another VCN to the access list does not remove this condition: a path that exits through the gateway of the other VCN is rejected by the service.

Section 10.3 reconstructs the transit test with source and Private Endpoint in VCN A and egress through SGW-B after a centralized firewall with no SNAT. Those results are experimental evidence for the described deployment, not conclusions inferred from the mere availability of the Database Service API through SGW or PSA.

Oracle reference for the general configuration model: Configure Network Access with Private Endpoints. The general source is not used as evidence for the specific observed test outcomes.

2.5 Oracle Integration 3: Public Service FQDN Inbound, Service Gateway from the VCN, Private Endpoint Outbound

Oracle Integration is the most effective case for separating naming, reachability, and direction. The design-time FQDN is regional and carries the instance in the integrationInstance parameter; the runtime/service-console FQDN is instance-specific. Both remain inbound Oracle service FQDNs. For a source in the same region, Oracle documents the pattern with an allowlisted VCN and Service Gateway, so traffic from the VCN reaches OIC privately without traversing the Internet; other allowed sources may still have normal external reachability. The allowlist remains the platform's inbound network-origin control.

The native OIC Private Endpoint is instead outbound only: it is the surface through which the integration runtime reaches private resources in the customer's VCN. It is not an alternative ingress endpoint for design-time or runtime callers. A custom endpoint adds a consumer-facing FQDN for supported surfaces, but it does not automatically remove the original service URL and does not make every OIC surface part of one mediated path.

The minimum decomposition is therefore: OIC-DESIGN-SGW, OIC-RUNTIME-STANDARD-SGW, optional OIC-RUNTIME-CUSTOM, OIC-OUTBOUND-PE, plus the control-plane API. The public/service nature of the FQDN and private reachability through SGW are not contradictory; they are two fields of the same exact-flow record.

Oracle sources: Control Network Access; Developer API URL contracts; Integration private endpoints; Integration custom endpoints.

2.6 Oracle Analytics Cloud, Replication, and AI: Direction Changes the Meaning of "Private"

Oracle Analytics Cloud makes three different contracts explicit. An instance may be deployed with a public endpoint and access-control rules; in that model Oracle allows IP/CIDR, VCN, and Oracle services to be allowlisted and documents the path from a VCN to OAC through Service Gateway, keeping traffic on Oracle fabric. Alternatively, the instance may be created with a native Private Endpoint inbound: the service URL is reachable only through the configured VCN/on-premises private connectivity and requires private DNS resolution. These two modes are deployment alternatives, not the same surface with a routing flag.

The Private Access Channel is a third flow and has the opposite direction: OAC uses it outbound toward private data sources or private Git. Oracle documents that PAC can be used whether the OAC instance is inbound-public or inbound-private. Consequently, OAC private is not a valid single row: user ingress public, user ingress native private, and PAC outbound are distinct exact flows.

The same direction rule applies to GoldenGate, Generative AI, and Data Science: deployment/front-door access and managed runtime egress are not one property called private endpoint. The census records source process, direction, and endpoint contract before assigning any other coordinate.

Oracle sources: OAC public endpoints and access control; OAC private endpoints; OAC Private Access Channels; Generative AI private endpoint; Generative AI networking.

2.7 Object Storage: Multiple Endpoint Forms for the Same Operation

OCIR and Artifact Registry: The Private-Access Matrix Is Per API Surface, Not Per Product Logo

The current catalog and the project's runtime snapshot show a separation that must appear in the census even before Object Storage is considered. OCI Container Registry is reachable through Service Gateway and appears among the regional catalog's PSA entries; its registry FQDN remains regional while namespace, repository, tag, and digest remain deeper in the request. Artifacts and Container Images API is likewise SGW+PSA. Generic Artifacts Content API, however, is a distinct sibling surface: Service Gateway is listed, while PSA is not indicated in the current matrix. A diagram that simply writes Artifact Registry → PSA therefore loses the content flow; a diagram that writes OCIR → Service Gateway loses the PSA variant.

This is exactly the structure of the Flow Atlas: each API surface has its own row, and endpoint/FQDN class remains separate from reachability family.

Oracle sources: Container Registry overview; SGW/PSA supported services. Project evidence: historical regional PSA catalog snapshot with 32 entries, including container-registry and artifacts.

Object Storage is one of the densest examples of how a single operation can produce materially different exact flows when the endpoint form changes. The semantic target can remain the same while endpoint contract, forwarding family, discriminator locality, and evidence surface all change.

The same operation — reading an object — may occur through the shared regional endpoint, a dedicated endpoint that moves the namespace into the hostname, a virtual-host-style compatibility form where supported, a per-service private-access endpoint, or a resource Private Endpoint bound to a namespace, compartment, or set of buckets. Five forms, five rows, with the discriminator living at different depths in each and with different collectors.

A further object is involved that is not itself a traffic flow: the capability artifact. A Pre-Authenticated Request encodes authorization and has its own creator, expiry, and scope. In the Flow Atlas it is therefore not treated as an autonomous traffic row: the flow that creates the capability and the flow that uses it are censused separately, while the PAR remains a credential/capability object referenced by both rows. This prevents an authorization artifact from being confused with the path on which it is presented.

The family extends beyond object storage: the managed file system exposes mount targets as network surfaces distinct from the file-system management plane itself; block volumes expose attach, backup, and clone planes, with backup potentially crossing a region boundary. Each of those surfaces produces a distinct record when the security meaning of the flow changes.

Oracle sources: Object Storage dedicated endpoints; Object Storage private endpoints; Pre-authenticated requests; File Storage mount targets.

2.8 Identity and Credentials: Planes Upstream of All Others

The identity family introduces a class of flows that often precedes consumption of every other service surface: credential issuance, provisioning, or acquisition. The concrete form depends on the principal and credential model; precisely for that reason, credential provenance must remain in the census.

There are at least five distinct surfaces with different authorities. Identity-domain administration governs users, groups, applications, and access policies. Token issuance produces credentials that all other planes later present and may itself be constrained upstream by network-perimeter definitions applied to sign-on policy or as a restriction on a specific application. Resource and instance identities allow a workload to acquire a credential without anyone distributing it and are the source of a flow family that inventories almost never capture. Vault and key management expose distinct management and cryptographic planes with different endpoints. Certificates and administrative-access services add their own surfaces.

A credential appearing in a row is not a value without provenance. API signing key, UPST, RPST, OAuth/OIDC token, database token, secret, or certificate-based identity each has a different issuance, provisioning, or acquisition process. The census must therefore be able to correlate the flow that uses a credential with the authority and process that made it available, without assuming that all credentials follow the same lifecycle.

Oracle sources: Network perimeters; Network perimeter on an application; Network sources.

2.9 Messaging and Events: When the Endpoint Is Not Regional

Messaging and streaming show another form of endpoint identity.

Not every service exposes one regional hostname. Some messaging surfaces direct the client to an endpoint specific to the cell that hosts the resource rather than to a name shared by the region. The census consequence is immediate and must be recorded: the name form changes discriminator locality, changes what a name-based rule can express, and changes row cardinality because two resources of the same service may have different endpoints.

That is why the record in Chapter 5 keeps destination name form separate from service family: the form must be verified per service and per date; it is not inferred from the family.

Oracle sources: Queue — Messages Endpoint; Streaming — Getting Details for a Stream; Stream Pool details.

2.10 Decomposition as a Method

Decomposition is not memorized service by service. It is performed by answering the same questions while retaining the discipline that answers are never transferred by analogy. The same grid is applied service family by service family.

Table 19 — Decomposition Questions and Why the Answers Are Not Inherited

3. Stable Flow ID

3.1 Why the Identifier Must Survive the Resource

A census that names flows after the objects that implement them does not survive the first lifecycle event. Resources are recreated, private addresses change, identifiers change with the resource, certificates rotate, and route tables are rewritten. A list that identifies a flow through those values becomes unreadable within months and — more importantly — loses the ability to answer the question does this claim still refer to the same thing it referred to before?

The analytical identity of the flow must therefore be separated from the values that implement it. The scheme adopted in this module is:

FA-<FAMILY>-<PLANE>-<OPERATION>-<VARIANT>-<NN>

FA-<FAMILY>-<PLANE>-<OPERATION>-<VARIANT>-<NN>

where FAMILY is the service family, PLANE is the code of the plane from the taxonomy in Chapter 2, OPERATION is the operation, VARIANT is the endpoint/path contract that distinguishes the row, and NN is a two-digit sequence. The first four fields use uppercase alphanumeric codes and, for compound codes, the underscore; the hyphen separates fields only. For example, FA-OCIR-CONTENT-PULL-SGW-01 and FA-OIC-RUNTIME-CONNECT-OUTBOUND_PE_ADB-01 follow the same grammar. The expanded plane and operation descriptions remain in the record; the code does not replace them.

The essential point is what does not enter the identifier. Resource identifiers, private addresses, security attributes, certificate fingerprints, route-table names, and analysis identifiers are evidence fields: they describe the implementation at a point in time, change with that implementation, and are updated accordingly. They are not the identity of the flow. Using them as the identity is the mistake that makes a census unmaintainable.

3.2 The Three Failures the Identifier Prevents

They are worth listing because they recur, are easy to recognize, and each consumes real organizational time.

The change ticket that opens more than it declares. A ticket says enable the integration toward service X. The implemented change opens a broad regional path used by multiple planes of the same service, and nobody notices because the request and the implementation speak about different objects: the request describes an integration, while the implementation describes a route. With stable identifiers, the request names the affected rows and the review verifies that the change touches those rows and no others.

The incident that cannot be correlated. During an investigation, flow records speak in addresses, service logs speak in buckets and request IDs, Audit speaks in principals and operations, and the application speaks in transactions. Without a common identifier, correlation means manually reconstructing a mapping that nobody recorded. With a stable identifier, every artifact carries a reference to the row and correlation becomes a join.

Compliance evidence that stands still while the estate moves. An evidence package collected six months ago describes a configuration that has since changed. Without stable identifiers, nobody knows which claims depended on the modified object, and the only honest answer would be to redo everything. With stable identifiers, changing an object mechanically produces the list of rows that reference it.

3.3 The Flow as an Evidence Object

From this follows a property established by Module I and made operational by the census: a row describes not only what happens, but also what would falsify it.

Alongside descriptive fields, the row therefore carries references to the artifacts that support it: which configuration evidence, which runtime evidence, which service record, with what timestamp, and produced by which observer. Module II does not decide whether that evidence is sufficient — that belongs to the Module V calculus — but it records which evidence exists and which evidence is missing, because a census that cannot distinguish supported rows from asserted rows is not a census; it is a statement of intent.

3.4 When a New Flow ID Is Created

Exact-flow discipline creates the opposite risk from a product list: multiplying rows for every runtime difference until the Atlas becomes unmanageable. The correct rule is therefore not "every different field always creates a new ID," but every difference that changes the security meaning of the flow creates a new ID.

A difference is materially sufficient when it changes at least one of the following: candidate PEP set, target discriminator, authorization authority, principal or credential class, protocol security semantics, endpoint contract, source-process ownership, forwarding family, evidence surface, or provider/customer lifecycle ownership. If a difference would force a later evaluation module to ask a different question, a different row must exist.

This criterion prevents row explosion without falling back into lazy aggregation. Ten replicas of the same microservice, with the same workload identity, VNIC profile, endpoint, and authority, may belong to one source_population; their OCIDs and private IPs are evidence fields. The same application scheduled onto a different OKE secondary-VNIC profile may require a new variant because the network surface changes. Likewise, two regions may share a Flow ID only if endpoint contract, authority, private-access family, and collector availability are genuinely equivalent; otherwise region is not merely a geographic value but a difference in security contract.

The same rule applies to operations. GetFunction and ListFunctions may be aggregated into a management operation family when source, authority, endpoint, and property set coincide; InvokeFunction cannot be absorbed into that row because the plane changes. On a database, password/mTLS and IAM DB token authentication may share endpoint and TCPS while remaining separate rows because credential issuer and authentication chain differ.

The objective is not to maximize row count, but to maximize fidelity to security meaning: two records remain together only as long as later evaluation modules would have reason to ask them the same questions.

4. Ownership, Discriminator Locality, and Collector Applicability

Once the object has been defined — the exact flow, per plane, with a stable name — the space in which it exists must also be defined. Every row carries three coordinates, and they are independent in the strict sense: knowing two does not determine the third.

That independence is not a theoretical observation. It is the reason a census discovers things that a configuration review does not, because almost every conventional practice collapses at least two of the three.

4.1 Who Owns the Flow

The first coordinate answers: who owns the emitting process, the network locality in which it executes, the authority that issued the credential, and the domain in which the destination authorizes the request?

Five recurring conditions must remain distinct because they determine which controls can in principle be inserted without breaking something the customer does not own.

Customer application egress is the full-ownership case: process, network, credential, and configuration are customer-owned.

Provider-managed software executing inside customer networking is the case in which the VNIC belongs to the customer while the process does not. This is the condition of managed agents running on customer-addressed nodes, and the census records it because it radically changes the list of controls that may be applied: the trust store of that process is not the customer's to modify. Whether the process can be intercepted is a separate enforcement question. At census time, the relevant fact is that process_owner and network_owner do not coincide.

Control-plane or service-to-service automation is the case in which the customer network is not where the flow occurs. Configuration, identity, logging, and contract remain census objects even though the customer VCN is not the network locality of the traffic.

Managed or agentic application egress is the fastest-growing family: a managed service calls outward on behalf of the customer under a technical service identity. The census asks a precise question: does the product keep that egress on a provider-operated plane, or does it return it to a customer-selected subnet? The answer changes row ownership and collector availability, and must be obtained from the documentation of the specific service.

The external authorization domain is the case in which the final target decision is made in another tenancy or by another provider. The row records where that decision occurs; it does not state whether the arrangement is acceptable.

4.2 Where the Discriminator Becomes Observable

The second coordinate asks: where along the path does the field that separates the approved target from the prohibited target become readable?

Four conditions recur. A shared regional hostname leaves the target in the path, query, token, or protocol semantics. A tenancy- or namespace-qualified hostname carries organizational identity in the name itself, and therefore into resolution, the certificate, and the Server Name Indication field. A resource-, instance-, or deployment-specific endpoint exposes a resource discriminator in the name or private address. And the fourth condition is the case where no usable discriminator exists at the network layer: the target lives inside protocol semantics the network does not speak, or inside a provider-operated plane.

Two warnings accompany this coordinate, and they are the two most often violated in practice.

A resource endpoint is not secure by construction. It means a discriminator is exposed at endpoint level. It does not mean the public endpoint is closed, that alternative forms do not exist, that a foreign credential would fail, or that supporting evidence exists. In the census this becomes an operational rule: the resource-endpoint row does not replace the shared-endpoint row; it sits alongside it until removal of the shared form has been demonstrated.

Absence of a discriminator does not mean insecure. It means that, if the required property exists, it must be carried by another authority. The census records that as a fact, not a judgment.

A third technical precision prevents the most subtle mistake on this coordinate: the protocol layer at which a value is readable and the semantic form of the endpoint are different facts, with no mechanical conversion between them. A bucket may appear in a virtual-host-style name and therefore be readable in Server Name Indication even though it is a resource; a console session may carry an instance identifier inside a protected tunnel and remain unreadable at every network layer. The row records both facts in separate fields.

Locality must also be stated relative to the property one intends to distinguish. Let r1 and r2 be two requests and O the set of fields actually available to an observer. If O(r1) = O(r2) while the required property distinguishes the two requests, a decision based only on those fields cannot guarantee that distinction. An additional discriminator, or an observation/authorization point that exposes it, is required. This limitation concerns that property; it does not erase the value of the same metadata for other purposes, such as anomaly detection. It follows from the declared information model, not from a newly asserted product capability.

4.3 Which Collector Can Observe

The third coordinate is the one almost no inventory tracks, and it is the one that turns an inventory into a census.

The question is: which instrument in this estate can observe this flow, and what can it prove?

Four conditions recur. Some paths are decidable by configuration analysis without sending traffic, within the documented limits of the tool. Others require a combination of tools, and the observation is admissible only up to the intersection of their respective coverage. Others are not decidable from configuration because the documentation explicitly declares a segment indeterminate, so they depend on runtime evidence only. And still others traverse provider-operated planes for which no tenant-visible collector exists.

On this last condition, one point must be stated directly: opacity is not an accusation. Large portions of every managed platform are legitimately opaque, and the shared-responsibility model expects that. What is unacceptable is silent opacity: an estate that cannot say which of its material flows are opaque has not performed the census. An estate that knows and declares them has simply done the work.

A further constraint makes this coordinate stricter than it appears. Documented coverage is the ceiling imposed by the platform; the set of collectors actually deployed in the estate determines how much of that ceiling is reached; and the distance between the two is itself a census field. Marking a path observable merely because a combination of tools could be deployed, when it is not deployed, creates an unsupported row.

4.4 Three Coordinates, Three Independent Questions

All three coordinates describe the same packet, yet they answer questions that do not imply one another.

A flow may belong to provider-managed software, have its target hidden beneath a regional hostname, and traverse a point that requires three collectors to reconstruct. A flow may expose its discriminator perfectly in the name and still be unobservable because the only tool that spans that segment declares it indeterminate. A flow may be entirely customer-owned and entirely opaque because the protocol places the target below every network layer.

The point where a decision can be made and the point where a fact can be observed are different facts about the same packet, and they almost never coincide.

The Same Row Viewed by Three Different Teams

Separating coordinates is not only about avoiding theoretical mistakes. It prevents three teams from describing the same flow using three different objects and then assuming they are discussing the same thing.

The network team starts from source subnet, destination, route family, and candidate PEP. To that team, FA-OIC-RUNTIME-CONNECT-OUTBOUND_PE_ADB-01 may look essentially like a private flow between an Oracle Integration VNIC-like surface and an Autonomous AI Database private endpoint. That is a correct description of forwarding context and an incomplete description of the flow.

The IAM team starts instead from principal and credential. The same row may be described as a connection that presents a credential configured in the integration, or another supported identity mode, to the database. That description is also correct and incomplete: it does not say which endpoint was selected or which route family delivered it to the target.

The database team starts from service name, user, TCPS protocol, and the database authorization context. It may have no operational interest in the DRG, subnet, or firewall names. Its description is likewise true and partial.

The Flow Atlas does not choose which of the three teams has the "right" representation. It preserves all three representations in one row and assigns them to different fields. This makes later comparison of candidate PEP and discriminator possible without forcing the network engineer to invent database semantics or the database engineer to reconstruct the network path.

The same discipline matters even more for managed services. An OCI Generative AI agent running in Customer Networking Mode has a provider-managed process, customer-selected networking, and an authorization domain determined by the tool target. One label Oracle-managed would erase the customer's control over the subnet; one label customer network would erase the fact that the process and trust store do not belong to the customer. The coordinates prevent both simplifications.

That is why the census does not seek one final "class" for the flow. It seeks a set of coordinates that can be queried independently.

The most common collapse is between the second and third coordinates: people assume that wherever a control could decide, the same fact can also be observed. This is false in both directions. An inspection point that could decide on a name is often the very object that makes configuration analysis of that segment indeterminate. Conversely, a flow whose target no network control can distinguish may be perfectly observable in the destination service logs, which name the resource the network will never see.

Three worked cases make the independence undeniable, one for each possible collapse. They are presented as coordinates, not verdicts.

Case A — the discriminator is readable, the flow is not observable. A workload consumes a service through an endpoint whose name contains the namespace. The second coordinate is favorable: organizational identity is readable from the name-indication field without decrypting anything. But the path traverses a network appliance, and the configuration analyzer documentation declares paths containing such an appliance indeterminate. The third coordinate is therefore unfavorable: no single tool decides that segment, and runtime evidence is required — evidence the estate may not have deployed. Knowing only the second coordinate would incorrectly suggest that the flow is "covered."

Case B — the flow is observable, the discriminator is not readable. A workload consumes a service through the shared regional endpoint, and the service records the selected resource name in its logs. The third coordinate is favorable: a collector exists that names the target, and names it better than any network tool could. The second coordinate remains unfavorable: no point in the network distinguishes the two requests. The two coordinates point in opposite directions on the same packet, which is why they must be recorded separately.

Case C — the flow is customer-owned and remains opaque. A fully customer-owned workload opens a session to a managed database. The first coordinate is as favorable as possible: process, network, credential, and configuration all belong to the customer. Yet the operation target is the service name and database user, which live inside protocol semantics and are not readable at the network layer. Process ownership says who can act, not where the target lives.

The second, less visible collapse occurs between the first and second coordinates: a customer-owned flow is assumed to be automatically analyzable and discriminable. It is not. Process ownership tells us who can intervene, not where the target exists.

5. The Canonical Flow Atlas Record

Once unit, name, and coordinates have been defined, the row is the object that carries them. It is deliberately verbose for an operational rather than aesthetic reason: an empty field is preferable to an assumption hidden inside a diagram, because an empty field is visible. The record is populated service family by service family while preserving the same grammar.

5.1 Field Groups

Table 20 — The Canonical Exact-Flow Record

Fields a Conventional Network Inventory Usually Loses

The table includes fields that a conventional network inventory does not usually retain. They are precisely the fields that allow networking, identity, application semantics, and evidence to be correlated without reconstructing the flow after the fact.

The identity chain is not one principal field. A flow may originate from a browser user, be authenticated by an Identity Domain, be mediated by API Gateway, and then be re-originated toward the backend under a different service identity. An OIC adapter may use a connection credential that does not match the designer's identity. An IAM database token is issued in one domain and consumed by the database in another authorization context. The record therefore separates principal, credential_type, credential_issuer, credential_audience, authentication_authority, and authorization_authority. Module II records the chain; it does not yet decide whether propagation or translation is correct.

Endpoint contract and reachability family must remain separate groups. An Oracle public service FQDN may be reached from a VCN through Service Gateway without becoming a private endpoint; the same service FQDN may, when the specific service API is PSA-capable, resolve to the private IP of a PSA endpoint; a native/resource Private Endpoint instead has its own private endpoint contract. The Flow Atlas records both coordinates. A row may therefore state endpoint_contract = regional Oracle service FQDN and reachability_family = SGW, or reachability_family = PSA, without turning the difference into a verdict.

Collector is recorded as a candidate observation surface, not as proof sufficiency. Audit available, Flow Logs enabled, or firewall traffic log present are not verdicts. The census needs to know what exists, who collects it, and what scope it sees; a later calculus decides whether the evidence join is sufficient.

Date is part of the record because endpoint behavior and the runtime catalog change. A row without source_date, runtime_capture_date, or at least a census date is a temporal generalization, not a snapshot of the estate.

These fields are the point at which the Flow Atlas stops being a networking table and becomes an inter-module object.

5.2 The Five Grammar Laws

One flow, one row. A row that describes two protocol surfaces, two planes, or two credential authorities is really two rows written lazily. This is the easiest rule to violate when row count grows and the temptation to aggregate for convenience increases.

No inherited field. Nothing is copied from another row because two services look similar. Guarantees, endpoint forms, discriminator locality, collector applicability: none of these values is transferable. This is the operational translation of the law established by Module I and the only defense against certification by analogy.

Semantic target and authorization authority are always separate fields. They answer different questions — what are we protecting? and who can refuse? — and they occupy different places often enough that collapsing them is dangerous.

Alternative forms of the same access are rows, not notes. If the same semantic target is reachable through multiple paths or endpoint forms, each one is a row. The census does not decide which one is the real path: it records all of them, and records which forms have been removed and with what evidence.

A row is dated or it is null. Every row carries the census date, an expiry, and at least one revalidation trigger.

5.3 The Record Preserves Facts, Not Verdicts

The strength of the record also lies in what it deliberately does not attempt to summarize. It contains no security score, produces no PASS/FAIL, and does not treat the presence of a control as proof of effectiveness. A row may record a private endpoint, a ZPR policy, an API Gateway, or a centralized firewall without turning any of those elements into a conclusion.

The reason is structural. Module II is building the domain of observable facts: which process generates the flow, which principal it uses, which endpoint it reaches, which target it selects, which authority decides, and which collectors exist. PEP effectiveness, evidence sufficiency, and lifecycle closure are additional properties and must remain separate until the modules responsible for them analyze them.

This separation prevents a common mistake in cloud-security documents: turning configuration into a verdict. private, mTLS, behind API Gateway, ZPR-enabled, Service Gateway, PSA, and behind firewall describe characteristics of the flow or path. They do not yet establish whether the requested property is closed. In the Flow Atlas they remain attributes, not security adjectives.

The same is true of destination identity. The field destination_service cannot be populated with the product's commercial name and treated as sufficient. The record retains plane, operation, endpoint_form, semantic_target, and target_discriminator precisely because technical destination and semantic destination may diverge.

Worked Row: OIC Runtime Outbound to an ADB Private Endpoint

An abbreviated record makes the difference between an architectural sentence and an exact-flow row visible. The YAML examples in this part are illustrative model cards, not OCI API payloads and not implicit runtime observations. Placeholders must be replaced with collected values; omitted fields must be populated or explicitly declared unknown before operational use. collector_applicability is a list of collectors, each with its own scope and limitation; evidence_class classifies one evidence reference, not a log type. A row may link multiple references in evidence_references.

flow_id: FA-OIC-RUNTIME-CONNECT-OUTBOUND_PE_ADB-01
service_family: Oracle Integration 3
plane: runtime outbound
exact_operation: adapter connection

source_process: OIC runtime integration
process_owner: Oracle-managed service runtime
network_owner: customer-selected VCN/subnet surface

principal: <connection/resource identity as configured>
credential_type: <exact configured credential type>
credential_issuer: <issuer>
authorization_authority: target database / associated identity authority

protocol: TCPS
endpoint_form: ADB private endpoint
region: <region>
address_family: <actual configured family>

semantic_target: <database service>
target_discriminator: <database service / target identity>
discriminator_location: database protocol/service context

forwarding_family: OIC Private Endpoint outbound
candidate_peps:
  - customer VCN network controls on the selected private path

collector_applicability:
  - collector: OIC connection/runtime evidence
    evidence_scope: connection configuration and integration result
  - collector: VCN network evidence
    evidence_scope: private segment actually covered by the collector
    applicability: verify on the selected resource and path
  - collector: database-side evidence
    evidence_scope: connection and identity in the database, where recorded
vendor_contract_source:
  - Oracle Integration private endpoint documentation
  - Autonomous AI Database private endpoint documentation
runtime_capture_date: <timestamp>
open_gap: <if any>

flow_id: FA-OIC-RUNTIME-CONNECT-OUTBOUND_PE_ADB-01
service_family: Oracle Integration 3
plane: runtime outbound
exact_operation: adapter connection

source_process: OIC runtime integration
process_owner: Oracle-managed service runtime
network_owner: customer-selected VCN/subnet surface

principal: <connection/resource identity as configured>
credential_type: <exact configured credential type>
credential_issuer: <issuer>
authorization_authority: target database / associated identity authority

protocol: TCPS
endpoint_form: ADB private endpoint
region: <region>
address_family: <actual configured family>

semantic_target: <database service>
target_discriminator: <database service / target identity>
discriminator_location: database protocol/service context

forwarding_family: OIC Private Endpoint outbound
candidate_peps:
  - customer VCN network controls on the selected private path

collector_applicability:
  - collector: OIC connection/runtime evidence
    evidence_scope: connection configuration and integration result
  - collector: VCN network evidence
    evidence_scope: private segment actually covered by the collector
    applicability: verify on the selected resource and path
  - collector: database-side evidence
    evidence_scope: connection and identity in the database, where recorded
vendor_contract_source:
  - Oracle Integration private endpoint documentation
  - Autonomous AI Database private endpoint documentation
runtime_capture_date: <timestamp>
open_gap: <if any>

The row does not claim that NSG, firewall, IAM, or database authorization is sufficient. It does, however, make explicit the distinctions erased by the sentence "OIC reaches ADB privately": direction, source process, endpoint form, semantic target, authority, and forwarding family.

5.4 Minimum Completeness Threshold

Completeness is not measured by the number of populated fields but by the record's ability to preserve distinctions that may change the meaning of the flow. For every material flow, at minimum the following must either be identified or explicitly declared unknown: service and plane, source process, endpoint, protocol, semantic target, discriminator and discriminator locality, authority, forwarding family, collector, evidence class, and date.

Three fields are particularly discriminating: semantic_target, target_discriminator, and discriminator_location. If they are missing, the record still describes a product or endpoint rather than a flow. Without source_process, the actual emitter cannot be identified; without authorization_authority, the deciding domain remains unknown; without forwarding_family, the materially present candidate PEP set cannot be reconstructed; without a date, a regional snapshot is silently converted into an atemporal platform property.

The criterion does not require inventing what is undocumented. On the contrary, unknown, not documented, provider-only, not observed, and runtime evidence missing are legitimate values. A row with an explicit gap is more useful than an apparently complete row built by analogy.

Figure F46 — Canonical exact-flow record: eleven field groups plus one explicit exclusion.

The figure is aligned to the groups in Table 20: identity, source, identity chain, protocol, coordinates, endpoint/FQDN identity, reachability/forwarding family, semantic target, collector, state, and record lifecycle/provenance. The twelfth cell is deliberately ABSENT BY DESIGN: the Flow Atlas contains no security score, PASS/FAIL, product-inherited capability, final assurance verdict, or control-lifecycle closure. A value such as unknown, not documented, provider-only, not observed, or runtime evidence missing remains explicit rather than being filled by analogy.

6. The Census Is Built from Sources That Do Not Coincide

Once unit, name, coordinates, and record form have been defined, the practical question that determines whether the census is useful remains: where the rows come from.

The wrong answer is: from the architecture. A census derived from diagrams contains the flows someone remembered, in the form in which someone interpreted them. It is the same set already covered by every configuration review, and that is precisely why those reviews discover nothing new.

The census is compiled by reconciling four sources that may overlap or diverge. The initial architecture diagram is a hypothesis to be tested against those sources, not the sole inclusion criterion. The expected outcome is coverage of material dependencies and an explanation of differences, not a mandatory increase in row count.

6.1 Published Capability

The first source is the vendor's current documentation: which planes the service exposes, which endpoint forms are supported, which private paths are documented for each surface, which behaviors are asserted, and with what scope.

Its value is precise and limited: it defines the supported contract. It states what the service does where a capability is available and — equally important — what it does not state. The census field populated here is therefore not only what the documentation says but also what it does not say: a surface for which no documented statement exists receives the value not documented. That is data, not an empty cell.

6.2 Regional Runtime Catalog

The second source is what the control plane actually exposes in the evaluated region at the evaluated time. It is captured with the command, complete output, timestamp, and artifact fingerprint.

This capture remains separate from the documentation because published capability and regional reality are different evidence objects. A count of supported surfaces captured once, in one region, on one day is a snapshot: it describes that region at that date. It is not a platform constant, and treating it as one is the kind of error that makes a census false without making it obviously false.

6.3 Workload Dependency Inventory

The third source is what workloads actually use, derived from flow records, Audit, name-resolution evidence, and workload configuration.

This is where unregistered flows emerge: a dependency on a service nobody declared, a call to a different region than expected, an endpoint form left active after migration, a content surface reached by a different path than the management surface, or an agent communicating with a service absent from every diagram.

The success criterion is reconciliation, not cardinality:

Every material dependency surfaced by the sources must be censused, correlated to an existing row, or explicitly excluded with rationale and evidence.

An already complete baseline may not grow; deduplication and decommissioning may reduce the row count. Two different sets may also have the same cardinality. Discovery quality is evaluated by comparing content, coverage, material variants, and exclusion rationales. Growth may indicate new dependencies, but by itself it is neither necessary nor sufficient to prove census quality.

6.4 Managed-Dependency Contract

The fourth source is the documentation of provider-owned dependencies: what the managed service calls, at which phases, and under which identity.

This source describes paths that may not appear in customer collectors. Rows are therefore declared from the vendor contract, with owner and visibility level explicit. Opacity does not remove the flow from the census; it becomes a property of the row.

6.5 Capture Procedure

The four sources remain only a definition until the method of capture, traceability, and ordering is specified. The procedure is deliberately mechanical because the value of discovery depends more on repeatability than on the intuition of an individual reviewer.

Order. First acquire the regional runtime catalog and workload dependency inventory; then compare them with published capability and the managed-dependency contract. This ordering reduces the risk of searching only for confirmation of the initial diagram. Reconciliation remains iterative: a new observation may require returning to documentation or configuration. New rows may emerge, but row growth is not mandatory.

Runtime catalog. Query the control plane for each in-scope family, recording the query, complete output, region, realm, time, and artifact fingerprint. The result is not a list of services; it is a list of surfaces exposed in that region at that date, which is a different object. Entries that are absent are recorded as absent from that region, not as nonexistent.

Dependency inventory. Reconstruct it by correlating flow records, Audit, DNS evidence, and workload configuration. Every source has its own scope: a network record covers the point and time window actually collected; a DNS answer documents a resolution, not admission of a connection; a configuration declares a dependency, not its use during the observation period. A name that resolves but is not contacted is therefore a candidate dependency to verify, not proof of an open surface. A connection without an observed DNS query may result from cache, resolution outside the window, an uncovered resolver, or direct address use; those remain hypotheses. A configured dependency that is not observed may be periodic, dormant, failover-only, or outside collector scope. The record keeps name existence, configured/modeled reachability, and observed connection as separate facts.

Comparison with published capability. For each surfaced endpoint, read the current documentation for the family and record three separate outcomes: documented behavior, documented behavior with a narrower scope than the observation, and absence of any documented statement. The third outcome populates not documented. It is not a failure of the research; it is a census result.

Managed-dependency contract. For families with provider-operated planes, record what the documentation states about the dependency, its owner, and the visibility still available to the customer. The census stops at the declaration.

Traceability. Every artifact produced by these four steps records the principal that collected it, the scope of that principal's permissions, the time, and a fingerprint. The reason was stated in Chapter 4 and deserves repetition here because this is where the process can fail silently: an absence observed by an insufficient principal is not an absence. A runtime catalog captured under partial permissions enumerates what that principal could see; the difference between that list and reality does not appear anywhere in the output.

6.6 Six Descriptions That Look Like Flows but Are Not

Some sentences look like a census but still describe architectural intent only.

"Service X is private." The plane is missing. OIC design-time, runtime, and outbound Private Endpoint are three rows. OAC private endpoint and PAC have opposite directions. "Private" without a surface is an attribute without an object.

"Function behind API Gateway." The other surfaces are missing from the inventory. The mediated flow and direct invocation surface remain distinct rows until the latter has been removed or declared non-material.

"Uses Service Gateway." Service Gateway is a forwarding family. It does not identify semantic target, principal, or operation.

"Protected by ZPR." ZPR is a candidate control associated with specific resource surfaces. OKE shows why a product-level statement is invalid: API endpoint, node VNIC, pod VNIC, Load Balancer, and File Storage mount target are not the same resource and do not automatically inherit the same security attributes.

"Observable in Audit." Audit is a candidate evidence surface, not a Boolean. The row must state which operation produces the event, which target field is present, which scope is read, and under which principal.

"No traffic observed." Not observed does not mean does not exist. It may indicate a dormant flow, a collector outside the path, disabled logging, insufficient scope, provider-managed segment, a different address family, or true absence. The dataset must distinguish at least not configured, not observed, not documented, provider-only, not material, and removed/closed.

The census becomes useful when missing values have explicit semantics rather than appearing as blank cells.

6.7 From Scattered Observations to the Record

The first operational pass should not attempt to populate every field immediately. It should create a candidate row that is specific enough not to lose the dependency and incomplete enough not to invent what is still unknown.

Consider a Flow Log showing an OKE VNIC connecting to a destination address associated with an Oracle service endpoint on TCP/443. The first row is not labeled OKE → Object Storage merely because that service is plausible. Record only what is actually observed:

source_population: <OKE node pool / VNIC>
protocol: TCP/443
destination_address: <observed>
endpoint_identity: <unresolved or resolved name if evidence exists>
source_process: unknown
semantic_target: unknown
principal: unknown
evidence_class: PROJECT-OBSERVED
evidence_kind: VCN Flow Log
observation_time: <collection_timestamp>
collector_scope: <VNIC_and_time_window_actually_covered>

source_population: <OKE node pool / VNIC>
protocol: TCP/443
destination_address: <observed>
endpoint_identity: <unresolved or resolved name if evidence exists>
source_process: unknown
semantic_target: unknown
principal: unknown
evidence_class: PROJECT-OBSERVED
evidence_kind: VCN Flow Log
observation_time: <collection_timestamp>
collector_scope: <VNIC_and_time_window_actually_covered>

DNS evidence may then add the name; node/container configuration may attribute the process to an image pull; OCIR configuration may identify namespace/repository; Audit or service logs may add principal and operation. The row becomes progressively more specific, but each step retains field provenance.

The same rule applies in the opposite direction. An OIC connection definition may declare a database hostname that does not appear in Flow Logs for the observed period. That does not authorize deleting the dependency: it may be dormant, failover-only, or outside the chosen collector's scope. The candidate row originates from configuration and carries runtime_observed: false.

This process creates a benefit a normal CMDB does not: conflicting sources become a structured finding. If configuration says PSA while DNS/Flow Logs show the public endpoint, the Flow Atlas does not choose whichever version "looks right"; it preserves the divergence as a field to resolve.

The first compilation therefore retains three distinct states for every critical attribute:

declared
observed
documented

declared
observed
documented

When they coincide, the record is stable. When they diverge, that divergence is the most important census result.

6.8 Documented, Available, and Observed Must Be Reconciled

The census universe includes material dependencies that are declared, observed, or required by the service contract. An observed but undocumented flow remains in the universe as a gap; a documented managed dependency that the customer cannot observe remains with explicit ownership and visibility. Neither disappears because of an intersection operation.

Selecting compatible candidate paths is a different operation. Documentation, runtime catalog, and dependencies are not sets of identical objects: before they can be compared they must be normalized to the same key — service/API surface, plane, operation, region/realm, endpoint form, protocol, source, and date. One explicit engineering model is:

U(t) = material dependencies declared or observed or required by contract

C(d, t) = candidate paths for dependency d in U(t)
          compatible with the exact-surface contract
          and with regional availability/configuration at date t

G(d, t) = missing information or incompatibilities still to be resolved

U(t) = material dependencies declared or observed or required by contract

C(d, t) = candidate paths for dependency d in U(t)
          compatible with the exact-surface contract
          and with regional availability/configuration at date t

G(d, t) = missing information or incompatibilities still to be resolved

C(d,t) is a view over the census, not the census itself. If availability is unknown, the path remains a candidate requiring verification; if the contract excludes it, it remains in the census as an attempted or inadmissible variant when material. A compatible candidate is not yet a successful connection: runtime outcome is an additional evidence object. The value of the comparison lies in making convergence and divergence explicit without deleting what no single source can close on its own.

7. FQDN Form Is a Flow Coordinate

Visual references: Figures F47–F49; Tables 21–24.

The first error the Flow Atlas must make impossible is using the word endpoint as though it already described the destination. In OCI, a Fully Qualified Domain Name (FQDN) may identify very different levels of the hierarchy: only a service in a region; a service plus the tenancy namespace; a specific instance; a private endpoint created inside the VCN; or a custom front door that does not coincide with the native origin. The fact that all of these objects are "DNS names" does not make them equivalent.

The distinction matters especially because an FQDN may play three different roles in the same design. It may be the string the client resolves, the value carried in TLS Server Name Indication (SNI), and the name from which the application builds the request. Yet the semantic target authorized by the service may sit deeper still: in the path, query, an OCID, repository, bucket, Oracle Net service_name, integration route, Function OCID, or access target. The census must therefore record both the visible name and the point at which the destination actually becomes specific.

This difference is not abstract theory. It is already visible in everyday OCI surfaces. <region-key>.ocir.io identifies the regional registry entry point, not the repository. design.integration.<region>.ocp.oraclecloud.com identifies Oracle Integration's regional design-time surface, while the instance name appears in the integrationInstance parameter. An Oracle Integration runtime URL instead carries the instance in the hostname. Object Storage may use the traditional regional endpoint, a dedicated endpoint that moves the namespace into the FQDN, a PSA endpoint with a private IP/FQDN, or an Object Storage Private Endpoint that adds a prefix and a private address inside the VCN. Autonomous AI Database may expose a native Private Endpoint and, under supported configurations, may also expose a public surface; the database service target nevertheless remains inside the connection protocol.

The consequence is that FQDN class becomes an explicit record field. This is not an aesthetic classification. It determines how much of the target is already named before the service interprets the request.

7.1 Regional FQDN: Service and Region, Target Still Deeper

A regional FQDN typically identifies a service/API surface in the region. It is the most common form for many OCI APIs and several data planes. The name allows DNS, routing, and TLS to deliver traffic to the correct service, but it does not necessarily contain the discriminator that separates two authorization targets.

OCIR is the clearest example. Oracle documents the recommended registry endpoint format and legacy region-key endpoints; in both cases the tenancy namespace and repository belong to the image reference, not the regional portion of the hostname. A push and pull to different repositories may therefore use the same regional host while namespace, repository, tag, or digest changes.

Artifact Registry requires the same decomposition, with one additional distinction: the commercial product name does not even correspond to a single API surface. The current Oracle matrix separates Artifacts and Container Images API, supported by both Service Gateway and PSA, from Generic Artifacts Content API, supported through Service Gateway but not listed for PSA. The census must therefore separate at least management/metadata from content transfer before it even addresses repository or artifact path.

Oracle Integration design-time provides another especially useful regional FQDN. Current documentation shows the form design.integration.<region>.ocp.oraclecloud.com and places the service instance in the integrationInstance parameter. Here the hostname says service and region; the instance discriminator appears later in the request. The runtime surface uses a different form in which the instance name belongs to the hostname.

The same pattern recurs in many control-plane APIs. Oracle's SGW/PSA matrix lists individual service API surfaces, not products. The Flow Atlas must therefore associate a regional FQDN with the exact API and exact operation family that uses it.

7.2 Namespace-Specific FQDN: The Name Begins to Carry Tenancy Identity

Object Storage dedicated endpoints show a deeper form. Oracle assigns tenancy-dedicated endpoints that include the Object Storage namespace in the URL. For the native API, the recommended form can be represented as:

<namespace>.objectstorage.<region>.oci.customer-oci.com

<namespace>.objectstorage.<region>.oci.customer-oci.com

The semantic benefit is immediate: the name no longer identifies only "Object Storage in the region," but also the tenancy namespace. In the census, this moves the tenancy discriminator upward into the FQDN and therefore into TLS SNI when the client uses that form.

That does not mean the bucket or object key has become part of the name. They remain in the path/request. The row must therefore be able to state simultaneously:

text

FQDN class              = namespace-specific
FQDN identifies         = service + region + tenancy namespace
semantic target         = bucket/object
deeper discriminator    = bucket / object key / version

FQDN class              = namespace-specific
FQDN identifies         = service + region + tenancy namespace
semantic target         = bucket/object
deeper discriminator    = bucket / object key / version

This precision prevents two opposite errors: treating the dedicated endpoint as equivalent to the old shared regional endpoint, or treating it as though it were already a per-bucket resource endpoint. It is neither.

7.3 Instance-Specific FQDN: A Specific Instance Enters the Name

When the instance or deployment enters the hostname, the census gains a more specific coordinate. Oracle Integration runtime is one example: the service-console/runtime URL is instance-specific, unlike the regional design-time FQDN that carries integrationInstance in the query. Oracle Analytics Cloud also exposes a distinct instance surface: the deployment may be created with a public endpoint or with a native inbound Private Endpoint, and the network-access mode becomes part of the instance's endpoint contract.

Autonomous AI Database brings specificity closer still to the resource. Its private endpoint is associated with a VNIC/private IP in the customer's VCN and provides a private hostname. If the supported public-access option is enabled, the database also has a public surface. The fact that both surfaces belong to the same Autonomous Database does not permit them to be compressed into one row: address, DNS population, source eligibility, and path family may differ; address family must be recorded rather than inferred from the public/private distinction.

An instance-specific FQDN still does not close the full semantics. In a database, service_name, database user, and optional schema/role remain deeper. In OIC runtime, the integration route or operation remains deeper. In a managed application, the tool target may remain deeper still.

7.4 PSA FQDN: Private IP for One Service API, Not for One Resource

Private Service Access adds a different class. Oracle documents a PSA endpoint as an object with a private IP and dedicated FQDN in a VCN/subnet for a single OCI service API. The model is VNIC-like: security lists, NSGs, and ZPR can be applied according to support for the resource.

The Flow Atlas must preserve that PSA specificity is service/API-level, not automatically resource-specific. A PSA endpoint for the Database Service API may serve management requests for multiple databases; a native Private Endpoint instead exposes a resource-specific surface. This granularity example does not demonstrate that SQL*Net traverses PSA or Service Gateway: the SQL contract for the Autonomous deployment in Section 10.3 remains separate.

That produces a materially different row:

endpoint_contract       = PSA
address                 = private IP
FQDN class              = PSA private service FQDN
service/API scope        = exact PSA-capable API
semantic resource       = may remain deeper than the FQDN

endpoint_contract       = PSA
address                 = private IP
FQDN class              = PSA private service FQDN
service/API scope        = exact PSA-capable API
semantic resource       = may remain deeper than the FQDN

The strongest documented property today remains Object Storage: Oracle explicitly states that the Object Storage PSA endpoint blocks cross-tenancy pre-authenticated requests, foreign credentials, and anonymous access. That behavior is service-specific and is not transferred to OCIR, Functions, or other PSA-capable APIs.

7.5 Resource Private Endpoint: Private Address and Target Scope Become Resource Properties

The resource/private-endpoint pattern is different again. An Object Storage Private Endpoint is a VNIC with a private IP in a selected subnet, has a private FQDN, and has access targets that may restrict namespace, compartment, and bucket. Oracle reiterates that access targets do not replace IAM: they describe which Object Storage resources the private endpoint may reach, while request authorization remains service-side.

This is why the record preserves both endpoint_identity and semantic_target. The Private Endpoint may become specific to a resource family or access-target set, but the individual operation and principal remain separate fields.

Another important property is the alternate surface. Oracle documents that creating an Object Storage Private Endpoint does not automatically restrict bucket access through the Internet or other network sources. A PAR created through the Private Endpoint may also be used through the public endpoint by substituting the private FQDN with the public endpoint. The census must therefore record the PE and public twin as distinct surfaces without anticipating the verdict on which one should be closed.

7.6 Custom FQDN: A New Name Does Not Remove the Origin

A custom endpoint is a fourth conceptual category because it introduces a customer-defined name in front of an existing service endpoint. Oracle Integration explicitly documents that a custom endpoint does not remove the original instance URL. Runtime access may use the custom endpoint directly; design-time, Visual Builder, and Process Automation have distinct redirect/behavior semantics. If API Gateway is introduced as a front door, the surfaces must be censused by exact component.

The row must therefore distinguish:

native endpoint
custom FQDN
mediating front door
origin endpoint

native endpoint
custom FQDN
mediating front door
origin endpoint

A custom FQDN being easier to read or easier to control does not automatically make it mandatory. Module II only needs to establish that these are different surfaces.

Figure F47 — Endpoint names expose discriminators, not complete targets.

The comparison distinguishes four naming contexts without turning them into a security ranking: regional service, namespace, instance, and assigned private endpoint. OIC URLs and Object Storage Dedicated Endpoints expose different discriminators. Resource-PE access targets remain configuration, not policy that can be decoded from the hostname. PSA DNS mapping may preserve the service FQDN; it does not create a universal fifth naming depth. The custom-endpoint note reminds the reader that, in OIC, the original name is not removed.

Table 21 — FQDN, SNI, and the Point Where the Target Appears

The table does not assign a PASS to an SNI column. Its purpose is to expose the exact point where destination description stops being sufficient. This field is especially important for later figures: an arrow to <region-key>.ocir.io and an arrow to <namespace>.objectstorage... are not equivalent, because in the second case part of the tenancy identity has already moved into the hostname.

The new Direct Consequence of Name/SNI column answers the question a reviewer should be able to close in seconds: does TLS passthrough distinguish only the region, also the tenancy namespace, or a specific instance/resource surface? For public ADB, the answer is intentionally strict: adb.<region>.oraclecloud.com is a shared regional hostname; the database is selected by service_name inside CONNECT_DATA. Oracle shows this separation in public connect descriptors, where host=adb.<region>.oraclecloud.com and service_name=<database-service>.adb.oraclecloud.com are separate fields. The public and private-SQL rows therefore remain separate even when they belong to the same Autonomous Database.

Table 22 — FQDN, First Visible Discriminator, and Private-Access Capability

Oracle sources: https://www.oracle.com/cloud/networking/private-service-access/service-gateway-and-psa-supported-services/ https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/private-service-access.htm https://docs.oracle.com/en-us/iaas/Content/Object/Concepts/dedicatedendpoints.htm https://docs.oracle.com/en-us/iaas/Content/Object/Tasks/private-endpoints.htm https://docs.oracle.com/en-us/iaas/application-integration/doc/configure-custom-endpoint-instance.html https://docs.oracle.com/en/cloud/paas/application-integration/rest-api/SendRequests.html

8. Endpoint Identity and Reachability Are Independent Axes

The second structural correction is to separate what the client names from how the source reaches that name. In OCI this separation is mandatory because Service Gateway can carry a private source to a public service endpoint without traversing the Internet, PSA can resolve the service API to a private IP inside the VCN, and a native Private Endpoint can be a resource-specific endpoint with its own address and DNS identity.

The field endpoint_contract describes the destination surface. The field forwarding_family describes the path family.

A regional FQDN may be reached:

• from a source with a public IP or NAT through Internet/public routing;
• from a private subnet through Service Gateway if the service API is SGW-supported;
• from on-premises through FastConnect/VPN → DRG → VCN → Service Gateway;
• through a PSA endpoint, but in that case the request uses the PSA FQDN/private IP and therefore the destination surface changes;
• through a customer-managed front door that then calls the service backend.

The key point is that Service Gateway does not "privatize" the FQDN. Oracle explicitly states that Oracle services have public IP addresses and that Service Gateway allows those services to be reached over Oracle fabric without traversing the Internet. The public service endpoint remains the service endpoint identity; the path is private.

PSA does something different. It creates an endpoint object in a subnet with a private IP/FQDN. DNS can then map the service API to the private surface. That difference must remain visible even when both flows are colloquially called "private access."

A native Private Endpoint is a third family: OAC may be deployed with a native inbound Private Endpoint; OIC has an outbound private endpoint for reaching private resources; Autonomous Database may have a database Private Endpoint; Object Storage has a resource Private Endpoint with access targets. These endpoints are not derived from generic PSA capability; they are product-specific resource surfaces.

Figure 48 — Endpoint identity and forwarding are independent coordinates.

The map crosses the scope selected by the name with four path families: public-address routing, Service Gateway, hybrid transit to SGW, and private-IP routing. The same Object Storage dedicated name or OIC runtime name may recur in several rows without becoming an additional hop. In the private-IP routing row, PSA and resource PE remain distinct endpoint contracts; PSA is not introduced as a universal extra level of DNS depth. Generic Artifacts Content appears on SGW, not among PSA endpoints. A blank cell does not indicate incompatibility. The figure does not prove an actual path, does not assign an enforcement verdict, and does not extend service-API support to ADB SQL: those outcomes remain the ones shown in F51. Centralized inspection and identified managed-flow exceptions are handled in F-H01/F-H02. Oracle sources: Service Gateway; Private Service Access; Private access from on-premises; Object Storage Private Endpoints.

Table 23 — Endpoint Contract and Forwarding Family Are Not Synonyms

Oracle sources: https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/servicegateway.htm https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/private-service-access.htm

9. The PSA Catalog Shows That the Unit Is the API Surface, Not the Product

The Oracle matrix updated to September 2026 makes one of the Flow Atlas rules especially visible. The table does not say "Functions yes/no," "Artifact Registry yes/no," or "Database yes/no." It lists service API endpoints. Within the same product, one surface may support PSA while another does not.

The Functions Service API row is SGW-supported and does not show PSA; Functions Service invocation shows both SGW and PSA. Artifacts and Container Images API shows SGW and PSA; Generic Artifacts Content API shows SGW but not PSA. OCI Container Registry shows both SGW and PSA. Kubernetes Engine API, GoldenGate API, Data Flow API, Data Integration API, and Oracle Integration API appear as SGW-supported and not PSA-listed. Monitoring, Logging, Audit, IAM control/data plane, and many other service APIs show both capabilities.

The project also retains a regional runtime snapshot obtained with:

oci psa psa-services list \
  --region <region> \
  --all \
  --output json

oci psa psa-services list \
  --region <region> \
  --all \
  --output json

The historical snapshot described in the project materials contains 32 entries in the captured region. The command above is the parameterized form for acquiring a new snapshot; it is not a reproduction of that historical execution. The number is neither an OCI constant nor a count derived from the current public matrix review: capability must be associated with the exact API surface and its date.

In the following sections, "not listed" means the consulted matrix does not state PSA for that exact surface; it is not the result of a new runtime attempt. The shorthand "SGW-only in the matrix" remains confined to the columns of that source and does not erase other service-specific contracts that may exist.

This is particularly useful for three families.

Functions. Invocation is PSA-capable; management does not inherit that capability. The Application subnet continues to describe runtime networking and does not automatically become an invocation endpoint.

Artifact Registry. Metadata/control and content transfer have two different API contracts. The bytes-moving Generic Artifacts Content API remains SGW-only in the current matrix. A statement such as "Artifact Registry uses PSA" therefore erases the most important distinction.

OCIR. The registry service is PSA-capable and SGW-supported. Repository identity nevertheless remains deeper than the endpoint. The census records PSA as a private-reachability capability and namespace/repository/tag/digest as separate target coordinates.

Figure F49 — Exact API support and alternative access paths.

Panel A separates the SGW path from two example PSA endpoints, each belonging to a different service. Panel B preserves thirteen exact surfaces, with Functions management separated from invocation and Generic Artifacts Content separated from metadata. Monitoring and Logging are decomposed into their respective APIs. NOT LISTED means that the consulted matrix does not indicate PSA; it is not a measured rejection outcome. The figure does not prove that PSA closes tenancy/resource semantics for services other than those with documented behavior. Database Service API means the control plane, not the database SQL listener.

Sources: Oracle SGW/PSA service matrix; Private Service Access endpoints; Service Gateway.

Path scope. The comparison concerns the capability of the individual API, not the number of hops in the landing zone. Any centralized firewalls are described in Sections 0.1–0.7. SGW and PSA remain alternative branches; PSA requires a distinct endpoint for every service to be covered.

Table 24 — SGW/PSA Subset That Must Produce Separate Rows

Primary source: https://www.oracle.com/cloud/networking/private-service-access/service-gateway-and-psa-supported-services/

10. OIC, OAC, Autonomous Database, and Functions: Four Products, Four Different Meanings of "Private"

Visual references: Figures F50–F52; Table 25.

The value of a taxonomy becomes clear when it prevents the same word from being used for four different mechanics. Oracle Integration, Oracle Analytics Cloud, Autonomous AI Database, and Functions all use private-networking concepts, but with different directions and endpoint contracts.

10.1 Oracle Integration: Inbound Service FQDN, Service Gateway from the VCN, and Outbound Private Endpoint

Oracle Integration 3 has at least three surfaces that must remain separate.

The design-time surface uses a regional FQDN such as design.integration.<region>.ocp.oraclecloud.com; the instance is carried in the integrationInstance parameter. The runtime surface uses an instance-specific service-console/runtime URL. Allowlist rules can be configured separately for runtime, design-time, File Server, and documented combinations.

When a same-region VCN is allowed, Oracle documents access to Oracle Integration through Service Gateway. This does not create a native OIC ingress Private Endpoint: the private source reaches the service surface through SGW over Oracle fabric.

The documented OIC Private Endpoint is instead outbound. It allows the OIC runtime to reach private resources in the VCN without traversing the Internet. The flow is therefore:

OIC managed runtime
  -> OIC Private Endpoint / customer-selected VCN surface
  -> private DNS / private target
  -> database / API / SAP / other supported private resource

OIC managed runtime
  -> OIC Private Endpoint / customer-selected VCN surface
  -> private DNS / private target
  -> database / API / SAP / other supported private resource

A custom endpoint adds a fourth surface. Oracle documents that it does not remove the original instance URL. The census records both.

10.2 Oracle Analytics Cloud: Public or Native Private Endpoint Inbound, PAC Outbound

Oracle Analytics Cloud is the perfect counterexample to OIC. At deployment time, Public or Private network access is selected. A private OAC deployment uses a native inbound Private Endpoint associated with a VCN/subnet and requires private DNS resolution. Oracle explicitly states that the URL is reachable only from the intended VCN/on-premises private network and not from the public Internet.

If OAC is deployed with a public endpoint, access may be restricted by access-control rules. Oracle also supports VCN access: in that case traffic from the VCN traverses the Service Gateway while still reaching the public OAC service surface over Oracle fabric.

The Private Access Channel (PAC) has the opposite direction: OAC uses PAC to reach private data sources or private Git repositories. PAC exists whether OAC has a public endpoint or a private endpoint; in the latter case it uses the same VCN/subnet as the private endpoint.

The Flow Atlas must therefore contain at least:

user/browser -> OAC public endpoint
user/browser -> OAC native Private Endpoint
OAC -> private data source via PAC
OAC -> private Git via PAC
OCI user/automation -> Analytics management API

user/browser -> OAC public endpoint
user/browser -> OAC native Private Endpoint
OAC -> private data source via PAC
OAC -> private Git via PAC
OCI user/automation -> Analytics management API

The product label "OAC private" distinguishes none of these rows.

10.3 Autonomous Database: Private Endpoint, HTTPS via SGW, and Service-Side Admission

The Database Service API shown in the SGW/PSA matrix is a management/control-plane API; it is not the SQL endpoint. The case below instead concerns Autonomous Database Serverless with a Private Endpoint and Allow public access enabled. The tests were designed and executed by the author; the results were subsequently confirmed with Oracle specialist engineering.

General documentation describes access options, endpoints, and ports. The more specific behavior reconstructed here distinguishes DNS resolution, network path, and request admission by the service. General availability of a public surface does not replace these experimental results.

SQL*Net/TCPS: the valid path terminates on the Private Endpoint. The client must use the PE private hostname and private IP over the corresponding private path. In the tests, the private hostname on TCPS 1521 established the connection. Attempts toward the public ADB surface routed through Service Gateway on TCPS 1521/1522 were rejected with DPY-6000 / ORA-12529. The rejection was also verified from a VM in the same VCN as the Private Endpoint while traversing the Service Gateway of that same VCN. With this PE deployment, Allow public access does not make SQL*Net/TCPS usable through SGW. The listener/service-side component is distinct from the transit gateway: SGW does not generate the Oracle Net error.

Authentication mode is not inferred from port alone. Oracle documentation distinguishes TLS on 1521 or 1522 and mTLS on 1522; the connect descriptor and client configuration identify the effective mode. This documented property is separate from the traversal result described above. The row also retains CONNECT_DATA.service_name, database user, and privilege context: the private hostname does not replace the target inside the protocol.

HTTPS/web: public access URL and Service Gateway in the same VCN as the PE. Enabling Allow public access in the ADB Control Plane makes the public surface available for database-associated HTTPS/web URLs such as SQL Actions / Database Actions and APEX/ORDS surfaces. The called URL must address the relevant public surface using an Oracle Services Network address reachable through SGW. In the tests, HTTPS 443 works through SGW-A, which belongs to VCN A where the Private Endpoint is also associated. Resolution to a public IP alone does not demonstrate application admission; the path and service result must also be retained.

HTTPS in transit routing: gateway VCN matters separately from source VCN. The negative test keeps both the VM and PE in VCN A. The source is in Subnet A1; the PE belongs to Subnet A2 in the same VCN A. The alternative path exits through the DRG, enters VCN B, traverses the centralized firewall without SNAT, and uses SGW-B:

VM-A / Subnet A1 / VCN A
  -> attachment A / DRG / attachment B
  -> centralized firewall / VCN B / NO SNAT
  -> Service Gateway B / VCN B
  -> ADB public HTTPS surface in Oracle Services Network
  -> ADB response: HTTP 403, referring to the “same private network”

VM-A / Subnet A1 / VCN A
  -> attachment A / DRG / attachment B
  -> centralized firewall / VCN B / NO SNAT
  -> Service Gateway B / VCN B
  -> ADB public HTTPS surface in Oracle Services Network
  -> ADB response: HTTP 403, referring to the “same private network”

The request reaches the ADB HTTPS surface but is rejected service-side because the Service Gateway used does not belong to the VCN associated with the Private Endpoint. In the tests, adding a different VCN to the access list did not remove the condition. This does not mean access lists are irrelevant in every configuration; it means they did not replace the observed gateway-VCN membership condition in this deployment. This is not a test with a VM originating in VCN B: source_vcn = A, pe_vcn = A, and egress_sgw_vcn = B all hold simultaneously. The no-SNAT firewall preserves the source but does not turn SGW-B into SGW-A.

HTTP 403 and the Oracle Net error are different outcomes. The application response proves that a service responder was reached; hop reconstruction refers to the controlled test path, not to the HTTP code in isolation. No rejection is attributed to the firewall or Service Gateway without supporting evidence.

Transient observation on name/destination binding. In a separate test, a Load Balancer in the same VCN received a request built with the private name and used as backend the public OSN address associated with that name in Oracle public resolution. The forced path worked for approximately one hour, then stopped working; on the SGW path, the HTTPS surface using the intended public access URL remained usable. The episode is recorded as a transient observation, not as a supported SQL*Net alternative and not as a guarantee of propagation timing. The observation alone does not identify which internal DNS or enforcement update caused the change.

The census therefore keeps separate rows for successful private SQL, rejected SQL-via-SGW attempts, successful HTTPS via SGW-A, service-side rejection for HTTPS through transit/SGW-B, and the transient name-binding observation. Connection outcomes are not an overall security verdict. The stable conclusion for the described deployment is explicit: SQL*Net/TCPS through the PE; HTTPS/web through SGW only with Allow public access and an SGW in the VCN associated with the PE.

Oracle documentation for configuration and ports: Configure Network Access with Private Endpoints. Source of the specific outcomes: author tests, subsequently confirmed with Oracle specialist engineering.

10.4 Functions: Management, Invocation, and Runtime Application Networking

Functions repeats the same principle across three planes.

Management API: SGW yes; PSA not listed in the current matrix.

Invocation: SGW yes; PSA yes. Project materials also include PSA runtime evidence for functions-invocation. The record must capture the actual invokeEndpoint value rather than reconstructing it from a regional name alone. Oracle shows an assigned-prefix hostname and a full URL whose path contains /20181201/functions/<function-ocid>/actions/invoke: host, Function OCID, and operation are different coordinates. The prefix is not interpreted as a tenancy or application identifier without a specific source. With SDK clients, the distinction between the base service endpoint and the complete invocation URL is also preserved.

Oracle source: Invoking Functions.

Application networking: the subnet/application-networking configuration governs runtime connectivity and dependencies. It is not a native client-addressable invocation Private Endpoint.

When API Gateway uses a Function as backend, Oracle documents its own contract: a private API Gateway reaches Functions through Service Gateway; a public API Gateway uses Internet Gateway. The broader PSA capability of the invocation service is not substituted into that managed backend contract by analogy.

Figure F50 — "Private" is direction-specific: four managed-service contracts.

OIC separates design-time/runtime inbound surfaces from outbound connections through Private Endpoint; the OIC Private Endpoint is outbound only, while design-time and runtime use distinct URLs. OAC separates inbound public/private deployment from the outbound Private Access Channel; an allowed VCN can reach an OAC public endpoint through Service Gateway without traversing the Internet. ADB keeps Database Service API, SQL private endpoint, and HTTPS/web surfaces separate: the specific SQL/HTTPS outcomes remain author field evidence detailed in F51, not deductions from general documentation. Functions keeps management API, direct invocation, and application networking distinct; the invoke endpoint carries the Function OCID in the path, while runtime connectivity derives from the application's subnets. No inbound property is automatically transferred to outbound traffic, and no invocation capability is inherited by management.

Figure F51 — One database, four outcomes, two VCNs.

The source VM and Private Endpoint remain in VCN A. The valid SQL path terminates on the PE; SQL through SGW is rejected even when using SGW-A. HTTPS toward the public access URL works through SGW-A, while transit through the no-SNAT firewall and SGW-B reaches ADB and receives HTTP 403. The decisive condition is the VCN of the gateway actually traversed, not only the VM VCN or access list. Management API and the transient Load Balancer observation remain separate planes.

Table 25 — Direction, FQDN, and Private-Access Contract Across Four Services

Oracle sources and project evidence: https://docs.oracle.com/en/cloud/paas/application-integration/rest-api/SendRequests.html https://docs.oracle.com/en-us/iaas/application-integration/doc/private-endpoints.html https://docs.oracle.com/en-us/iaas/application-integration/doc/configure-custom-endpoint-instance.html https://docs.oracle.com/en-us/iaas/analytics-cloud/doc/private-endpoints.html https://docs.oracle.com/en-us/iaas/analytics-cloud/doc/public-endpoints-and-access-control-rules.html https://docs.oracle.com/en-us/iaas/analytics-cloud/doc/private-access-channels.html https://docs.oracle.com/en-us/iaas/autonomous-database-serverless/doc/private-endpoints-autonomous.html https://docs.oracle.com/en-us/iaas/Content/APIGateway/Tasks/apigatewayusingfunctionsbackend.htm

11. DNS, Private Views, and Address Family Are Part of the Endpoint Contract

An FQDN class is incomplete unless the record also states who resolves it, against which view, and into which address family. The same string may carry a private meaning only for a specific DNS population; a new private-endpoint resource may create private DNS zones; an on-premises client may require forwarding toward a VCN resolver; IPv4 and IPv6 may lead to different endpoint families.

PSA is explicit on this point. Oracle assigns a private IP and FQDN in the VCN to the PSA endpoint. To let on-premises clients use that FQDN, Oracle proposes a DNS listening endpoint or manual hostname-resolution management. The record must therefore contain not only the name but at least:

resolver population
DNS view / zone
answer type
resolved address
address family
source scope
observation timestamp

resolver population
DNS view / zone
answer type
resolved address
address family
source scope
observation timestamp

Object Storage added another dimension through dual-stack endpoints, announced in the 11 August 2026 release note: they use the Dedicated Endpoint format. In the OC1 commercial realm, the documentation distinguishes traditional oraclecloud.com IPv4-only endpoints from dual-stack dedicated endpoints under ds.oci.customer-oci.com. Private Endpoints and virtual-hosted style are excluded from the dual-stack support described on that page.

This means IPv6 enabled cannot be a product-level attribute. It is a property of the exact endpoint form.

Another example is the OAC Private Endpoint. Oracle requires private DNS resolution to reach the private OAC URL from the VCN or on-premises. Here the DNS population is part of the inbound access contract.

For OIC outbound Private Endpoint, by contrast, the private-DNS question concerns the private targets reached by the OIC runtime. The same expression "private endpoint" therefore creates opposite DNS responsibilities in OAC and OIC.

Figure F52 — DNS context selects an address, not an authorized route.

The same QNAME is compared across a VCN where the relevant PSA mapping is visible, a VCN where that mapping or an applicable forwarding rule is absent in the illustrated example, and on-premises with forwarding toward a listening endpoint. The second VCN still has its default view; it is not a VCN "without private DNS." Oracle's resolution order distinguishes views, rules, and public recursion, and a negative answer may stop the sequence. IPv4/IPv6 support belongs to the exact endpoint. OAC inbound and OIC private-endpoint outbound carry different DNS responsibilities. The arrows describe resolution; peer selection, application path, and authorization require separate evidence. Section 11.1 separates this lane from a corporate-DNS record used for OAC and from upstream resolution performed by a proxy in OCI; proxy bypass, DNS, and routing are not the same configuration.

11.1 Corporate DNS, proxy bypass and proxy-side resolution

The on-premises lane in F52 illustrates one conditional-forwarding configuration, not a universal prerequisite. Queries for the configured name or suffix are forwarded by corporate DNS toward the OCI listening endpoint, and the answer returns to the corporate resolver. This is not automatic transfer of OCI private zones into on-premises. DNS resolves the service hostname, not a complete URL with scheme and path. Oracle — Private DNS.

Corporate DNS record — OAC private ingress. In the OAC case described by the author, that forwarding was not present. Instead, a request to the corporate DNS operator allowed a custom FQDN under the enterprise domain to be published and resolved to the OAC private IP. The on-premises client, or a client connected to the corporate network through VPN, used central DNS without modifying its local hosts file. The exact record type used in that evidence is not specified and is therefore not reconstructed. In general, an A record may provide the address; a CNAME requires its target to be resolvable as well. Oracle requires name resolution for private OAC and, for a vanity URL, DNS mapping toward the instance address. Oracle — OAC Private Endpoints · Oracle — Vanity URL Prerequisites.

Proxy bypass is not a route. In the described environment, the enterprise suffix was already excluded from the corporate proxy: the client opened the private connection to OAC over the configured FastConnect connectivity. Resolution, proxy exclusion, and routing are three different configurations. Bypass removes corporate-proxy mediation; it does not bypass firewalls or controls on the private path. The custom name also does not replace the vanity configuration and matching TLS certificate on the OAC service. Oracle — Configure a Vanity URL.

Corporate proxy versus OCI proxy. In the same environment, OCI APIs using public addresses followed the corporate proxy rather than the FastConnect path. That describes the customer configuration, not an OCI prohibition: Oracle documents on-premises access to public OSN service IPs through FastConnect private peering or VPN and transit through a VCN/SGW. Oracle — Service Gateway.

In the variant with a private proxy in OCI, the client must first reach the proxy. When the request delivers the service hostname to the proxy and the selected mode calls for upstream resolution, the proxy process resolves the upstream target in its own DNS context. Merely placing the proxy in the VCN is not enough: which resolver it actually uses and which mappings it can see must be verified. For Squid, configuration references distinguish system resolvers from optional overrides; product version and mode remain part of the record. Squid — DNS Nameservers.

The two reference outcomes remain separate:

Proxy DNS result = supported regional OSN service public IP
Upstream path = Proxy -> FW-C -> SGW -> Oracle service

Proxy DNS result = relevant PSA private IP
Upstream path = Proxy -> FW-C -> PSA endpoint -> Oracle service

Proxy DNS result = supported regional OSN service public IP
Upstream path = Proxy -> FW-C -> SGW -> Oracle service

Proxy DNS result = relevant PSA private IP
Upstream path = Proxy -> FW-C -> PSA endpoint -> Oracle service

The first branch requires a supported service and the appropriate OSN route: not every public IP uses SGW. The second requires the relevant PSA mapping to be visible to the proxy resolver and private routing toward that endpoint; SGW is not a subsequent hop after PSA. DNS does not impose firewall traversal: routing must make the inspection point required by the foundation mandatory. Oracle — PSA DNS Mapping · Oracle — PSA Endpoints.

The ability of the proxy to resolve the upstream target does not prove source preservation. The F-H02 evidence states remain unchanged: existing double traversal is tested; the source-preserving proxy variant on another subnet in the same VCN was considered plausible by specialist engineering but has not been validated. The branches above are design requirements for that variant, not new tests. The exception for the identified Oracle-managed dependencies remains separate as well.

For each case the Flow Atlas retains requested hostname, resolving subject, effective resolver and answer, direct/proxy selection, selected proxy, upstream peer, and observed route. A corporate DNS record may replace forwarding for a particular name; neither mechanism alone proves the application path or authorization.

Table 26 — DNS and Address-Family Fields the Census Must Preserve

Oracle sources: https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/private-service-access.htm https://docs.oracle.com/en-us/iaas/analytics-cloud/doc/private-endpoints.html https://docs.oracle.com/en-us/iaas/Content/Object/Concepts/use-ipv6-urls.htm

12. Discriminator Locality: What the Name Does Not Say Must Be Recorded Elsewhere

The conclusion of the preceding chapters is not that "the more specific the FQDN, the more secure the service." The correct conclusion is that discriminator locality changes.

For a regional OCIR FQDN, the tenancy namespace and repository remain in the request target. For a dedicated Object Storage FQDN, the namespace moves into the name while bucket/object remain deeper. For a native Object Storage Private Endpoint, the private address/FQDN identifies the PE and its access-target context, while the specific object operation remains service-side. For ADB private SQL, the endpoint identifies the database resource while service_name and database user remain inside protocol/database authority. For OIC design-time, the instance discriminator is in the parameter; at runtime it moves into the FQDN; the integration route remains deeper still.

The census does not yet decide whether a firewall, API Gateway, or service-native policy can enforce that distinction. It makes the fact available to Module III.

A useful recording scheme is:

D0  region/service
D1  tenancy/namespace
D2  instance/resource endpoint
D3  application route/path/resource selector
D4  credential / signed target / service-native identity
D5  database/application semantic object

D0  region/service
D1  tenancy/namespace
D2  instance/resource endpoint
D3  application route/path/resource selector
D4  credential / signed target / service-native identity
D5  database/application semantic object

This scale is not a score and does not measure "security." It exists only to make flows comparable when their targets become distinguishable at different levels.

SNI also enters the record as an observed field, not as a synonym for target. If the FQDN is regional and shared, SNI remains regional. If the namespace is present in the dedicated FQDN, SNI carries that namespace as well. If the request traverses a TLS terminator, the downstream leg may have a new server identity. If the protocol does not use SNI or the client selects another endpoint form, the field must be populated accordingly.

The methodological requirement is concrete: the Flow Atlas must prevent the sentence "the firewall sees the FQDN" unless the record also states which FQDN and which target that string actually identifies.

13. Object Storage: The Reference Service for Separating FQDN, Path, Namespace, Resource, and Capability

Visual references: Figures F53–F54; Tables 27–28.

Object Storage is the most useful service for stress-testing the entire method because multiple endpoint contracts with different properties coexist inside one product. Treating it as one row, Object Storage = private, destroys exactly the distinctions the Flow Atlas is designed to preserve.

The principal surfaces relevant to this block are:

1. traditional regional endpoint;
2. dedicated namespace-specific endpoint;
3. S3 compatibility endpoint;
4. PSA endpoint;
5. Object Storage Private Endpoint;
6. capability artifacts such as Pre-Authenticated Requests, which are not endpoints but change how a request is authorized;
7. dual-stack dedicated endpoint, introduced as an IPv4/IPv6 form in 2026.

The first point to establish is that naming depth and network path are independent coordinates. The traditional endpoint objectstorage.<region>.oraclecloud.com is regional. The dedicated endpoint moves the namespace into the hostname. The PSA endpoint uses a private IP/FQDN in a subnet. The resource Private Endpoint uses another private FQDN/private IP and may have access targets. Four surfaces, four rows.

13.1 Traditional Regional Endpoint: The Name Does Not Contain the Tenancy

The traditional form:

objectstorage.<region>.oraclecloud.com

objectstorage.<region>.oraclecloud.com

identifies the service and region. The namespace is not in the name. Bucket, object key, version, and operation remain in the request.

This surface may be reached through Service Gateway from a VCN when the routing/security contract permits it. The fact that traffic does not traverse the Internet does not change the nature of the regional service FQDN. It remains a service surface shared by the region.

For the Flow Atlas:

FQDN class            = Regional
FQDN scope            = service + region
reachability family   = SGW / other supported public-service paths
semantic target       = namespace / bucket / object
deeper discriminator  = request target

FQDN class            = Regional
FQDN scope            = service + region
reachability family   = SGW / other supported public-service paths
semantic target       = namespace / bucket / object
deeper discriminator  = request target

The row does not conclude whether that target can be confined by a candidate PEP. It records only that the target is not named by the FQDN.

13.2 Dedicated Endpoint: The Namespace Moves into the Hostname

Oracle Object Storage Dedicated Endpoints assign tenancy-specific endpoints that include the namespace. The recommended native-API form is:

<namespace>.objectstorage.<region>.oci.customer-oci.com

<namespace>.objectstorage.<region>.oci.customer-oci.com

This choice moves the namespace into destination identity. TLS SNI built from that hostname can therefore distinguish the namespace without decrypting the request path.

The bucket remains deeper. A dedicated endpoint is not a bucket endpoint. Nor is it a private IP: Oracle documents that dedicated endpoints, like traditional endpoints, resolve to public Object Storage IPs. The difference is tenancy-specific name identity.

From a census perspective:

endpoint class         = Dedicated / namespace-specific
address class          = Object Storage public service IP
FQDN discriminator     = tenancy namespace
deeper discriminator   = bucket/object/version

endpoint class         = Dedicated / namespace-specific
address class          = Object Storage public service IP
FQDN discriminator     = tenancy namespace
deeper discriminator   = bucket/object/version

The same tenancy may have multiple API forms: native, S3 compatibility, and Swift. These forms merit separate rows whenever protocol/request semantics change.

13.3 S3 Compatibility: Namespace in the Name Does Not Mean Native API Semantics

The traditional S3-compatible form already carries the namespace:

<namespace>.compat.objectstorage.<region>.oraclecloud.com

<namespace>.compat.objectstorage.<region>.oraclecloud.com

The dedicated form uses the oci.customer-oci.com domain. In both cases the hostname is deeper than the regional native endpoint, while request semantics follow the S3-compatible protocol.

This is another non-inheritance example: "namespace visible in the FQDN" says nothing about whether operations, headers, checksums, and signing semantics are identical to the native Object Storage API.

The Flow Atlas must therefore record:

plane            = object data
protocol family  = S3 compatibility
FQDN class       = namespace-specific
target           = bucket/object
auth semantics   = S3-compatible request/auth model

plane            = object data
protocol family  = S3 compatibility
FQDN class       = namespace-specific
target           = bucket/object
auth semantics   = S3-compatible request/auth model

13.4 PSA: Private Service/API Path with Object Storage-Specific Behavior

Object Storage is the case in which Oracle documents a PSA property substantially stronger than simple reachability. Current documentation states that the Object Storage PSA endpoint blocks:

• cross-tenancy Pre-Authenticated Requests;
• foreign credentials;
• anonymous access.

This is a service-side property. It is not inferred from the private IP and is not extended to other PSA services.

Oracle recommends PSA for many Object Storage use cases because it provides region-wide private access without depending on public endpoints and adds security features such as metrics and ZPR attributes. Private Endpoint remains indicated where finer access targets are required for specific namespaces, compartments, or buckets.

For the census this produces two coordinates:

endpoint_contract      = PSA
service/API            = Object Storage
address                = private IP
credential behavior    = Oracle-documented Object Storage PSA behavior
semantic target        = namespace/bucket/object

endpoint_contract      = PSA
service/API            = Object Storage
address                = private IP
credential behavior    = Oracle-documented Object Storage PSA behavior
semantic target        = namespace/bucket/object

The final field remains necessary because the PSA service surface does not become per-bucket.

13.5 Object Storage Private Endpoint: A VNIC with Access Targets

Oracle documents Private Endpoint as a VNIC with a private IP in the customer's subnet. The endpoint creates private DNS FQDNs, for example:

pe1-<namespace>.private.objectstorage.<region>.oci.customer-oci.com

pe1-<namespace>.private.objectstorage.<region>.oci.customer-oci.com

and separate forms for S3 compatibility and Swift.

The endpoint may have up to ten access targets, each of which may specify namespace, compartment, and bucket. It is therefore more resource-aware than PSA.

Two caveats must remain in the same chapter.

First: access target is not an IAM grant. Oracle continues to authorize requests through IAM.

Second: Private Endpoint does not make that path exclusive. Oracle explicitly states that buckets may still be reached through other methods; IAM/Network Source must be used when origin restriction is required.

Those two properties make Private Endpoint especially useful for the Flow Atlas: it carries more semantic target information into the network object without removing the authorization layer.

Figure F53 — Object Storage endpoint names and access paths.

Panel A separates SGW, PSA, and resource Private Endpoint as alternative mechanisms; Panel B distinguishes traditional, dedicated, S3-compatible, and dedicated dual-stack names in the OC1 commercial realm. The name family alone does not prescribe a NAT or SGW route. The resource PE leads to its access-target scope, not to a public dual-stack endpoint, and IAM continues to authorize the request. The figure does not prove that alternate surfaces are closed.

Sources: Object Storage Dedicated Endpoints; Private Endpoints in Object Storage; Dual-Stack Endpoints and Support for IPv6; Private Service Access endpoints.

Path scope. Name family and access path remain distinct coordinates even when traffic traverses a hub firewall. The SGW path remains private over Oracle fabric and does not traverse PSA; the resource Private Endpoint is not connected to dedicated dual-stack. See Sections 0.1–0.7.

Table 27 — Object Storage Endpoint Forms

Oracle sources: https://docs.oracle.com/en-us/iaas/Content/Object/Concepts/dedicatedendpoints.htm https://docs.oracle.com/en-us/iaas/Content/Object/Tasks/private-endpoints.htm https://docs.oracle.com/en-us/iaas/Content/Object/Concepts/use-ipv6-urls.htm https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/private-service-access.htm

14. Object Storage Capability Artifacts: PAR Shows That Authorization and Path Binding Are Different Objects

A Pre-Authenticated Request is an excellent example of an object that must not be mistaken for a flow. A PAR is a capability artifact: it is created by an authorized principal, embeds a scope and an expiration time, and can subsequently be used by a client that does not present the same OCI credential as the creator.

The Flow Atlas must therefore create at least two rows:

PAR creation flow
PAR consumption flow

PAR creation flow
PAR consumption flow

and reference the same capability object from both.

The behavior changes again according to the endpoint contract.

For Object Storage PSA, Oracle documents the blocking of cross-tenancy PARs, foreign credentials, and anonymous access on the path that traverses the PSA endpoint. The qualifier cross-tenancy delimits the claim: the source does not establish a universal prohibition on every PAR and is not, by itself, sufficient to characterize same-tenancy PAR behavior. This is Object Storage-specific service behavior, not a property that may be transferred to every PSA-enabled service. Oracle — PSA, Service Specific Considerations: Object Storage.

For an Object Storage Private Endpoint, Oracle documents another important property: a PAR created through the Private Endpoint contains the private-endpoint FQDN, but the same PAR can be used from the public endpoint by replacing the private FQDN in the URL.

That behavior is a direct counterexample to the statement "the PAR is bound to the private path." It is not bound by construction. The capability remains valid on an alternate surface if the service accepts it.

The census therefore records:

capability_object        = PAR
creation_endpoint        = Private Endpoint
embedded_FQDN            = private PE FQDN
alternate_use_surface    = public Object Storage endpoint
authorization_semantics  = capability + service validation

capability_object        = PAR
creation_endpoint        = Private Endpoint
embedded_FQDN            = private PE FQDN
alternate_use_surface    = public Object Storage endpoint
authorization_semantics  = capability + service validation

The Private Endpoint continues to provide private reachability and access targets; the PAR nevertheless demonstrates that capability authorization is not automatically path binding.

14.1 Access Targets, Network Sources, and Capability Are Three Different Dimensions

Three mechanisms must not be compressed into one cell.

Access targets define what the Private Endpoint can reach.

IAM/Network Sources can constrain authorization according to origin.

A PAR is a capability that authorizes a specific operation/resource scope according to its own contract.

A design that uses all three must produce at least three evidence families. The Flow Atlas records the fields separately because a change to one does not automatically modify the others.

Figure F54 — Object Storage PAR: creation, capability and use paths.

C0 is the authorized request that creates capability C1; U1 and U2 are distinct use requests, not the same flow under different names. Oracle documents that a PAR created through a resource Private Endpoint can be used from the public endpoint by replacing the FQDN: the figure illustrates the alternate path through SGW without turning it into a measured PASS or rejection for the deployment. The PAR remains a capability: the consumer's failure to present an API signing key does not mean that no credential exists. Scope, expiration, capability state, and the creator's permissions remain relevant. Repeated representations of the PE and target do not indicate additional resources; the C1 box is not a network appliance. Centralized inspection and return paths are addressed in F-H01/F-H02. This figure does not show a PSA path: U1 uses the resource Private Endpoint and U2 uses the public endpoint through SGW. The documented blocking of cross-tenancy PARs through Object Storage PSA remains distinct; the public-endpoint twin does not demonstrate circumvention of the PSA control because that request uses another path. The alternate surface must itself be inventoried and governed separately. The public name alone does not certify the path: the effective DNS answer and request routing must be recorded.

Sources: Private Service Access — Object Storage-specific restrictions; Private Endpoints in Object Storage — Pre-Authenticated Request Behavior; Object Storage Pre-Authenticated Requests; Creating an Object Storage Pre-Authenticated Request.

Table 28 — Object Storage Access-Control Objects That Must Not Be Collapsed

15. OCIR and Artifact Registry: Same Region, Different Target, Different APIs

Visual reference: Figure F55; Table 29.

Although OCIR and Artifact Registry do not technically belong to the Object Storage family, including them in this first block is useful because they form the nearest counterexample: they are artifact/content-storage services in which the regional endpoint remains shallower than the target.

15.1 OCIR: The Registry Host Is Not Repository Identity

An image reference contains several coordinates beyond the regional host:

<registry-host>/<tenancy-namespace>/<repository>:<tag>

<registry-host>/<tenancy-namespace>/<repository>:<tag>

or a digest.

The regional host identifies the registry service. Namespace and repository are carried in the reference/path.

This produces distinct exact flows even when the host is unchanged:

build runner -> repository A push
OKE node -> repository A pull
Functions service -> repository B managed pull
developer -> repository C pull

build runner -> repository A push
OKE node -> repository A pull
Functions service -> repository B managed pull
developer -> repository C pull

The principal, operation, and source process change; the regional FQDN can remain identical.

The current Oracle matrix states that OCI Container Registry supports Service Gateway and PSA. The census must record both private-access variants. Neither property, however, is described as a repository boundary.

15.2 Artifact Registry: Metadata/Control and Content Bytes Are Two API Surfaces

Oracle documents an explicit separation between:

• Artifacts and Container Images API;
• Generic Artifacts Content API.

The first manages repositories/metadata and container-image-related operations; the second is used to upload and download the actual content bytes of generic artifacts.

The SGW/PSA matrix assigns SGW + PSA to the first surface, whereas the Generic Artifacts Content API is SGW yes, PSA not listed.

A single "upload artifact" workflow can therefore generate at least:

metadata/repository operation -> PSA or SGW
content upload/download        -> SGW-only surface

metadata/repository operation -> PSA or SGW
content upload/download        -> SGW-only surface

The Oracle PL/SQL SDK reference directly documents the templates https://artifacts.{region}.oci.{secondLevelDomain} for the Artifacts and Container Images API and https://generic.artifacts.{region}.oci.{secondLevelDomain} for the Generic Artifacts Content API. In the commercial realm, the reference form is therefore artifacts.<region>.oci.oraclecloud.com for metadata/control and generic.artifacts.<region>.oci.oraclecloud.com for generic content. Container-image push/pull retains the distinct registry form <region-key>.ocir.io, documented for commercial realm OC1. This is not the only OCIR form: Oracle also documents <region>.ocir.io and recommends ocir.<region>.oci.oraclecloud.com. Those registry variants do not transfer to Generic Artifacts Content. region and region-key are not interchangeable. Container Registry Concepts.

The documented template does not replace the endpoint captured from the client. The row still preserves SDK/CLI version, region/realm, any service_endpoint override, and the hostname actually selected. An older capture remains dated evidence; it is not retroactively rewritten or treated as an alias of the current template without evidence. The Python SDK source reviewed confirms the Generic Artifacts Content template, but a moving branch does not identify the version installed in the estate. Repository ID, artifact path, and version remain deeper than the hostname.

Oracle sources: Overview of Artifact Registry; Artifacts Functions: endpoint parameter; Generic Artifacts Content Functions: endpoint parameter; GenericArtifactsContentClient.

Any figure or table that simply states "Artifact Registry = PSA" is technically false for the bytes-moving content flow.

Figure F55 — Registry, metadata and generic content are distinct surfaces.

The diagram separates the two PSA endpoints for Container Registry and the Artifacts API from the SGW branch, which in the consulted matrix also covers Generic Artifacts Content. Commercial-realm templates do not replace the client's effective endpoint; namespace, repository, artifact path, and version remain additional coordinates. The anti-exfiltration behavior documented for Object Storage is not transferred to these services. Sources: SGW/PSA matrix, Container Registry Concepts, Artifacts Functions, Generic Artifacts Content Functions.

Path scope. The graphical omission of the firewall does not exclude inspected transit in the landing zone. The SGW/PSA decision is made per exact API surface downstream of the prescribed network path. PSA endpoints for Container Registry and Artifacts API are distinct; Generic Artifacts Content does not inherit their PSA support. See Sections 0.1–0.7 and 15.2.

Table 29 — OCIR / Artifact Registry Exact-Flow Split

Oracle sources: https://www.oracle.com/cloud/networking/private-service-access/service-gateway-and-psa-supported-services/ https://docs.oracle.com/en-us/iaas/Content/Registry/Concepts/registryoverview.htm https://docs.oracle.com/en-us/iaas/Content/artifacts/overview.htm

16. File Storage: The Control Plane Is an API, the Data Plane Is an NFS Endpoint in the VCN

Visual reference: Figure F56; Table 30.

File Storage is the first service in this block that completely breaks the idea that "everything goes through a regional FQDN."

Oracle documents the mount target as an NFS endpoint that resides in a selected subnet. The mount target provides an IP address or DNS name and makes one or more file systems available through exports. The same mount target can be reused for multiple file systems, with an export for each.

The data-plane identity is therefore not:

filestorage.<region>.oraclecloud.com

filestorage.<region>.oraclecloud.com

but a combination of:

mount target IP/DNS
export path
NFS version/options
client source

mount target IP/DNS
export path
NFS version/options
client source

The control plane, by contrast, is managed through OCI APIs and can be reached privately through Service Gateway because File Storage API appears in the SGW matrix.

This produces at least two structurally different rows:

user/automation -> File Storage API
NFS client -> mount target -> export -> file system

user/automation -> File Storage API
NFS client -> mount target -> export -> file system

OCI File Storage supports NFSv3 and Network Lock Manager (NLM) for file locking. The variants to inventory arise from encryption mode, mount target, export, client, and applicable controls; they do not arise from NFSv4 support attributed to this service. The primary data-flow port does not exhaust the mount and locking dependencies.

Oracle source: Overview of File Storage.

16.1 Mount Target as Endpoint Identity

A mount target resides in the customer subnet and uses VNIC/network security. It is therefore much closer to a native resource endpoint than to a regional Oracle service FQDN.

Its identity is network-local:

private IP / private DNS
export path

private IP / private DNS
export path

The deeper semantic target is the file system/export/path.

The row must distinguish:

mount_target
export
file_system
client
protocol

mount_target
export
file_system
client
protocol

Successful access to the mount target does not prove that every export is available, and an available export does not state which file-system path the application uses.

16.2 In-Transit Encryption and Communication Profiles

In-transit encryption introduces a variant of the connection, not a new NFS protocol. The census preserves the client profile, mount target, direction, and relevant ports.

For the ordinary NFSv3 scenarios documented by Oracle, the client-to-mount-target profile includes TCP 111, 2048, 2049, and 2050, together with UDP 111 and 2048. For the scenario using in-transit TLS encryption, the documented destination on the mount target is TCP 2051. Client and mount-target rules, source ports, and export options must be consistent with the selected scenario; the profiles are not automatically merged into one broad rule. Any LDAPS or customer-managed DNS dependencies remain separate flows when the configuration requires them.

source                 = identified NFS client
destination            = identified mount target
scenario               = ordinary NFSv3 or in-transit TLS
destination_ports      = ports for the selected profile
source_port_policy     = value consistent with client and export
evidence               = configuration and observation of the relevant segment

source                 = identified NFS client
destination            = identified mount target
scenario               = ordinary NFSv3 or in-transit TLS
destination_ports      = ports for the selected profile
source_port_policy     = value consistent with client and export
evidence               = configuration and observation of the relevant segment

A network collector describes the segment it covers; by itself, it does not prove export, file path, NFS identity, or content. For an on-premises client, the source domain remains outside the VCN and the private transport to the mount target must be recorded separately.

Oracle sources: Configuring VCN Security Rules for File Storage; Using In-transit TLS Encryption.

Figure F56 — File Storage separates management, NFS access and observation.

The HTTPS call originates from the client/automation and reaches the management API through SGW; NFSv3 sessions reach the private mount target. The on-premises client is outside the Region and the file system is a managed resource associated through an export, not a VNIC in the subnet. NFSv3/RPC/NLM and TLS profiles remain separate. VCN Flow Logs do not prove file operations; the documented mount-target logs concern Kerberos/LDAP errors on Kerberos-enabled targets and do not constitute an audit trail for file or directory deletion. Sources: mount targets, network profiles, Logging for File Storage, VCN Flow Logs, Network Path Analyzer.

Path scope. The hybrid path represents the NFS destination, not every intermediate appliance: it can include the private hub firewall after the DRG. The HTTPS management request originates from the client/automation, not from the mount target; the NFS profile includes the dependencies described in Section 16.2. See also Sections 0.1–0.7.

Table 30 — File Storage and Block Volume: Control Plane and Data Plane

Oracle sources: https://docs.oracle.com/en-us/iaas/Content/File/Concepts/filestorageoverview.htm https://docs.oracle.com/en-us/iaas/Content/File/Tasks/managingmounttargets.htm https://docs.oracle.com/en-us/iaas/Content/Block/Concepts/overview.htm

17. Block and Boot Volume: The Storage Request Changes Identity When It Becomes I/O

Visual references: Figures F57–F58; Tables 30–31.

Block Volume highlights a different class of error: the control-plane API and the data path to the volume are not merely two endpoints; they are two transport models.

Oracle documents two attachment types for VMs:

• iSCSI;
• paravirtualized.

For bare metal, iSCSI is the standard documented path; for modern VMs, paravirtualized attachment is also available.

The management operation:

AttachVolume

AttachVolume

is an OCI API request made by an IAM principal.

The subsequent I/O is not a REST call to the Block Volume management endpoint. It is a device/attachment flow. The source identity is the instance/guest; the target is the volume attachment/device; the transport can be iSCSI or paravirtualized.

That distinction must be visible in the Flow Atlas because it changes almost every field:

plane
protocol
principal
source process
collector
target discriminator
lifecycle owner

plane
protocol
principal
source process
collector
target discriminator
lifecycle owner

An IAM policy that permits AttachVolume does not describe runtime I/O. For OCI Block Storage, core link-local traffic on 169.254.0.0/16 does not appear in VCN Flow Logs; therefore, the census does not assume a VCN-firewall trace or a flow record for each iSCSI operation. Attachment metadata and guest-session state describe different aspects and do not prove which principal authorized creation of the attachment. Control-plane operation and I/O remain correlated rows, not interchangeable evidence.

Oracle source: Details for VCN Flow Logs.

17.1 Boot Volume

Boot Volume is even more interesting because the volume participates in the lifecycle of the instance. Root-filesystem I/O belongs to the compute runtime path, whereas management, clone, backup, and restore remain control/service operations.

The census must therefore distinguish:

boot volume create/attach
boot device I/O
boot volume backup
restore/clone

boot volume create/attach
boot device I/O
boot volume backup
restore/clone

when those operations are materially in scope.

17.2 Multi-Attach and Source Population

When a volume supports multiple attachments, source_population becomes a decisive field. The volume resource is the same; its consumers are not.

One row for volume X would be too coarse. Separate rows are required for source/attachment families when principal, ownership, or path changes.

Figure F57 — Block and Boot Volume: API, device I/O and managed recovery.

Lane A represents caller requests to the Core Services APIs: SGW and PSA are alternate control-plane access mechanisms, not I/O paths. Lane B separates iSCSI and paravirtualized attachment contracts; device and volume do not become REST endpoints. Lane C represents, semantically, the managed backup to Object Storage and restoration into a new volume without inventing provider-internal hops or a path through a customer gateway. A backup can be requested by a caller or initiated according to a policy; execution of the transfers remains distinct from the request. Audit, attachment metadata, and guest evidence are not interchangeable. OCI Block Storage core link-local traffic on 169.254.0.0/16 does not appear in VCN Flow Logs: absence of a log record does not prove absence of I/O.

Sources: Overview of Block Volume; Block Volume Backups; Restoring a Backup to a New Volume; Restoring a Boot Volume; Details for VCN Flow Logs; Private Service Access and Service Gateway: Supported Cloud Services.

18. Backup and Recovery: Customer Request and Managed Transfer Are Distinct Flows

Backup is the first class in which the source process can be almost entirely service-managed.

Oracle Block Volume backup provides a clear example. A backup is an independent copy of volume data stored in Object Storage, with its own lifecycle. It can be created while the volume is attached or detached and can be restored into a new volume.

From the customer perspective, the operation can begin with a REST/API request:

CreateVolumeBackup

CreateVolumeBackup

but the byte transfer to Object Storage is service-managed.

If the Flow Atlas preserves only the API call, it loses the material data movement. If it preserves only "backup stored in Object Storage," it loses the principal that authorized creation.

At minimum, the following distinct rows are therefore required when present:

backup request/control flow
provider-managed data-copy flow
restore request/control flow
provider-managed restore flow
cross-region backup-copy flow, if used

backup request/control flow
provider-managed data-copy flow
restore request/control flow
provider-managed restore flow
cross-region backup-copy flow, if used

These rows do not yet receive lifecycle closure; that is later work. But they must exist.

18.1 Volume Group Backup: One Request Produces Multiple Data Relationships

A Volume Group Backup creates consistent backups of multiple volumes. source_population is therefore not a single volume but a group. The target is a backup-group object with relationships to multiple backup resources.

A diagram that merely states volume group -> backup hides:

• source volumes;
• source instances;
• region;
• backup policy;
• retention;
• restore destinations;
• any inter-region copy.

The Flow Atlas records ownership and the links between rows.

18.2 Retention and Ransomware-Resilient Backup Protection

The Oracle release note of August 11, 2026 introduces protection of Block Storage backups against early deletion and modification of the retention period, according to the configured mode. For the census, this is a lifecycle property to record on the backup, not an automatic verdict of resilience or compliance.

A backup row must therefore be able to record:

retention mode
retention lock
expiry
deletion eligibility
source region
copy region

retention mode
retention lock
expiry
deletion eligibility
source region
copy region

An immutable backup and a deletable backup are not necessarily the same lifecycle variant.

18.3 Recovery Service and Service-Managed Dependencies

Oracle Database Autonomous Recovery Service and other managed backup families will produce rows later in the database atlas. The lesson already visible here is that provider-managed does not mean out of scope.

The customer may not possess packet evidence for the transfer; the flow still exists and must record:

source_process = provider-managed
operational_owner = Oracle
customer_observability = partial/provider-only
documented_target = backup/recovery service

source_process = provider-managed
operational_owner = Oracle
customer_observability = partial/provider-only
documented_target = backup/recovery service

These rows become direct input to the Managed-Flow Boundary.

Figure F58 — Storage Flow Atlas synthesis: one estate, several exact-flow families.

The synthesis imposes no minimum cardinality: only rows materially present in the estate are instantiated. Object/registry keeps shared/dedicated, PSA, resource PE, OCIR, and Generic Artifact Content as separate contracts; File Storage separates the management API and mount-target NFSv3, including the TLS profile when adopted; Block/Boot Volume separates the control API, iSCSI, paravirtualized I/O, and service-managed backup/restore transfers. Oracle documents iSCSI and paravirtualized as distinct attachment contracts and restore from backup as an operation that creates a new volume. Endpoint, attachment, control request, and provider-managed transfer are not interchangeable records; the collector must be selected against the exact plane.

Table 31 — Storage Exact-Flow Handoff Matrix

19. First-Block Convergence: What the Census Can Now Distinguish

At this point, the census has enough structure to undergo a first convergence test. Three technical domains are now linked in the same model:

1. census unit and canonical row;
2. FQDN / endpoint anatomy, DNS, private-access contracts, and discriminator locality;
3. storage reference surfaces, including Object Storage, OCIR/Artifacts, File Storage, Block/Boot Volume, and backup.

The value of the merge is not quantitative. Its value is that the method is immediately tested against cases that force precision.

The regional OCIR FQDN demonstrates that endpoint identity can be shallower than repository identity.

Object Storage dedicated endpoints demonstrate that the namespace can move into the FQDN while the bucket remains deeper.

PSA demonstrates that private service/API reachability is a destination surface distinct from Service Gateway.

Object Storage Private Endpoint demonstrates that a private VNIC can incorporate access-target scope without replacing IAM.

OIC and OAC demonstrate that "private endpoint" can mean outbound in one product and inbound in another.

Autonomous Database demonstrates that control-plane PSA and the SQL data path are not the same thing, and that service_name remains a protocol coordinate.

File Storage demonstrates that the data plane can be an NFS mount target in the VCN rather than a regional API endpoint.

Block Volume demonstrates that a REST management operation and subsequent storage I/O do not belong to the same transport model.

Backup demonstrates that a material data flow can exist even when the customer does not directly originate the transfer.

These are not exceptions. They are the reason the Flow Atlas must exist.

The result is not a decorative taxonomy: the canonical record survives surfaces where naming, protocol, private reachability, target, and ownership actually change. That is the minimum condition for extending the Flow Atlas to other service families without starting again from the product name each time.

20. Six Worked Cases: The Theory Must Survive Concrete Records

The fastest way to determine whether the Flow Atlas is actually usable is to populate complete records for cases that look similar at product level but diverge on FQDN, source, path, or authority. The following six examples are not decorative templates: they expose the fields that become indispensable when the same platform offers multiple surfaces.

20.1 OCIR Image Pull via Service Gateway

The first flow originates from a compute instance, OKE node, or managed runtime that needs to retrieve an image from OCIR.

flow_id: FA-OCIR-CONTENT-PULL-SGW-01
service_family: OCI Container Registry
plane: content / image pull
source_process: container runtime
principal: <approved principal or auth-token identity>
protocol: HTTPS
fqdn_class: regional
fqdn: <region-key>.ocir.io
semantic_target: <tenancy-namespace>/<repository>@sha256:<digest>
target_discriminator:
  - tenancy namespace
  - repository
  - digest
discriminator_location: request path / registry protocol
forwarding_family: Service Gateway
collector_applicability:
  - DNS evidence
  - VCN Flow Logs
  - registry/IAM evidence
source_date: <source_date>

flow_id: FA-OCIR-CONTENT-PULL-SGW-01
service_family: OCI Container Registry
plane: content / image pull
source_process: container runtime
principal: <approved principal or auth-token identity>
protocol: HTTPS
fqdn_class: regional
fqdn: <region-key>.ocir.io
semantic_target: <tenancy-namespace>/<repository>@sha256:<digest>
target_discriminator:
  - tenancy namespace
  - repository
  - digest
discriminator_location: request path / registry protocol
forwarding_family: Service Gateway
collector_applicability:
  - DNS evidence
  - VCN Flow Logs
  - registry/IAM evidence
source_date: <source_date>

The record immediately exposes a property that the diagram node -> OCIR cannot express: the source can be authorized to reach the regional registry FQDN and still select a different repository. forwarding_family = Service Gateway describes only the path. It does not change the fact that the repository lies deeper.

A second row, FA-OCIR-CONTENT-PULL-PSA-01, can carry the same semantic target and the same source process while using a different endpoint contract and forwarding family. The presence of PSA therefore creates a new exact flow even when the application operation remains pull.

This is a case where the materiality rule yields a clear decision: SGW and PSA are not two runtime identifiers of the same row. They change the endpoint contract and candidate PEP set, and therefore require distinct Flow IDs.

20.2 Generic Artifact Content Upload: Same Commercial Family, Different API

A build runner publishes a generic artifact. The repository is managed through the Artifacts and Container Images API, while the content bytes are transferred through the Generic Artifacts Content API.

The content-flow record can be represented as:

flow_id: FA-ARTIFACT-CONTENT-UPLOAD-SGW-01
service_family: Artifact Registry
plane: generic artifact content
source_process: build/release runner
operation: upload artifact bytes
protocol: HTTPS
endpoint_contract: Generic Artifacts Content API
fqdn_class: regional
fqdn: <effective_client_hostname>
documented_template: https://generic.artifacts.{region}.oci.{secondLevelDomain}
commercial_template: https://generic.artifacts.<region>.oci.oraclecloud.com
client_version: <SDK_or_CLI_version>
realm: <realm>
region: <region>
service_endpoint_override: <absent_or_configured_value>
endpoint_capture_time: <timestamp>
semantic_target:
  repository_id: <repository-ocid>
  artifact_path: <path>
  artifact_version: <version>
forwarding_family: Service Gateway
psa_capability: not listed

flow_id: FA-ARTIFACT-CONTENT-UPLOAD-SGW-01
service_family: Artifact Registry
plane: generic artifact content
source_process: build/release runner
operation: upload artifact bytes
protocol: HTTPS
endpoint_contract: Generic Artifacts Content API
fqdn_class: regional
fqdn: <effective_client_hostname>
documented_template: https://generic.artifacts.{region}.oci.{secondLevelDomain}
commercial_template: https://generic.artifacts.<region>.oci.oraclecloud.com
client_version: <SDK_or_CLI_version>
realm: <realm>
region: <region>
service_endpoint_override: <absent_or_configured_value>
endpoint_capture_time: <timestamp>
semantic_target:
  repository_id: <repository-ocid>
  artifact_path: <path>
  artifact_version: <version>
forwarding_family: Service Gateway
psa_capability: not listed

The metadata row can instead use PSA. The product label is identical; the API surface is not. This is exactly the kind of difference that a Flow Atlas must preserve before anyone tries to apply a single "private access policy" to the entire Artifact Registry product.

20.3 Oracle Integration: Design-Time and Runtime Have Different Naming Depth

The design-time record:

flow_id: FA-OIC-DESIGN-ACCESS-SGW-01
plane: design-time
source_process: administrator browser / automation
protocol: HTTPS
fqdn_class: regional
fqdn: design.integration.<region>.ocp.oraclecloud.com
semantic_target:
  integration_instance: <instance>
  design_object: <integration|adapter|connection|flow>
target_discriminator:
  - integrationInstance
  - resource path / object identifier
forwarding_family: Service Gateway from allowed same-region VCN

flow_id: FA-OIC-DESIGN-ACCESS-SGW-01
plane: design-time
source_process: administrator browser / automation
protocol: HTTPS
fqdn_class: regional
fqdn: design.integration.<region>.ocp.oraclecloud.com
semantic_target:
  integration_instance: <instance>
  design_object: <integration|adapter|connection|flow>
target_discriminator:
  - integrationInstance
  - resource path / object identifier
forwarding_family: Service Gateway from allowed same-region VCN

The runtime record:

flow_id: FA-OIC-RUNTIME-INVOKE-SGW-01
plane: runtime inbound
source_process: application caller
protocol: HTTPS
fqdn_class: instance-specific
fqdn: <instance>.integration.<region>.ocp.oraclecloud.com
semantic_target:
  integration_route: <route>
  operation: <invoke operation>
endpoint_contract: original OIC runtime service endpoint
forwarding_family: Service Gateway from allowed VCN

flow_id: FA-OIC-RUNTIME-INVOKE-SGW-01
plane: runtime inbound
source_process: application caller
protocol: HTTPS
fqdn_class: instance-specific
fqdn: <instance>.integration.<region>.ocp.oraclecloud.com
semantic_target:
  integration_route: <route>
  operation: <invoke operation>
endpoint_contract: original OIC runtime service endpoint
forwarding_family: Service Gateway from allowed VCN

The naming-depth difference is immediate: design-time keeps the instance selector outside the hostname; runtime incorporates it into the service host. Neither surface is the OIC outbound Private Endpoint. The runtime record above describes the SGW path to the original endpoint; a custom endpoint or public/Internet access requires separate variants when materially present, not alternate values in the same forwarding field.

The third record, outbound, changes direction entirely:

flow_id: FA-OIC-RUNTIME-CONNECT-OUTBOUND_PE_SAP-01
plane: runtime outbound
source_process: OIC managed runtime
endpoint_contract: OIC outbound Private Endpoint
semantic_target: private SAP/API/DB target
dns_population: OIC private-endpoint VCN
forwarding_family: private VCN routing

flow_id: FA-OIC-RUNTIME-CONNECT-OUTBOUND_PE_SAP-01
plane: runtime outbound
source_process: OIC managed runtime
endpoint_contract: OIC outbound Private Endpoint
semantic_target: private SAP/API/DB target
dns_population: OIC private-endpoint VCN
forwarding_family: private VCN routing

Three rows for the same product, all indispensable.

20.4 OAC: Public/Private Is an Inbound Deployment Contract

OAC must not be modeled with the same semantics as OIC.

A public OAC deployment can define access-control rules that admit a VCN; Oracle documents that traffic from that VCN reaches OAC through Service Gateway. The FQDN remains the public OAC service surface.

flow_id: FA-OAC-INGRESS-ACCESS-PUBLIC_SGW-01
plane: user/runtime ingress
endpoint_contract: OAC public endpoint
source_population: allowed VCN
forwarding_family: Service Gateway
authorization_context: OAC access-control rule + application identity

flow_id: FA-OAC-INGRESS-ACCESS-PUBLIC_SGW-01
plane: user/runtime ingress
endpoint_contract: OAC public endpoint
source_population: allowed VCN
forwarding_family: Service Gateway
authorization_context: OAC access-control rule + application identity

A private OAC deployment instead creates a native inbound Private Endpoint:

flow_id: FA-OAC-INGRESS-ACCESS-PRIVATE_PE-01
endpoint_contract: OAC native Private Endpoint
dns_view: private
source_population:
  - VCN
  - on-prem via private connectivity
forwarding_family: private VCN/on-prem routing

flow_id: FA-OAC-INGRESS-ACCESS-PRIVATE_PE-01
endpoint_contract: OAC native Private Endpoint
dns_view: private
source_population:
  - VCN
  - on-prem via private connectivity
forwarding_family: private VCN/on-prem routing

The PAC is a third exact flow, in the outbound direction:

flow_id: FA-OAC-OUTBOUND-CONNECT-PAC_DATASOURCE-01
plane: outbound data-source access
source_process: OAC managed runtime
endpoint_contract: Private Access Channel
semantic_target: private DB or private Git

flow_id: FA-OAC-OUTBOUND-CONNECT-PAC_DATASOURCE-01
plane: outbound data-source access
source_process: OAC managed runtime
endpoint_contract: Private Access Channel
semantic_target: private DB or private Git

A single OAC <-> VCN diagram cannot substitute for these records.

20.5 Autonomous Database: Four Records for the Private Endpoint Deployment

The database shows why the record must state what the hostname identifies and where the semantic target remains. In Oracle Net, CONNECT_DATA.service_name selects the database service; database user, schema, and role remain separate coordinates. In the tests described in Section 10.3, protocol and Service Gateway VCN also change request admission.

The following records translate that topology into the census model. They report the outcomes described by the author and subsequently confirmed by Oracle specialist engineering; runtime timestamps, identifiers, and references to individual artifacts must be associated with the corresponding execution and must not be inferred from the publication date.

flow_id: FA-ADB-SQL-CONNECT-PE_TCPS-01
plane: SQL data
source_process: SQL client
source_vcn: A
pe_vcn: A
adb_network_mode: Private Endpoint
allow_public_access: true
endpoint_contract: ADB native Private Endpoint
protocol: TCPS
port: 1521
tls_mode: TLS
fqdn: <ADB_private_hostname>
destination_address: <PE_private_IP>
forwarding_family: private VCN routing
semantic_target:
  service_name: <descriptor_service_name>
  database_user: <database_user>
observed_result: connection succeeded
evidence_references:
  - evidence_class: PROJECT-OBSERVED
    origin: author field test
  - evidence_class: ORACLE-ENGINEERING-CONFIRMED
    origin: confirmation by Oracle specialist engineering
observation_time: <test_timestamp>

flow_id: FA-ADB-SQL-CONNECT-PE_TCPS-01
plane: SQL data
source_process: SQL client
source_vcn: A
pe_vcn: A
adb_network_mode: Private Endpoint
allow_public_access: true
endpoint_contract: ADB native Private Endpoint
protocol: TCPS
port: 1521
tls_mode: TLS
fqdn: <ADB_private_hostname>
destination_address: <PE_private_IP>
forwarding_family: private VCN routing
semantic_target:
  service_name: <descriptor_service_name>
  database_user: <database_user>
observed_result: connection succeeded
evidence_references:
  - evidence_class: PROJECT-OBSERVED
    origin: author field test
  - evidence_class: ORACLE-ENGINEERING-CONFIRMED
    origin: confirmation by Oracle specialist engineering
observation_time: <test_timestamp>

The SQL attempt through SGW is another row, even when the source remains in the same VCN:

flow_id: FA-ADB-SQL-CONNECT-PUBLIC_SGW_A-01
plane: SQL data
source_vcn: A
pe_vcn: A
egress_sgw_vcn: A
adb_network_mode: Private Endpoint
allow_public_access: true
endpoint_contract: ADB public SQL surface
protocol: TCPS
port: <1521_or_1522_for_the_individual_attempt>
tls_mode: <descriptor_mode_for_the_individual_attempt>
forwarding_family: Service Gateway
observed_result: connection rejected
observed_errors:
  - DPY-6000
  - ORA-12529
rejection_origin: ADB service-side, not Service Gateway
observation_time: <test_timestamp>

flow_id: FA-ADB-SQL-CONNECT-PUBLIC_SGW_A-01
plane: SQL data
source_vcn: A
pe_vcn: A
egress_sgw_vcn: A
adb_network_mode: Private Endpoint
allow_public_access: true
endpoint_contract: ADB public SQL surface
protocol: TCPS
port: <1521_or_1522_for_the_individual_attempt>
tls_mode: <descriptor_mode_for_the_individual_attempt>
forwarding_family: Service Gateway
observed_result: connection rejected
observed_errors:
  - DPY-6000
  - ORA-12529
rejection_origin: ADB service-side, not Service Gateway
observation_time: <test_timestamp>

Ports remain fields of the individual execution. TLS on 1522 and mTLS on 1522 do not become the same variant merely because they share a port.

flow_id: FA-ADB-WEB-ACCESS-PUBLIC_SGW_A-01
plane: HTTPS web tools
source_vcn: A
pe_vcn: A
egress_sgw_vcn: A
adb_network_mode: Private Endpoint
allow_public_access: true
endpoint_contract: ADB public HTTPS tools surface
fqdn: <public_access_URL_hostname>
protocol: HTTPS
port: 443
forwarding_family: Service Gateway
observed_result: access succeeded
observation_time: <test_timestamp>

flow_id: FA-ADB-WEB-ACCESS-PUBLIC_SGW_A-01
plane: HTTPS web tools
source_vcn: A
pe_vcn: A
egress_sgw_vcn: A
adb_network_mode: Private Endpoint
allow_public_access: true
endpoint_contract: ADB public HTTPS tools surface
fqdn: <public_access_URL_hostname>
protocol: HTTPS
port: 443
forwarding_family: Service Gateway
observed_result: access succeeded
observation_time: <test_timestamp>

The transit variant does not change the VCN of the VM or PE; it changes the VCN of the gateway used:

flow_id: FA-ADB-WEB-ACCESS-PUBLIC_SGW_B_TRANSIT-01
plane: HTTPS web tools
source_vcn: A
source_subnet: A1
pe_vcn: A
pe_subnet: A2
egress_sgw_vcn: B
adb_network_mode: Private Endpoint
allow_public_access: true
endpoint_contract: ADB public HTTPS tools surface
protocol: HTTPS
port: 443
forwarding_family: DRG transit routing to SGW-B
firewall_vcn: B
firewall_snat: false
observed_result: request reached ADB and was rejected service-side
http_status: 403
message_fragment: same private network
rejection_origin: ADB service-side, not firewall or Service Gateway
observation_time: <test_timestamp>

flow_id: FA-ADB-WEB-ACCESS-PUBLIC_SGW_B_TRANSIT-01
plane: HTTPS web tools
source_vcn: A
source_subnet: A1
pe_vcn: A
pe_subnet: A2
egress_sgw_vcn: B
adb_network_mode: Private Endpoint
allow_public_access: true
endpoint_contract: ADB public HTTPS tools surface
protocol: HTTPS
port: 443
forwarding_family: DRG transit routing to SGW-B
firewall_vcn: B
firewall_snat: false
observed_result: request reached ADB and was rejected service-side
http_status: 403
message_fragment: same private network
rejection_origin: ADB service-side, not firewall or Service Gateway
observation_time: <test_timestamp>

The optional admission of VCN B in an access list is a field of the test configuration; it does not change pe_vcn or egress_sgw_vcn. The four records therefore preserve both the result and the conditions that distinguish it from the other rows. The transient Load Balancer observation from Section 10.3 remains a separate time-bound piece of evidence; it is not converted into a fifth stable SQL mode.

20.6 Object Storage PE and PAR: A Capability That Survives an FQDN Change

The PAR-creation record:

flow_id: FA-OS-PAR-CREATE-PE-01
source_process: authorized client
endpoint_contract: Object Storage Private Endpoint
semantic_target: bucket/object
operation: create PAR
capability_output: <PAR>

flow_id: FA-OS-PAR-CREATE-PE-01
source_process: authorized client
endpoint_contract: Object Storage Private Endpoint
semantic_target: bucket/object
operation: create PAR
capability_output: <PAR>

The consumption record:

flow_id: FA-OS-PAR-CONSUME-PUBLIC-01
source_process: unauthenticated/capability client
endpoint_contract: public Object Storage endpoint
credential_type: PAR capability
semantic_target: same bucket/object

flow_id: FA-OS-PAR-CONSUME-PUBLIC-01
source_process: unauthenticated/capability client
endpoint_contract: public Object Storage endpoint
credential_type: PAR capability
semantic_target: same bucket/object

Oracle documents that the private FQDN in the PAR URL can be replaced by the public endpoint. The two records share the capability and target but not the path.

This example matters because it demonstrates a general census principle: the same authorization object can cross multiple endpoint contracts.

21. DNS, SNI, and Semantic Target: Three Identities That May Coincide or Diverge

One of the most frequent sources of error in OCI architectures is to treat the DNS name, TLS SNI, and semantic target as though they were three names for the same object. In some flows they almost coincide; in others they describe three different layers.

The DNS name is the name that a resolver converts into one or more address records.

SNI is the server name that a TLS client can send in ClientHello to select the virtual-host/certificate context.

The semantic target is what the operation actually intends to modify, read, or invoke.

A regional service endpoint can have:

DNS name        = <region-key>.ocir.io
SNI             = <region-key>.ocir.io
semantic target = namespace/repository/digest

DNS name        = <region-key>.ocir.io
SNI             = <region-key>.ocir.io
semantic target = namespace/repository/digest

An Object Storage dedicated endpoint can have:

DNS name        = <namespace>.objectstorage.<region>.oci.customer-oci.com
SNI             = same namespace-specific FQDN
semantic target = bucket/object

DNS name        = <namespace>.objectstorage.<region>.oci.customer-oci.com
SNI             = same namespace-specific FQDN
semantic target = bucket/object

A database private endpoint can have:

DNS name        = private database host
SNI             = database host, if the protocol/TLS stack uses it in that form
semantic target = service_name + database principal + operation

DNS name        = private database host
SNI             = database host, if the protocol/TLS stack uses it in that form
semantic target = service_name + database principal + operation

These differences must be present in the row before any future control can receive credit.

21.1 When DNS and SNI Are Not Enough

OCIR and Generic Artifacts are the reference case. The regional hostname can be perfectly stable and the client can present it in SNI, yet repository and artifact target remain in the application protocol.

If a network collector records:

src = 10.10.10.12
dst = <regional-registry-IP>
tcp = 443
sni = <region-key>.ocir.io

src = 10.10.10.12
dst = <regional-registry-IP>
tcp = 443
sni = <region-key>.ocir.io

it has observed the service surface. It has not yet observed:

namespace = X
repository = Y
digest = Z

namespace = X
repository = Y
digest = Z

The Flow Atlas therefore records both the network-visible identity and the deeper target fields. This discipline prevents the diagram from substituting what the architect knows from the requirement for what the collector cannot see.

21.2 When the Namespace Moves into SNI

An Object Storage dedicated endpoint moves one part of the target into the name:

<namespace>.objectstorage.<region>.oci.customer-oci.com

<namespace>.objectstorage.<region>.oci.customer-oci.com

The namespace is therefore available to DNS and SNI. This transformation matters because it changes the first point at which two tenancies become distinguishable.

The bucket, however, does not automatically move into the same field. The census must avoid the statement "dedicated endpoint = bucket isolation." The row says:

first tenancy discriminator  = FQDN/SNI
bucket discriminator         = request path/service semantics

first tenancy discriminator  = FQDN/SNI
bucket discriminator         = request path/service semantics

The same architecture can therefore contain two discriminator localities at the same time.

21.3 When DNS Changes the Path but Not the Semantic Target

PSA and native Private Endpoint expose another form of separation.

In the PSA model, DNS can resolve the service API to a private IP/FQDN in the VCN. The semantic target of the request can remain the same as on another access surface.

In the resource Private Endpoint model, DNS resolves to a VNIC/private IP associated with the resource or access-target context. The semantic target moves closer to the network, but operation and principal remain service-side.

This is why the record preserves:

fqdn_class
dns_view
resolved_address
endpoint_contract
semantic_target
target_discriminator

fqdn_class
dns_view
resolved_address
endpoint_contract
semantic_target
target_discriminator

as independent fields.

21.4 Custom FQDN: The Visible Name Is Not Necessarily the Origin

A custom endpoint creates a new visible identity without destroying the origin.

Oracle Integration documents this explicitly. The custom URL is reachable, but the original URL remains. At runtime the request can use the custom endpoint directly; other component surfaces can be redirected.

Therefore:

visible FQDN       = mycustom.example.org
mediating contract = OIC custom endpoint
origin             = original OIC service URL
semantic target    = integration route / operation

visible FQDN       = mycustom.example.org
mediating contract = OIC custom endpoint
origin             = original OIC service URL
semantic target    = integration route / operation

If the census recorded only the custom name, it would lose an alternate surface.

21.5 A Complete Record Preserves Uncertainty

Documentation does not always expose exactly which name appears in every TLS leg or every managed backend. The correct response is not to invent one.

The record can use:

sni = unknown / not documented
server_identity = documented certificate name
semantic_target = documented target
runtime_capture = required

sni = unknown / not documented
server_identity = documented certificate name
semantic_target = documented target
runtime_capture = required

An unknown cell is better than an SNI value inferred from the shape of a URL.

22. The Private-Access Spectrum Is Not a "More Secure" Scale: It Is a Scale of Different Binding

It is intuitive to place Service Gateway, PSA, and resource Private Endpoint on a line from "less private" to "more private." That model is too simple; the Flow Atlas replaces it with independent coordinates.

Service Gateway adds private reachability to public service IPs.

PSA adds private IP/FQDN for one service API.

Resource Private Endpoint adds a private address bound to a resource or access-target context.

A dedicated namespace FQDN adds tenant-specific naming while retaining public service IPs.

A custom endpoint adds customer-defined naming/fronting.

Each shifts a different property.

22.1 Service Gateway: Path Binding Without Resource-Specific Destination Identity

Service Gateway routes to regional public service IP ranges over Oracle fabric. A client can reside in a private subnet and avoid NAT/IGW, while the destination service remains regional/shared.

That is excellent for expressing:

source -> Oracle Services Network

source -> Oracle Services Network

and insufficient, by itself, to prove:

source -> only my repository

source -> only my repository

The Flow Atlas does not yet evaluate the second property; it records that the two properties are different.

22.2 PSA: Service/API Binding

PSA is more specific at the network-object level: private IP, FQDN, subnet, NSG/ZPR capability. Oracle nevertheless uses one PSA endpoint for a service API that can serve multiple resources.

Therefore:

network binding      = service/API endpoint in VCN
resource binding     = service-specific, not implied
credential boundary  = only where documented

network binding      = service/API endpoint in VCN
resource binding     = service-specific, not implied
credential boundary  = only where documented

Object Storage adds documented credential behavior. OCIR does not inherit it.

22.3 Dedicated FQDN: Naming Binding Without Private Addressing

The Object Storage dedicated endpoint demonstrates that tenant-specific naming does not require a private IP.

namespace in FQDN
public Object Storage service IP

namespace in FQDN
public Object Storage service IP

This combination matters because an architecture diagram that uses only "public/private" colors represents it badly. The name is tenancy-specific; the addressing remains public service addressing.

22.4 Resource Private Endpoint: Network Object with Semantic Scope Closer to the Resource

Object Storage PE and ADB native PE bring private addressing into the VCN, but the two services do not share the same semantic model.

Object Storage PE exposes access targets.

ADB PE identifies the database network endpoint; the SQL service remains deeper.

Therefore, even resource private endpoint is not a universal semantic class. It is an endpoint class that must be enriched with service-specific discriminator fields.

22.5 Why the Census Must Be Multidimensional

The same row can have:

endpoint specificity = high
credential isolation = unknown
alternate path       = present
collector visibility = high

endpoint specificity = high
credential isolation = unknown
alternate path       = present
collector visibility = high

or:

endpoint specificity = regional
service credential boundary = strong
network path = private

endpoint specificity = regional
service credential boundary = strong
network path = private

There is no total ordering that permits one to state which is "more private" without first naming the property.

That is one reason Module II does not assign scores.

23. Storage Source-Process Taxonomy: Knowing Which Service Receives the Bytes Is Not Enough

Storage introduces a variety of source processes that an endpoint inventory cannot represent.

An image pull can be generated by the container runtime of an OKE node.

A Functions image pull can be service-managed.

A generic artifact upload can originate from a build pipeline.

A File Storage NFS flow can originate from the kernel/NFS client of a host or pod.

Block-volume I/O can be guest-initiated through iSCSI or mediated by the virtualization layer under the paravirtualized model.

A backup byte transfer can be entirely provider-managed after a customer API request.

These source processes must not be merged simply because destination_service = storage.

23.1 Build-Plane Storage Flows

Build/release pipelines produce:

source code fetch
dependency download
image push
artifact metadata create
artifact content upload
signature upload
scan result query
promotion/copy

source code fetch
dependency download
image push
artifact metadata create
artifact content upload
signature upload
scan result query
promotion/copy

Even when several operations use OCIR/Artifact Registry, source process and authority change across build, release, and runtime.

The Flow Atlas must therefore be able to correlate:

build identity
release identity
runtime identity

build identity
release identity
runtime identity

without assuming that all three use the same repository permission.

23.2 Runtime Storage Flows

Runtime consumers include:

OKE node/container runtime
Functions managed runtime
Compute application
Data Science notebook/job
OIC/managed service integration
database/export process

OKE node/container runtime
Functions managed runtime
Compute application
Data Science notebook/job
OIC/managed service integration
database/export process

A runtime image pull and an application data read are different storage flows even when both traverse the same Service Gateway.

23.3 Kernel/Device-Plane Flows

File Storage and Block Volume expose source processes below the application layer.

NFS can be generated by the kernel NFS client.

iSCSI is managed by the instance OS and the block-storage connection.

Paravirtualized I/O does not appear as an ordinary L3/L4 guest session in the same way as iSCSI.

Collector applicability must therefore change. For NFS to a mount target, VCN evidence can be relevant where the resource and collection configuration make it available. OCI Block Storage core link-local traffic, however, is excluded from VCN Flow Logs. For iSCSI, attachment metadata is correlated with guest session state; for the paravirtualized model, available attachment/device and runtime evidence is used. None of these data sets is promoted to packet evidence for the provider's internal fabric.

Oracle source: Details for VCN Flow Logs.

23.4 Provider-Managed Storage Flows

Backup, replication, managed image pull, and service lifecycle can produce data movement that the customer does not originate as the packet source.

The record must be able to express:

source_process      = provider-managed
source_network      = not customer-routable / partially visible
operational_owner   = Oracle
customer evidence   = service state / Audit / documented contract

source_process      = provider-managed
source_network      = not customer-routable / partially visible
operational_owner   = Oracle
customer evidence   = service state / Audit / documented contract

The fact that Oracle owns the process does not make the flow irrelevant; it makes it a row with a different evidence contract.

23.5 Data Classification Remains Separate from the Service Family

Two Object Storage flows can have the same endpoint anatomy and different data classification. The Flow Atlas preserves data_classification as a field in the record but does not use it to alter the technical truth of the path.

This distinction will be useful when Module VI prioritizes adoption and revalidation without deforming the census.

24. Endpoint Drift: The Name May Stay the Same While the Contract Changes

A dated Flow Atlas must also be able to distinguish two cases that look opposite when read superficially.

In the first case, the name remains the same but the contract changes. A service API can add PSA support in a later release; a region can receive a capability it did not previously expose; a dual-stack endpoint can become available; a service can introduce a new native Private Endpoint family. The historical FQDN need not change, but the set of endpoint contracts available to the estate does.

In the second case, the contract remains logically the same but the runtime identifiers change. A private endpoint can be recreated, a private IP can change, a DNS answer can change, or a certificate chain can rotate. The stable Flow ID remains, but the evidence epoch expires.

This distinction prevents the DNS snapshot from becoming the permanent identity of the flow.

24.1 Capability Drift

The regional PSA catalog is the clearest example. A global Oracle page states which service APIs support PSA; the runtime command in the region states which entries are actually available at capture time.

The record must therefore contain at least:

capability_documented_at
capability_runtime_checked_at
runtime_region
runtime_service_id

capability_documented_at
capability_runtime_checked_at
runtime_region
runtime_service_id

If Oracle adds PSA to a service API that was previously SGW-only, the census does not silently modify an existing row. It creates a new endpoint/path variant or opens a new epoch of the same logical dependency.

24.2 DNS Drift

DNS evidence is temporal.

For a PSA or Private Endpoint, the private FQDN can resolve to an address that changes after recreation or failover.

For a regional public service endpoint, the set of public service IPs can change while the Service Gateway service CIDR label continues to represent the service.

For an Object Storage dedicated dual-stack endpoint, the same logical endpoint class can return A or AAAA records depending on client/network context.

The record must therefore preserve:

fqdn
answer
rrtype
resolver
timestamp
ttl

fqdn
answer
rrtype
resolver
timestamp
ttl

when the proof depends on address resolution.

24.3 Endpoint Recreation

A recreated resource Private Endpoint does not necessarily define a new business flow.

If:

business purpose
source process
operation
semantic target
endpoint class
authorization authority

business purpose
source process
operation
semantic target
endpoint class
authorization authority

remain unchanged, the stable Flow ID can remain the same while endpoint OCID/IP become a new evidence epoch.

If recreation moves the PE to a different subnet, changes access targets, NSGs, ZPR attributes, or DNS prefix in a materially relevant way, the census must decide whether the variant deserves a new Flow ID.

That decision applies the materiality rule already defined: if a future evaluation module should ask a different question, a different row is required.

24.4 Public/Private Twin Drift

Some resources can change the number of available surfaces.

Autonomous Database with a private endpoint can add the public-access surface when the supported configuration permits it.

OIC can add a custom endpoint without removing the original.

Object Storage can add a Private Endpoint without removing traditional/dedicated access.

A change request that "adds private access" can therefore increase the number of exact-flow rows rather than reduce it.

The census must record:

surface_added
surface_removed
surface_still_active
effective_date

surface_added
surface_removed
surface_still_active
effective_date

and must not assume that the new private surface replaced the previous one.

24.5 Protocol Drift

The endpoint can remain identical while protocol behavior changes.

Oracle release notes from 2026 document new S3 variants, including checksum support for DeleteObjects/BulkDelete and Content-Encoding: aws-chunked, together with dual-stack endpoints. An updated client SDK can start using a new endpoint template, checksum header, or address family.

A database client can change TLS/mTLS mode while keeping the same database endpoint.

A registry client can change the sequence of token/manifest/blob requests.

The Flow Atlas must therefore distinguish endpoint drift from protocol drift. Both can invalidate earlier evidence, but for different reasons.

24.6 The Record Must Not Become a CMDB

Preserving this information does not mean turning the Flow Atlas into an inventory of every change.

The record retains only changes that can modify:

• endpoint contract;
• discriminator locality;
• authority;
• source/owner;
• forwarding family;
• collector applicability;
• lifecycle dependency.

A display-name patch that changes none of these coordinates does not create a new row.

This selection keeps the census precise enough to support proof and stable enough to govern.

25. Evidence Locality: The Collector Must Observe the Same Surface Declared by the Record

One final problem spans every example in this first part: the row can be described correctly while the evidence is still collected in the wrong place.

A DNS capture proves which FQDN a resolver resolved during a given epoch. It does not prove which OCIR repository was used.

A VCN Flow Log can prove source/destination/port observed on the covered VNIC. It does not prove the Object Storage bucket or ADB service_name.

An Audit event can prove a control-plane operation and the principal that executed it. It does not automatically prove the NFS data path to a File Storage mount target.

A service log can show the semantic target and result. It does not prove the route path followed before the request reached the service.

This is why the canonical row contains collector applicability, not a generic logging = yes column.

25.1 The Same Dependency Produces Multiple Evidence Objects

For an OCIR image pull:

DNS evidence       -> regional registry FQDN
network evidence   -> source VNIC / destination / 443
registry evidence  -> repository / digest
IAM evidence       -> principal / authorization
runtime evidence   -> process that requested the image

DNS evidence       -> regional registry FQDN
network evidence   -> source VNIC / destination / 443
registry evidence  -> repository / digest
IAM evidence       -> principal / authorization
runtime evidence   -> process that requested the image

The Flow Atlas does not yet decide which combination is sufficient for a verdict. It must, however, preserve which pieces exist and which part of the flow each can describe.

25.2 A Private Endpoint Does Not Automatically Improve Observability

A resource Private Endpoint can be much more specific at the address/FQDN layer without guaranteeing that all deeper target fields are present in network logs.

A PSA private IP can make the path more deterministic while repository, bucket, or Function OCID remain in the service request.

A public dedicated FQDN can be tenancy-specific and provide an excellent name-layer discriminator while using public service IPs.

Endpoint specificity and evidence richness are therefore independent coordinates.

25.3 The Collector Source Must Be Recorded

The collector itself has a principal and scope.

Network Path Analyzer (NPA) analyzes a full configuration snapshot, while the path displayed to the user is limited to objects the user has permission to view. The analysis-service permissions, analyzed configuration, and result visibility must therefore remain distinct. NPA is configuration analysis, not observation of transmitted packets, and its topology and address-family limitations remain subject to verification. Audit and Logging Search have their own query scopes and retention; packet capture exists only at the point where it is actually configured.

Oracle source: Network Path Analyzer.

For the census:

collector_type
collector_principal
collector_scope
retention
observation_time
known_blind_spots

collector_type
collector_principal
collector_scope
retention
observation_time
known_blind_spots

are record metadata.

25.4 Absence of Evidence Is Not Converted into Evidence of Absence

If a flow does not appear in a collector, the record must distinguish at least:

not observed
not configured
outside collector scope
provider-managed
dormant
failed before collector
actually absent

not observed
not configured
outside collector scope
provider-managed
dormant
failed before collector
actually absent

This distinction is essential for backup/provider-managed flows and alternate endpoint surfaces used only for failover or maintenance.

A census that converts not observed into does not exist deletes precisely the rows Module II was created to discover.

26. Technical Closure of the First Block

The result of this expansion can be expressed as one operational rule: an exact-flow record is acceptable only when the destination surface and semantic target are not conflated, the reachability family is recorded separately from the endpoint contract, the source process and authorization authority are named, and the evidence surface is dated and scoped.

That rule has already been applied to regional FQDNs, dedicated namespace endpoints, PSA, native/resource Private Endpoints, custom FQDNs, OIC, OAC, Autonomous Database, Functions, Object Storage, OCIR, Artifact Registry, File Storage, Block/Boot Volume, and backup. The cases do not share one architecture; they share one census grammar.

That uniformity is what makes the next part of the Flow Atlas possible: adding new service families without returning each time to the generic question "is the product private?", and instead populating the coordinates that determine the actual exact flow.

Oracle Sources and Evidence References

The following references document the corresponding services and contracts. The author's field evidence remains distinct from properties stated in Oracle documentation; publication date does not substitute for the date of a test or regional runtime snapshot.

1. Service Gateway and Private Service Access Supported Services https://www.oracle.com/cloud/networking/private-service-access/service-gateway-and-psa-supported-services/
2. Access to Oracle Services: Service Gateway https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/servicegateway.htm
3. Access to Oracle Services: Private Service Access Endpoints https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/private-service-access.htm
4. Object Storage Dedicated Endpoints https://docs.oracle.com/en-us/iaas/Content/Object/Concepts/dedicatedendpoints.htm
5. Object Storage Private Endpoints https://docs.oracle.com/en-us/iaas/Content/Object/Tasks/private-endpoints.htm
6. Object Storage Dual-Stack Endpoints and IPv6 https://docs.oracle.com/en-us/iaas/Content/Object/Concepts/use-ipv6-urls.htm
7. Oracle Integration — Design-time and service console URL semantics https://docs.oracle.com/en/cloud/paas/application-integration/rest-api/SendRequests.html
8. Oracle Integration — Private Endpoints https://docs.oracle.com/en-us/iaas/application-integration/doc/private-endpoints.html
9. Oracle Integration — Custom Endpoint https://docs.oracle.com/en-us/iaas/application-integration/doc/configure-custom-endpoint-instance.html
10. Oracle Analytics Cloud — Private Endpoints https://docs.oracle.com/en-us/iaas/analytics-cloud/doc/private-endpoints.html
11. Oracle Analytics Cloud — Public Endpoints and Access Control Rules https://docs.oracle.com/en-us/iaas/analytics-cloud/doc/public-endpoints-and-access-control-rules.html
12. Oracle Analytics Cloud — Private Access Channels https://docs.oracle.com/en-us/iaas/analytics-cloud/doc/private-access-channels.html
13. Autonomous Database — Private Endpoints https://docs.oracle.com/en-us/iaas/autonomous-database-serverless/doc/private-endpoints-autonomous.html
14. API Gateway — Functions backend https://docs.oracle.com/en-us/iaas/Content/APIGateway/Tasks/apigatewayusingfunctionsbackend.htm
15. OCI Container Registry — Overview https://docs.oracle.com/en-us/iaas/Content/Registry/Concepts/registryoverview.htm
16. Artifact Registry — Overview https://docs.oracle.com/en-us/iaas/Content/artifacts/overview.htm
17. File Storage — Overview https://docs.oracle.com/en-us/iaas/Content/File/Concepts/filestorageoverview.htm
18. File Storage — Mount Targets https://docs.oracle.com/en-us/iaas/Content/File/Tasks/managingmounttargets.htm
19. Block Volume — Overview https://docs.oracle.com/en-us/iaas/Content/Block/Concepts/overview.htm
20. Block Volume — Connecting to a Volume https://docs.oracle.com/en-us/iaas/Content/Block/Tasks/connectingtoavolume.htm
21. Block Volume Backups https://docs.oracle.com/en-us/iaas/Content/Block/Concepts/blockvolumebackups.htm
22. Creating a Block Volume Backup https://docs.oracle.com/en-us/iaas/Content/Block/Tasks/create-bv-backup.htm
23. Volume Group Backups https://docs.oracle.com/en-us/iaas/Content/Block/Concepts/volumegroups_topic-Volume_Group_Backups.htm
24. File Storage — port and protocol profiles https://docs.oracle.com/en-us/iaas/Content/File/Tasks/securitylistsfilestorage.htm
25. File Storage — in-transit encryption https://docs.oracle.com/en-us/iaas/Content/File/Tasks/intransitencryption.htm
26. VCN Flow Logs — content and exclusions https://docs.oracle.com/en-us/iaas/Content/Logging/Reference/details_for_vcn_flow_logs.htm
27. Network Path Analyzer — model, visibility, and limitations https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/path_analyzer.htm
28. Functions — invoke endpoint and invocation https://docs.oracle.com/en-us/iaas/Content/Functions/Tasks/functionsinvokingfunctions.htm
29. ArtifactsClient — Oracle OCI Python SDK source https://github.com/oracle/oci-python-sdk/blob/master/src/oci/artifacts/artifacts_client.py
30. GenericArtifactsContentClient — Oracle OCI Python SDK source https://github.com/oracle/oci-python-sdk/blob/master/src/oci/generic_artifacts_content/generic_artifacts_content_client.py
31. Block Storage — backup-protection release note https://docs.oracle.com/iaas/releasenotes/blockvolume/retention-lock.htm
32. Private Access to Oracle Services https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/transitroutingoracleservices.htm
33. FortiGate on OCI https://docs.oracle.com/en/solutions/secure-oci-workloads-fortigate/index.html
34. Palo Alto Networks VM-Series on OCI https://docs.oracle.com/en/solutions/secure-app-palo-alto-firewall/index.html
35. Network Firewall and Regional WAF https://docs.oracle.com/en/learn/waf-local-app/index.html
36. OCI DMZ common architectures https://www.ateam-oracle.com/oci-dmz-concepts
37. Working with VCN Route Tables and Route Rules https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/managingroutetables_topic-working.htm
38. OCI Load Balancers: logging the real source IP https://www.ateam-oracle.com/oci-load-balancers-logging-the-real-source-ip
39. NAT Gateway https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/NATgateway.htm
40. Palo Alto active/active and OCI NLB https://docs.oracle.com/en/solutions/oci-nlb-palo-alto-active-active/index.html
41. VCN Route Tables https://docs.oracle.com/iaas/Content/Network/Tasks/managingroutetables.htm
42. Artifacts Functions https://docs.oracle.com/en-us/iaas/Content/pl-sql-sdk/doc/dbms_cloud_oci_ar_artifacts.html
43. Generic Artifacts Content Functions https://docs.oracle.com/en-us/iaas/Content/pl-sql-sdk/doc/dbms_cloud_oci_gac_generic_artifacts_content.html
44. Container Registry Concepts — registry-domain formats https://docs.oracle.com/en-us/iaas/Content/Registry/Concepts/registryconcepts.htm
45. Central network virtual appliance — DRG route tables and VCN ingress route table https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/scenario_g.htm
46. FastConnect Security — IPSec over FastConnect and attachments https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/fastconnectsecurity.htm
47. Oracle Integration — ingress restrictions and allowlist https://docs.oracle.com/en/cloud/paas/application-integration/oracle-integration-oci/allowlist.html
48. Exadata — network setup https://docs.oracle.com/en-us/iaas/exadatacloud/doc/ecs-network-setup.html
49. Exadata — Manage VM Clusters and PSA for specific dependencies https://docs.oracle.com/en/engineered-systems/exadata-cloud-service/ecscm/manage-vm-clusters.html
50. OKE — network-resource configuration https://docs.oracle.com/en-us/iaas/Content/ContEng/Concepts/contengnetworkconfig.htm
51. Autonomous Database — VCN transit routing https://docs.oracle.com/en/cloud/paas/autonomous-database/serverless/adbsb/access-vcn-transit-routing.html
52. API Gateway — authorizer Function https://docs.oracle.com/en-us/iaas/Content/APIGateway/Tasks/apigatewayusingauthorizerfunction.htm
53. Service Gateway — gateway characteristics and pricing https://www.oracle.com/cloud/networking/service-gateway/