← Back to catalogue
Published

Network / Endpoint

vr.wm-sft-018 · wm-sft-018-network-endpoint

Describe one stable logical network endpoint with effective-dated address bindings, contextual connectivity and bounded exposure assertions.

World Models Information and virtual systems INF.SFT.NET
Bundle → Layer → Finding → QuestionsClassifiersWhat it isWhy it existsDistinguishing featuresWhat robots and AI may and may not doMoral aspectsOwnersLinks to other meta-modelsIdentity and identifiersDirect propertiesRecognitionCapabilities and actionsHazards and failure modesStandards and interfacesContext of useSources

Bundle → Layer → Finding → Questions Filled

3 bundles · 3 layers · 5 findings · 10 questions

Endpoint identity What the endpoint is and who owns it.

Logical endpoint

The stable identity, owner and purpose of the endpoint.

Identity and owner

The endpoint's identifier, owner and the service it fronts.

  1. Which stable identifier names this endpoint, and who owns it?
  2. Which service or system does the endpoint front?
Address bindings Where the endpoint currently resolves.

Effective-dated bindings

Host names, addresses and ports with validity periods.

Current binding

The addresses and ports the endpoint uses now.

  1. Which host names, IP addresses and ports does the endpoint resolve to now?
  2. Since when is this binding valid, and which binding did it replace?

Protocol and certificate

The protocols and certificates presented.

  1. Which protocols and versions does the endpoint accept?
  2. Which certificate does it present, and when does it expire?
Exposure and connectivity Who can reach it and how far it is exposed.

Exposure assertion

Bounded statements about reachability and controls.

Reachability

Networks from which the endpoint can be reached.

  1. Is the endpoint reachable from the internet, a private network or only locally?
  2. Which authentication and access controls protect it?

Verification

Evidence that the exposure assertion is true.

  1. When was the exposure last verified, and by what scan or test?
  2. Do observed open ports match the declared exposure?

Classifiers Filled

Family
World Models
Category
Information and virtual systems
Entry kind
entity
Navigation path
NAV.INF.SFT.NET
Domain
INF.SFT.NET
Industry
Cross-industry
Tags
networkendpointinf.sft.net

What it is Filled

A network endpoint is a stable logical identity for a point where a system can be reached over a network, such as a service address, API endpoint or device interface. It holds effective-dated bindings to concrete addresses (host names, IP addresses, ports), its connectivity and bounded assertions about how it is exposed. The software running behind it, the physical device and the traffic flowing to it are separate subjects.

In scope

  • Endpoint identity, accountable roles, classification and contextual service, runtime and interface bindings
  • Effective-dated locator sets, protocol properties, discovery evidence and expected versus presented service identity
  • Topology references, bounded exposure declarations, reachability evidence links, local assessments and record continuity

Out of scope

  • Whole network inventory or routing engine; device, software, runtime and interface contract masters
  • Traffic collection, telemetry lifecycle, credentials, certificate issuance, access-policy enforcement and operational security decisions
  • Active scans, network writes, production changes, deployment, universal availability guarantees and compliance certification

Why it exists Filled

Describe one stable logical network endpoint with effective-dated address bindings, contextual connectivity and bounded exposure assertions.

Distinguishing features Filled

  • The logical endpoint stays stable while its concrete address bindings change over time.
  • Exposure is stated as bounded, verifiable assertions rather than assumed.
  • Distinct from the software service behind it, its parent context, and from the device that hosts it.
  • Distinct from network flow telemetry, which records traffic rather than the endpoint's identity.

What robots and AI may and may not do Filled

Must not

  • Scan, probe or attack endpoints without the owner's authorization.
  • Open firewall rules or expose endpoints beyond the declared exposure.
  • Publish internal endpoint inventories that help attackers.
  • Rebind an endpoint to a new address without change control.
  • Disable authentication or encryption on an endpoint.

Only with a human decision

  • Exposing an endpoint to the internet.
  • Changing bindings of production endpoints.
  • Approving penetration tests against endpoints.

May

  • Keep an inventory of endpoints with owners, bindings and validity periods.
  • Verify exposure of endpoints the owner is authorized to test.
  • Report expiring certificates, stale bindings and unexpected open ports to the owner.
  • Resolve an endpoint to its current binding for authorized clients.

Moral aspects Filled

  • Exposed endpoints are the main entry point for attacks that harm users and their data.
  • Endpoint addresses can identify people and devices, so inventories need protection.
  • Scanning other people's systems without consent can be unlawful and harmful.

Who is affected

  • Users of the services behind the endpoints
  • System owners and operators
  • People whose devices are addressed

Owners Filled

Steward

The team that operates the service behind the endpoint owns its identity, bindings and exposure assertions.

Roles

Endpoint steward
Resolve identity, namespace and binding disputes within delegated authority.
Network policy approver
Approve bounded exposure declarations; external enforcement remains separately controlled.
Evidence curator
Link permitted observations with scope, provenance and freshness; do not rewrite telemetry masters.
Profile reviewer
Review schema constraints, neighbor pins and projection losses before operational adoption.
Authorized consumer
Read or export only purpose-approved views and report ambiguity.

Master systems

  • IP address management systems
  • DNS zones
  • Configuration management databases
  • API gateways and service registries

Links to other meta-models Filled

references

  • WM-SFT-002 - Candidate ledger edge: software identity and lifecycle stay software-owned; retain service reference and effective binding only.
  • WM-SFT-010 - Candidate ledger edge: runtime identity and capacity stay runtime-owned; retain hosting and network-context references only.
  • WM-SFT-003 - Candidate ledger edge, including reciprocal incoming reference: bind interface contract revisions without owning their semantics, operations or compatibility.
  • WM-SFT-017 - Candidate ledger edge: reference traffic and reachability evidence; telemetry occurrence, collection lifecycle and signal identity stay telemetry-owned.

aligned

  • RFC 8345 network topology - Optional versioned mapping from an endpoint binding to topology references; no universal equivalence to a termination point.
  • DCAT 3 endpointURL and endpointDescription - Optional data-service projection; the endpoint root is not a dataset or the full service description.
  • OpenAPI 3.1.1 Server Object - Optional HTTP interface binding projection with pinned variables and selector semantics; no executable conformance claim.

neighbor

  • WM-SFT-002 - Candidate ledger edge: software identity and lifecycle stay software-owned; retain service reference and effective binding only.
  • WM-SFT-010 - Candidate ledger edge: runtime identity and capacity stay runtime-owned; retain hosting and network-context references only.
  • WM-SFT-003 - Candidate ledger edge, including reciprocal incoming reference: bind interface contract revisions without owning their semantics, operations or compatibility.
  • WM-SFT-017 - Candidate ledger edge: reference traffic and reachability evidence; telemetry occurrence, collection lifecycle and signal identity stay telemetry-owned.

parent

  • WM-SFT-002

What else AI and robots need to interact with it Filled

Identity and identifiers required Filled

  • An endpoint is identified by a stable logical name or URI that outlives its address bindings.
  • Bindings use DNS host names, IP addresses and port numbers.
  • Certificates presented by the endpoint are identified by issuer and serial number or fingerprint.

Direct properties not applicable Not applicable

Not applicable

A network endpoint is a logical identity, not a physical object; latency and throughput are measured on the traffic, not on the endpoint itself.

Recognition optional Filled

  • An addressable point that accepts connections on a protocol and port, with a known owner.
  • Often confused with the host machine, the service behind it, or a DNS name that points to several endpoints.

Capabilities and actions required Filled

  • Accepts connections over defined protocols and returns responses.
  • Bindings can be changed while the logical identity stays the same.

Hazards and failure modes required Filled

  • Unintended internet exposure of internal services.
  • Expired or misissued certificates enabling interception.
  • Stale bindings that send traffic to addresses now controlled by others.

Standards and interfaces required Filled

  • DNS, IP and TCP or UDP port numbers as defined by the IETF and IANA.
  • X.509 certificates and TLS for endpoint authentication.
  • OpenAPI descriptions for HTTP API endpoints.

Context of use required Filled

  • Found in data centres, cloud platforms, enterprise networks and devices.
  • Security frameworks require inventories of exposed services.

Sources Filled

  1. Uniform Resource Identifier (URI): Generic Syntax - Internet Engineering Task Force
  2. A YANG Data Model for Network Topologies - Internet Engineering Task Force
  3. Data Catalog Vocabulary (DCAT) - Version 3 - World Wide Web Consortium
  4. Zero Trust Architecture - National Institute of Standards and Technology
  5. Domain names - concepts and facilities - Internet Engineering Task Force
  6. IPv6 Scoped Address Architecture - Internet Engineering Task Force
  7. Service Identity in TLS - Internet Engineering Task Force
  8. Service Name and Transport Protocol Port Number Registry - Internet Assigned Numbers Authority
  9. OpenAPI Specification v3.1.1 - OpenAPI Initiative
  10. PROV-O: The PROV Ontology - World Wide Web Consortium
  11. RFC 3986 Uniform Resource Identifier: Generic Syntax, IETF
  12. Service Name and Transport Protocol Port Number Registry, IANA
  13. NIST Cybersecurity Framework, NIST

Open questions

  • Complete independent source verification with response metadata, version and errata review, claim support and applicability checks; restore external provider review before canonical promotion.
  • Develop nested instance schemas and pinned mappings with fixtures for shared addresses, concurrent bindings, conflicting resolver views, scoped IPv6, stale evidence, identity mismatch, retirement and redacted export.
  • Review specialist protocol, mediation, authorization, privacy and retention profiles with accountable operators before any operational adoption.
  • Independent external provider review is absent; this Codex result can only be a reviewable draft.
  • Direct HTTP checks were not run because the owner reports sandbox blocking; response status, final URLs and body digests remain unmeasured. Browser readings cover selected sections only; latest versions and all errata are not certified.
  • Nested instance schemas, mandatory profile fields, loss-aware executable mappings and adverse-instance fixtures remain unimplemented.
  • Protocol-specific discovery beyond the selected DNS concepts, non-IP transports, multicast or anycast behavior, complex mediation and full certificate lifecycle need specialist profiles.
  • Legal authority for testing, privacy, retention, export, licensing and sector requirements need adopting-context review.

Machine files

Card as JSON Specification AGENTS.md Source Card backlog vercy.card/1

Provenance

world-models research · reviewable-draft

Built from: models/wm-sft-018-network-endpoint/spec.yaml, ver-cy/world-models/card-supplements/wm-sft-018-network-endpoint.json