Summary

  • The BTW directory card for Seattle Internet Exchange carries card confidence 0.95 but rests on exactly one evidence basis: a public registry record at AS33108, weighted 0.82. The same card lists legal-entity country, current services, visible assets, ownership links and responsible leadership as unverified.
  • Two retrieval generations on 17 October 2026 recorded the operator publishing 10G, 100G and 400G interfaces, route servers used for multilateral peering under AS10297, a primary site at the Westin Building Exchange, and peak traffic above 1 Tbps.
  • An aggregation listing returned for the same exchange reported more than 350 participating networks across the Westin Building and KOMO Plaza, formerly Fisher Plaza.
  • The same listing service returned two different record identifiers for one exchange — IX 66 at 14:11 UTC and IX 147 at 14:36 UTC — a divergence to be reported and held open, not merged into a single canonical object.
  • None of the three layers documents who can provision a member port, change route-server policy or grant access to either facility. Those are the powers that decide whether a dense fabric disciplines transit prices or turns into a shared failure domain, and they remain outside the evidence.

The card is a pointer, not a measurement

The directory record for Seattle Internet Exchange is unusually explicit about its own basis. It publishes a card confidence of 0.95 and, directly beside it, an evidence basis of one item: a public registry record at AS33108, described as public registry record evidence and weighted 0.82. It also types the entity as a private company with a headquarters country of "Global" and a registration jurisdiction of "Global", then lists the questions it has not answered — legal-entity country, current services, visible assets, parent or subsidiary links, and responsible public leadership contacts.

That is a candid record, and reading it correctly means reading it narrowly. A registry entry at an autonomous-system number is a recognition claim: it says that a number is registered and associated with an organisation name. It does not say who owns the number, who operates the fabric behind it, what legal form the operator has, or which facilities the operator controls. The 0.82 weighting on that single edge, set against a 0.95 card confidence, is the whole tension of this piece in miniature: a high-confidence summary resting on one moderate-confidence pointer.

The identifier itself is the first thing to hold apart. AS33108 appears in the directory as the lookup key for attribution. The operator's technical page names a different number for its route-server function: AS10297. These are not competing claims about one fact; they are claims about two different roles, and the retrieved material does not establish how, or whether, the two are related operationally. Anyone who compresses AS33108, AS10297 and the exchange's name into one identity is doing resolution work that the evidence has not done.

What the operator publishes, and what publishing costs

The exchange's own front page describes a neutral, non-profit internet exchange point located primarily in the Westin Building Exchange in Seattle. Its technical page reports support for 10G, 100G and 400G port interfaces, states that route servers are used for multilateral peering, and identifies AS10297 for route-server operations. Its statistics page indicates peak traffic volumes that have surpassed one terabit per second.

These are first-party service claims, and they are the most operationally specific material in the record. They are also self-descriptions. A 400G interface capability is a statement about what the operator can sell or provision; a route-server ASN is a statement about which routers participants are invited to peer with; a traffic graph above one terabit per second is a statement about aggregate load. Each is the kind of claim an operator has every reason to publish and little reason to inflate carelessly, because participants can test it with their own ports. That is an argument for taking the claims seriously.

It is not an argument for treating them as measurements taken by anyone other than the operator.

What the operator material does not contain is equally important. There is no dated participant list, no port-count table, no statement of measurement window or instrumentation behind the traffic figure, and no description of how provisioning authority is divided between the exchange, the facility providers and the members. The retrieved snapshots preserve page summaries rather than verbatim text, which is a further limit this report carries openly: the numbers above are reported values with a retrieval date, not quoted figures with a publication date.

The aggregator's count and its two identities

The aggregation record returned on 17 October 2026 reports more than 350 participating networks and multiple physical points of presence including the Westin Building and KOMO Plaza. That is the densest quantitative claim in the set, and it is also the least defined. "More than 350" is a floor, not a count. It does not say when the count was taken, whether it counts organisations or autonomous systems, whether it includes route-server-only presences, or whether dormant entries are pruned.

Then there is the divergence. An earlier pass the same day returned a different record identifier for the same exchange. Two identifiers, one afternoon, one subject. The honest reading is not that the exchange has two identities or that someone is concealing something; duplicate, historical, alias and differently scoped records are all ordinary outcomes in any volunteer-maintained directory. The honest reading is that a reader who needs one canonical exchange object does not have one, and that any claim depending on canonicality — a comparison across exchanges, a market-share figure, a ranking — inherits that uncertainty.

This matters more than it looks. Aggregators are where most practitioners actually check an exchange's size, because the operator's own pages rarely publish a clean count and the registries do not track participants at all. If the aggregator's own identifier is unstable within a single day, then the count it publishes should be treated as a directional indicator rather than a measurement, and the operator's silence on participant numbers becomes the binding constraint on the whole question.

Where control actually sits

Strip the layers back and the control question is simple to state and hard to answer. Three powers decide what an exchange is: who can provision or withdraw a member port, who administers the route-server function that members peer with, and who holds access to the facilities where the fabric terminates. A party holding all three operates an exchange. A party holding none of them is a name attached to a record.

The retrieved material establishes the second power partially — the operator reports operating route servers under AS10297 — and the third only as a location: the fabric is described as primarily at the Westin Building Exchange, with a second site at KOMO Plaza appearing in the aggregation record. Facility presence is not facility control; a tenant at a carrier hotel and the building's owner are different parties with different leverage. On the first power, provisioning authority, the record is silent.

That silence is the finding. It means the strongest defensible statement is layered: the registry records an autonomous-system association, the operator reports a service capability, the directory lists a participant population. None of those statements upgrades into proof that the entity behind the name can turn a port up or down, and no reader should infer operational control from an identifier's stability.

Capacity becomes leverage at the route server

Why does the distinction matter commercially? Because an exchange disciplines transit pricing through density and reachability, and both are physical before they are institutional. More than 350 listed participants is enough density for a Seattle access network to find most of its significant counterparties on one fabric; interfaces up to 400G mean the fabric can carry that traffic without a member having to buy a private circuit to every peer; peaks above one terabit per second indicate the fabric is carrying real aggregate load rather than a handful of symbolic sessions.

Those three facts together are the reason a local exchange can hold transit prices down in a metro.

The route server is where that leverage becomes concentrated. Multilateral peering through operator-run route servers is a convenience: a member configures one session and receives reachability for every other member that also uses it. The convenience is real, and so is the transfer. A member that depends on the route server for most of its reachability has delegated prefix propagation to routers it does not administer, under a policy it does not set. When the route server behaves, that is efficient. When it does not — a misconfiguration, a policy change, an outage — the failure is not local to one member's port.

It is correlated across every member relying on the same session.

This is not an argument against route servers; they are standard practice and usually well run. It is an argument for knowing where the dependency sits before treating a fabric as a resilience asset. An exchange with 350-plus participants and a widely used route server is simultaneously a price-disciplining mechanism and a shared single point of failure, and the record above tells us the first half clearly while leaving the second half to inference.

The correlated-failure question

Two named sites change the failure calculus in a way that the participant count cannot. A fabric that terminates in one building has a single physical dependency: power, cooling, fibre entry and building access all fail together. A fabric described as primarily at one site with a second site listed separately may have redundancy — or may have a primary facility plus a satellite presence that most members never use.

The retrieved material says "primarily the Westin Building Exchange" and lists KOMO Plaza as a site; it does not say how members are distributed between them, whether the peering LAN spans both, or whether a member at one site can reach a member at the other without leaving the fabric.

That distinction is the difference between a metro interconnect with genuine physical diversity and a single-building exchange with an annex. The record cannot settle it, and this report does not pretend otherwise. What can be said is that the question is testable, and that the operator is the party holding the answer.

What would change this reading

Five observations would move the assessment, and each is specific enough to be checked rather than argued.

A delegated-resources record linking AS33108 to the exchange operator, together with a contemporaneous routing observation showing the number in use, would close the registry-to-operation gap that currently separates the directory card from the operator's pages. Evidence of who can provision ports and change route-server configuration — a member agreement, an operations page, a published change process — would move the control question from apparent responsibility to evidenced control.

Reconciliation of the two listing identifiers through aliases, creation dates, operator fields and facility history would reduce the divergence to directory maintenance. Independent port-count or traffic measurements that differ from the operator's figures would require reporting the variance and its basis rather than choosing a preferred source. And a dated participant list would convert "more than 350" into a countable figure that could be compared across exchanges.

Conversely, the working thesis is falsified if the operator's published capacity turns out to describe capability rather than deployed state — interfaces that can be ordered but are not in service, or a traffic peak that reflects a single member's migration rather than durable aggregate load. Nothing in the retrieved material supports that reading, but nothing excludes it either.

Reading an identifier divergence correctly

Identifier divergence of the kind recorded here has a small set of ordinary causes, and separating them is a bounded exercise rather than an open-ended suspicion. The first is duplication: two records created for one exchange, usually by different contributors, neither withdrawn. The second is history: an entry retired and replaced when an exchange changed operator, name or scope, with the old record left resolvable. The third is scoping: one record describing the exchange as an organisation and another describing a specific peering LAN, a regional presence, or a route-server service.

The fourth is error: a mis-keyed or mis-merged entry nobody has corrected.

Each cause carries a different implication for anyone citing the count. Duplication and error mean the published figure may double-count or misattribute; history means the figure may be stale; scoping means the figure may answer a narrower question than the reader asked. None of them means the exchange is misrepresenting itself, because in every case the divergence sits in a volunteer-maintained directory rather than in the operator's own publication.

That asymmetry deserves stating plainly: an operator's pages and a directory's entries are not the same kind of claim, and a disagreement between two directory records says nothing about the operator's honesty.

What would settle it is unglamorous. Creation and update timestamps on both records, the operator field each carries, the facility list each attaches, and any alias or redirect between them would separate duplication from history from scoping in a single pass. That is the test to apply before treating either identifier as canonical, and until it is applied the correct posture is to cite the count as a floor with a named source and a retrieval date — which is what this report does.

Evidence boundaries

The limits of this report are the limits of its retrieval. The retained page summaries carry no verbatim excerpts, so no sentence here quotes the operator or the aggregator. Participant count, interface speeds and traffic peaks arrive without a method statement, a measurement window or independent corroboration.

The directory card's single registry edge does not establish ownership of AS33108, operation of the fabric, control of AS10297 or any particular legal form, and the card's own "private company" and "Global" attributions sit unreconciled against the operator's "non-profit" self-description — a discrepancy this report records rather than resolves, because no corporate filing, non-profit registration or leadership record was obtained.

The two listing identifiers remain open for the same reason. Duplicate, historical, alias and differently scoped records are all live explanations, and choosing one without evidence would manufacture the canonicality the record lacks.

What survives all of that is narrower than a profile and more useful than one. Seattle Internet Exchange is a dense, high-capacity Seattle fabric whose operator publishes 400G capability, route-server peering under AS10297 and terabit-scale peaks, and whose participant population is listed at more than 350 networks across two named sites. The registry edge that introduces it is a pointer to an autonomous system, not a measurement of the exchange. Between those two statements sits the entire question of who actually runs the fabric — and that question is still open.