Endpoint Type Entity Feasibility

Date: 2026-02-27

Context: The Clarity UX spec uses "Endpoint Type" in the verdict sentence template:

<N> autonomous paths exercised <Domain>-scoped authority and invoked <Endpoint Type> <X> times in the last 30 days.

This term does not exist as an entity in the current data model. This document assesses whether it should.

---

Executive Answer

"Endpoint type" is not a new entity. It is a composite of data we already collect.

Three existing fields combine to produce what the Clarity spec calls "Endpoint Type":

Existing Field	Source	Example Values
connection_type	Foundry Connections API	AzureOpenAI, AzureBlob, AzureSearch, S3, MCP, Custom
egress_category	Egress classifier (computed from URL)	llm, cloud, external, internal
resource_display_name	Entra sign-in logs	Microsoft Graph, Azure Key Vault, Azure Storage

No new entity type. No schema migration. Just surface and compose existing data.

---

What Already Exists

1. Azure Foundry Connector — Richest Source

The Foundry connector already captures structured endpoint type data on connection nodes:

Connection properties (transformer.py lines 246-265):

properties = {
    "connection_type": "AzureOpenAI",           # Standardized enum
    "endpoint": "https://my.openai.azure.com",  # Raw URL
    "egress_category": "llm",                   # Classified type
    "authentication_type": "aad_default",
}

Supported connection_type values (from Foundry Connections API):

• AzureOpenAI, Serverless, ManagedOnlineEndpoint — AI/LLM endpoints
• AzureBlob, AzureDataLakeGen2, S3 — Storage endpoints
• AzureSearch, AzureSqlDb, AzureCosmosDb — Data endpoints
• AzureKeyVault — Secrets endpoints
• ContainerRegistry — Infrastructure endpoints
• MCP, Custom — External/custom endpoints

Egress classifier (egress_classifier.py) automatically categorizes endpoint URLs:

Category	Pattern Matches
llm	openai.azure.com, api.openai.com, api.anthropic.com, generativelanguage.googleapis.com, .inference.ai.azure.com
cloud	.blob.core.windows.net, .vault.azure.net, .servicebus.windows.net, .cosmos.azure.com, graph.microsoft.com, management.azure.com
internal	localhost, RFC 1918 ranges
external	Everything else

2. Entra-ServiceNow Connector — Partial Data

Sign-in evidence nodes (transformer.py line 1957):

properties = {
    "target_resource": sign_in.get("resource_display_name", ""),  # Free-text
    # e.g., "Microsoft Graph", "Azure Key Vault", "Azure Storage"
}

This captures what was accessed but as a free-text string — not classified into types.

3. ServiceNow Connection Entities

Connection node properties (from data model spec):

connection_subtype: rest_message | rest_method | soap_message | http_connection
endpoint_url: https://...
authentication_type: oauth2 | basic | api_key | certificate

These already carry protocol-level endpoint type information (REST vs SOAP vs HTTP).

---

Mapping to the Verdict Sentence

The Clarity template: <N> autonomous paths exercised <Domain>-scoped authority and invoked <Endpoint Type> <X> times in the last 30 days.

Slot	Source	Available Now?
<N>	Count of execution_paths[]	Yes
<Domain>	business_domain on resource entities	Yes
<Endpoint Type>	Composed from connection_type + egress_category	Yes — needs composition
<X> (invocation count)	execution_evidence aggregation	Partially — workload-level, not per-endpoint
last 30 days	Filter by last_activity_at	Yes

The one gap: invocation count (<X>) is tracked per-workload, not per-endpoint-pair. Getting "invoked Graph API 47 times" requires either:

• Aggregating execution_evidence records filtered by (workload, target_resource) — possible today for sign-in evidence
• Storing invocation counts per connection entity — enhancement needed

---

Recommendation: Derive, Don't Invent

Option A — Composition at Query Time (MVP)

Materialize endpoint_type as a derived property during path materialization by combining existing fields:

connection_type = "AzureOpenAI" + egress_category = "llm"
→ endpoint_type = "LLM API (Azure OpenAI)"

connection_subtype = "rest_message" + egress_host = "api.openai.com"
→ endpoint_type = "REST API (OpenAI)"

resource_display_name = "Microsoft Graph"
→ endpoint_type = "Microsoft Graph API"

Effort: ~1 Claude Code session Schema impact: None — computed at materialization time

Option B — Enriched Property on Connection Nodes

Add a normalized_endpoint_type property to connection entities during ingestion:

# In transformer, after egress classification:
properties["normalized_endpoint_type"] = derive_endpoint_type(
    connection_type=properties.get("connection_type"),
    egress_category=properties.get("egress_category"),
    endpoint_url=properties.get("endpoint"),
)

Effort: ~1 Claude Code session Schema impact: One new property per connection entity (~50 bytes)

Option C — New Entity Type (Not Recommended)

Creating a standalone endpoint_type entity with its own nodes and edges would be over-engineering. The data is already on connection nodes — adding another entity type creates redundancy and complicates the graph without adding new relationships.

---

What Would Improve Over Time

Enhancement	Source	Customer Requirement	Effort
Per-API-call endpoint URIs	Microsoft Graph Activity Logs	Enable Azure Monitor export (Entra P1/P2)	2-3 sessions
Per-run tool invocations	Foundry Runs API + Run Steps	None (already have permissions)	2-3 sessions
ServiceNow outbound HTTP logs	sys_outbound_http_log	Enable glide.rest.outbound_log_level=elevated	1-2 sessions
Normalized resource_display_name	Sign-in log mapping table	None	1 session

These are additive enrichments, not prerequisites. The verdict sentence works today with existing data.

---

Verdict

Question	Answer
Is "endpoint type" feasible?	Yes — it already exists as raw data
Is it a new entity type?	No — it's a derived property on existing connection/evidence nodes
Is it too specific for SV0?	No — it directly supports the Clarity UX verdict sentence and aligns with execution-determined framing
What's the implementation path?	Option A or B — compose from existing connection_type, egress_category, resource_display_name
Effort?	~1 Claude Code session for MVP

The Clarity spec can reference "Endpoint Type" in the verdict sentence. The backend just needs to compose it from fields the connectors already produce.