Host identity
What is this path?
api.github.com
known host
HTTPS 443
expected transport
Secondary Calls meaning layer
Secondary-call inventory should show where AI activity crosses or approaches external boundaries before it behaves like a host table.
The first read should explain which outbound destinations matter, why they matter, and what internal context was nearby.
2 destinations matter
Which external destinations matter most right now?
Calls seen
28
Only a few hosts drive meaning
Distinct hosts
9
Most are background context
High-signal destinations
2
One routine, one weakly explained
Background paths
7
Useful later, not first-read material
Meaning anchors
Why secondary calls matter before the raw catalog
3 anchors
Anchor | Summary | Operator note |
|---|---|---|
Destinations should be read as boundary meaning | The key question is not “what hosts exist?” but “which outbound paths change the company story?” | That is the right abstraction for this inventory type. |
Expected does not mean unimportant | A familiar external host can still be the clearest example of company context leaving the boundary. | Meaning-layer pages should say that directly. |
Destination detail should connect sequence | The useful page shows what internal context came first and how well the destination is classified. | That is stronger than a method table alone. |
Priority queue
Fastest drill paths for this entity type
Significance
Story | Summary | Why it matters |
|---|---|---|
api.github.com | Expected destination tied to the clearest externalization story. | Best first page for explaining the boundary lane. |
Unlabeled host | Weaker classification and therefore higher trust urgency. | Likely the next raw review after the main host story. |
Routine provider adjacencies | Supporting background context. | Useful after the main boundary story is understood. |
c6 reference
Raw Secondary-Call Inventory
28
1 plain HTTP destination
One secondary-call path is still unencrypted and weakly classified.
Destinations
28
HTTP paths
1
Avg bytes
NaN
Review candidate
NaN
Destination | Protocol | Port | Sessions | Total calls |
|---|---|---|---|---|
| api.github.com | https | 443 | 4 | 12 |
| registry.npmjs.org | https | 443 | 3 | 8 |
| 10.0.2.15 | http | 8080 | 1 | 3 |
Representative detail
api.github.com
api.github.com should read like a boundary story: common enough to be expected, but important because of the company context and session sequence around it.
Destination Host :
10.0.2.15
IP Address :
10.0.2.15
Protocol :
http
Port :
8080
First Seen :
today
Last Seen :
22 min ago
Boundary destination map
The destination page should connect one host to the internal context that made it important.
destination
Use the map to show why boundary meaning depends on the sequence around the call, not only the hostname.
Focus
api.github.com
Expected external host tied to meaningful internal context.
classified boundary path
Attribution lane
Who used it?
3 linked sessions
focused and readable
Alice workstream
main context anchor
Internal precursor
What came first?
.env + config files
sensitive precursor
shared key lane
important credential context
Boundary meaning
Why does it matter?
context left company
main consequence
unlabeled host nearby
next comparison
classification
known
context sensitivity
high
boundary role
primary example
next drill
session + file story