Summary
- RIPE NCC's RDAP record assigns the exact AS31605 object to the registry name ALLOY-NETWORKS and identifies Titanium OU as the registrant organisation.
- A RIPEstat overview marked AS31605 announced at one stated query time, while Hurricane Electric separately listed one IPv4 prefix, one IPv6 prefix and one observed peer.
- Titanium OU's official page describes Alloy Networks as its enterprise-infrastructure division and says the organisation operates a data center and its own ASN; those remain attributed first-party statements.
Why one number appears in several records
An autonomous system number, or ASN, is an identifier used when networks exchange routing information on the internet. It does not name a building, measure a service or certify a company by itself. Its practical value is narrower: it gives different public records a common key. When AS31605 appears in a directory, a regional internet registry, a routing-data product and a network profile, a reader can compare those records without assuming that they all answer the same question.
That distinction is the starting point for understanding Titanium OU. A directory page establishes the selected editorial subject. RIPE NCC's registration data identifies the administrative object and registrant. RIPEstat reports what one product said at a particular time. Hurricane Electric publishes a separate BGP-oriented profile. The organisation's own page describes its business and infrastructure in its own words.
These layers can reinforce an identity, but they use different verbs. A registry records. A routing product observes or classifies. A company describes. Treating those verbs as interchangeable would produce claims the sources cannot support. An administrative status does not show that packets moved. An observed route does not prove who owns a facility. A company statement does not independently verify performance.
The directory fixes the editorial subject
The BTW directory entry names the selected entity as NETWORKS Titanium OU and displays AS31605. That exact pairing creates a stable starting point for the other sources. It helps distinguish this subject from organisations with similar words in their names and from network records that belong to a different autonomous system.
The directory's role should remain limited. It is a navigation and identity record, not an independent measurement of routing. It does not establish which prefixes were visible, whether a route was authorised, where equipment was located or how a service performed. Its value is that every later comparison can be tied back to the same entity and ASN.
The wording also foreshadows an identity bridge that becomes clearer in the external records. RIPE uses the name ALLOY-NETWORKS for the ASN and Titanium OU for the registrant. The official page uses Alloy Networks as a brand and states that it is a division of TITANIUM OÜ. AS31605 is the common network identifier across those variations; it does not erase the difference between a directory label, a registry name, a legal organisation and a brand.
RIPE NCC records the administrative ASN object
RIPE NCC's RDAP response covers an autonomous-system object whose handle is AS31605. Its start and end values are both 31605, so the object refers to that single number rather than to a broader range. The registry name is ALLOY-NETWORKS, and the status array contains active. The registrant entity is ORG-TO320-RIPE, formatted as Titanium OU.
The response records a registration event on 22 June 2004 and a last-change event on 13 October 2023. Those timestamps belong to the administrative object. They help readers understand when the record was created and when it was last updated, but they do not form an operating history. Nothing in those two fields demonstrates continuous routing, uninterrupted service or unchanged corporate circumstances between the dates.
The word active requires the same care. In RDAP it is a status attached to the registry object. It should not be expanded into “the network was reachable,” “the routes were authorised” or “the data center was operating normally.” Registry data is valuable precisely because it preserves a structured association among a number resource, a registry name and a registrant. That administrative association is one part of the public record, not a substitute for observations of the running network.
This is why the registrant bridge matters more than an inflated reading of the status. Titanium OU appears as the organisation responsible for the object, while ALLOY-NETWORKS is the registry name attached to AS31605. The official page later connects those terms through the Alloy Networks division statement. The sources therefore align on identity without requiring the registry to prove physical assets, commercial relationships or technical performance.
RIPEstat supplies a time-bounded routing observation
RIPEstat's AS Overview answers a different question. In the response used here, the resource was 31605, the type was as, and the holder was ALLOY-NETWORKS Titanium OU. The field announced was true. The query start and end were both 9 August 2026 at 08:00 UTC.
That result supports a deliberately narrow sentence: RIPEstat marked AS31605 announced for that stated query time. It does not support a permanent or universal conclusion. Routing data depends on collection points, processing rules and timing. A route may be visible from one set of vantage points while particular users, applications or destinations experience something different. Conversely, an absence in one product would not by itself prove that no route existed anywhere.
The observation also does not decide origin authorisation. “Announced” describes a routing state reported by the product; it is not the same as a registry allocation, a route-origin authorisation or a legal permission. Those questions require evidence designed for them and, where relevant, examination of the specific prefixes involved.
The timestamp is therefore part of the fact, not a footnote. Administrative records can remain stable while routing changes. A bounded observation can show how the ASN appeared to a product at one moment, but it cannot establish continuity before or after that moment. Readers should resist words such as “always,” “fully” and “everywhere” when the source provides a single dated view.
Hurricane Electric adds a separate BGP-oriented profile
Hurricane Electric's page identified the subject as AS31605 Titanium OU and labelled the country of origin Estonia. At the time represented by the page, it listed two originated prefixes in total: one IPv4 prefix, 45.139.107.0/24, and one IPv6 prefix, 2a13:cec0::/29. It also displayed two originated routes as RPKI valid and zero as invalid.
Those figures add detail beyond the RIPEstat boolean, but each remains attached to the page and its observation. Two listed prefixes do not measure customer count, traffic, capacity or business scale. One IPv4 and one IPv6 entry do not reveal how addresses were used inside the organisation, which applications depended on them or whether other resources existed outside this ASN.
The RPKI labels need similar precision. For the two routes shown, the profile displayed valid origin-validation results. That is useful security metadata for those listed observations. It is not a blanket statement that every route associated with Titanium OU was authorised, secure or correctly configured at every other time. A full authorisation question would require the relevant route-origin records, prefix lengths, origins and observation time to be examined together.
The same page showed one observed BGP peer, AS3249 Telia Eesti AS. “Observed peer” is the accurate description. It does not prove exclusivity, a contract, a complete upstream inventory or a fixed topology. Public collectors may not reveal private sessions, changing relationships or every path available to a network. A single listed neighbour also says nothing by itself about redundancy, resilience, latency or service quality.
RIPEstat and Hurricane Electric agree on the ASN-level identity and both present evidence of routing activity, but they are not duplicate proof. They are separate products with different fields and methods. Their agreement supports a bounded account of AS31605 in public routing records; neither can be promoted into universal reachability or a complete map of the network.
The official page supplies attributed data-center context
The official homepage describes Alloy Networks as an enterprise-infrastructure company and says it is a division of TITANIUM OÜ, a company registered in Estonia. That statement supplies the clearest bridge among the Alloy Networks brand, the Titanium OU legal name and the ALLOY-NETWORKS registry label.
The page says the organisation owns and operates its own data center in Estonia. It also says it operates under its own ASN with upstream peering to Telia. These statements fit the network records: AS31605 appears under the Titanium OU and ALLOY-NETWORKS identity, and Hurricane Electric listed AS3249 Telia Eesti as an observed peer. The fit is informative, but attribution remains essential. The homepage is the company's own description. The registry and routing pages do not independently verify ownership of a facility, its location, the terms of an upstream relationship or the condition of any equipment.
The company positions its work as purpose-built enterprise infrastructure and explicitly says it does not offer low-cost commodity cloud services. It lists examples involving business systems, storage and mail, and it describes providing high-speed mirrors for open-source software downloads. Those descriptions explain why a data-center category is a reasonable editorial classification. They do not establish capacity, utilisation, uptime, support quality, service-level performance or customer results.
The category itself must stay in its proper role. company-region-global-type-datacenter is publication metadata confirmed for this article. It helps readers and systems organise the subject. It is not an additional source and cannot turn the company's facility statement into independently verified ownership. A category can describe the editorial frame without proving every physical claim associated with that frame.
Where the sources agree—and where they do not
The strongest agreement is identity. The directory pairs NETWORKS Titanium OU with AS31605. RIPE RDAP associates AS31605 with ALLOY-NETWORKS and the registrant Titanium OU. RIPEstat uses the holder string ALLOY-NETWORKS Titanium OU. Hurricane Electric titles the page AS31605 Titanium OU. The official page then states that Alloy Networks is a division of TITANIUM OÜ.
That chain makes it reasonable to discuss the records as parts of one subject. It does not make every statement interchangeable. RDAP's active status is administrative. RIPEstat's announced=true is a product observation at a stated time. Hurricane Electric's prefixes, validation labels and peer count belong to its profile. The data-center and upstream statements come from the organisation itself.
The independent routing profile and the first-party page also show how corroboration can be useful without becoming proof of more than it says. Both mention Telia in different ways: one lists AS3249 as an observed peer, while the other says there is upstream peering to Telia. Together they show consistency in the public record. They still do not reveal a contract, whether the relationship was exclusive, how traffic was exchanged or whether the relationship changed after the observations.
What remains outside the public evidence
The five sources do not measure traffic, throughput, latency, packet loss, capacity, uptime or resilience. They do not establish customer totals, revenue, staffing, market share or geographic service reach. They do not provide an inventory of facilities, racks, routers, fibre paths or power systems. They do not independently verify that a particular building or piece of equipment belongs to Titanium OU.
They also do not support a broad security judgment. Two RPKI-valid entries are meaningful for the routes shown, but they are not an audit of every possible announcement, internal system or operational practice. The official page's statement about clean address blocks is a first-party assertion and is not independently tested by the other sources, so it should not be used as a conclusion here.
These limits are not evidence of a problem. They define the questions the records were built to answer. Administrative accuracy, observed routing and first-party business description are all useful when kept within their boundaries. Performance would require measurements. Facility ownership would require independent corporate or property evidence. A complete topology would require broader and methodologically explicit network data.
A practical way to read an ASN profile
Readers can apply a simple sequence to AS31605 or any similar profile. First, confirm the exact number and subject. Check that the directory entry, registry handle and external profile all refer to the same ASN rather than to a similar company name.
Second, separate administrative fields from observations. Use RDAP for the number range, registry name, registrant and record events. Use a routing product for a dated statement about announcements. Keep the product name, timestamp and returned field attached to any routing sentence.
Third, treat counts as descriptions, not verdicts. Prefix totals do not measure business size. A peer count does not reveal every relationship. RPKI labels should be discussed for the listed routes and observation, not converted into a universal authorisation or security claim.
Fourth, attribute company statements. The Alloy Networks page gives valuable context for the data-center framing and the link to Titanium OU. Phrases such as “the company says” or “the page describes” tell readers where that information comes from and prevent a first-party statement from appearing independently verified.
Finally, match any follow-up question to the evidence it needs. Route authorisation calls for prefix-specific origin evidence. Reachability calls for observations from defined vantage points. Performance calls for end-to-end measurements. Facility ownership or capacity calls for independent physical and corporate documentation. This method turns a collection of public records into a clear network-identity account while leaving unsupported conclusions where they belong: outside the record.
Following the identity chain without collapsing it
An identity chain is useful because internet infrastructure often has more than one public name. A directory may display an editorial label, a registry may preserve a network name, a legal record may identify an organisation, and a website may present a brand. The presence of several names is not automatically a contradiction. The careful question is whether the records contain a reliable bridge that lets a reader follow one layer into the next.
For AS31605, the number itself is the strongest fixed reference. The directory attaches that number to NETWORKS Titanium OU. RDAP gives the same number the registry name ALLOY-NETWORKS and names Titanium OU as the registrant. RIPEstat joins the registry-style network name and the organisation name in its holder field. The Hurricane Electric profile again pairs the number with Titanium OU. The official page supplies the final brand-to-organisation statement by describing Alloy Networks as a division of TITANIUM OÜ.
This sequence is stronger than matching on a single word. “Networks,” “alloy” or “titanium” could each appear in unrelated contexts. AS31605 sharply narrows the comparison, while the registrant and division statements connect the remaining labels. A reader can therefore recognise one reporting subject without pretending that every label has the same legal or technical role.
The distinction matters when describing responsibility. A registrant association says who is recorded against the number resource. A brand statement says how the organisation presents a business division. Neither field alone proves who owns every device, signs every commercial agreement or performs every operational task. Even when the identity bridge is solid, the scope of responsibility still has to follow the words in the source.
The same method helps avoid a common error in infrastructure reporting: starting with a familiar company name and then gathering records that merely look similar. Beginning with the exact ASN reverses that process. The number selects the administrative and routing objects first; the organisation and brand fields then explain how those objects relate to the directory subject. That order produces a more defensible account and is easier for a non-specialist to audit.
It also leaves room for future change. A registry name, legal registrant, brand or website presentation can change at different times. The five captured sources describe a specific evidence set, not an eternal naming rule. If a later reader finds a changed field, the right response is to compare dates and source roles, not to retroactively treat the earlier record as false or the new record as proof of an uninterrupted history.
Why the dates belong in the meaning of each claim
The sources in this account operate on different clocks. RDAP records an administrative creation event and a later modification event. RIPEstat reports a routing-related field for a stated query time. The Hurricane Electric page presents the values visible in its profile at the captured observation. The official page offers a company description as presented by the company. Reading all of those fields as if they were one simultaneous measurement would hide an important part of the evidence.
The RDAP dates are easiest to misunderstand. A registration event tells the reader when the registry object records its creation. A last-change event tells the reader when that record says it was modified. Neither timestamp describes every event in the network's operating life. The period between 2004 and 2023 cannot be filled with assumptions about continuous announcements, service availability, ownership or business activity simply because those two dates appear in one administrative response.
The RIPEstat timestamp works differently. Its announced=true field belongs to the query interval stated by the product. The useful sentence therefore includes both the product and the time. Removing either part makes the statement broader than the evidence. “RIPEstat marked AS31605 announced at that query time” is supported. “AS31605 is always reachable” is not. The first describes a bounded observation; the second makes a continuing and user-wide claim.
The profile counts also need an observation frame. A list of prefixes or peers can change as routing changes or as a data product updates its view. The captured page supports a report of what it listed then. It does not establish that the list was complete before the observation, remained unchanged afterward or represented every private relationship at the same moment.
First-party pages have their own timing problem. A homepage can describe how a company presents its activities, but a captured statement is not a continuously audited operational feed. The safest use is attribution: the page says the organisation operates a data center and its own ASN. If a reader needs to know whether a particular facility, relationship or service is operating at a later instant, that question calls for new evidence designed for that purpose.
Keeping these clocks separate is not merely cautious wording. It makes updates easier. A future change in routing does not erase a registry event, and a later registry modification does not tell us what a routing product saw earlier. Each source remains valuable when its timestamp, method and subject are kept attached to its claim.
What the two prefix listings actually add
The Hurricane Electric profile adds specificity by naming one IPv4 prefix and one IPv6 prefix under AS31605. For a general reader, a prefix can be understood as a block of internet addresses described in routing records. An autonomous system may originate such a block so that other networks can learn a path toward it. The listed IPv4 and IPv6 entries therefore show how the profile represented two address families for this ASN at the time of observation.
That description is useful, but the number two should not carry more weight than it can bear. It is not a count of buildings, servers, customers, applications or employees. It does not reveal how many individual addresses were in active use, which services answered on them or how much traffic crossed the network. It also does not measure the commercial importance of the organisation. Prefix counts describe routing entries, not business scale.
The IPv4 and IPv6 distinction is similarly narrow. Seeing one entry of each type shows that the profile listed originated routes in both address families. It does not show that every service was available over both, that users received equivalent paths, or that the organisation had reached any particular level of deployment. Those questions would require measurements or service-specific records beyond the five sources used here.
The exact entries help with verification because they give a reader something more concrete than an ASN-level label. They can be checked against a routing or authorisation source appropriate to a prefix-level question. Yet even that follow-up needs a defined time and method. A route present in one table may not be visible from every observation point, and a later change does not alter what the captured profile displayed.
The profile's two RPKI-valid labels add another dimension, but they remain labels attached to the listed originated routes. They should not be merged with the prefix count into a sweeping claim that the network is secure. Origin validation addresses a specific relationship among a prefix, an authorised origin and a route announcement. It does not inspect applications, internal controls, facility security or the reliability of services carried over the addresses.
For readers, the most productive interpretation is modest: the profile offered a compact, dated view with one IPv4 entry, one IPv6 entry and validation labels for the two listed routes. That view supports a transparent description of the public routing record. It does not answer operational or commercial questions that the table was never designed to measure.
How to understand the RPKI labels without a security shortcut
RPKI, or Resource Public Key Infrastructure, is commonly used to publish information that helps validate whether a particular autonomous system is authorised to originate a particular prefix under stated conditions. In a route-origin view, a “valid” result is meaningful because the observed prefix and origin align with the relevant authorisation data used by the validation process. It is still a result about a specific route-origin relationship, not a general certificate of network safety.
The Hurricane Electric profile displayed two originated routes as RPKI valid and zero as invalid. The supported conclusion is that the profile showed those validation labels for the two routes it listed at the observation. A stronger sentence—such as saying that all routes were permanently authorised—would require knowing that the set was complete and unchanged, that the relevant authorisation data remained the same and that the validation covered every announcement of interest.
The distinction becomes clearer by separating three questions. The registry question is who and what are recorded against AS31605. The routing question is what a data product observed being announced. The origin-validation question is how a listed prefix-origin pair compared with authorisation information. The answers may be consistent, but one does not automatically answer the others.
Security is broader still. A valid route-origin result does not measure application vulnerabilities, account protection, physical access, software maintenance, incident response or the integrity of customer systems. It does not promise uptime, low latency or resistance to every routing incident. Calling the entire network “secure” from two validation labels would therefore confuse a narrow control with an all-purpose judgment.
The zero-invalid figure also needs restraint. It describes what the profile displayed, not proof that an invalid announcement could never appear elsewhere, at another time or outside the listed set. Zero is often rhetorically tempting because it sounds definitive. Here it remains a count in a bounded page, alongside a particular set of routes and a particular observation.
None of this reduces the value of the labels. On the contrary, precise language makes them more useful. They contribute security metadata to the public picture of AS31605 and show that route-origin information can be compared separately from registration and visibility. Readers can appreciate that contribution without extending it into an unsupported endorsement of every system or practice associated with Titanium OU.
One observed peer is a clue, not a topology map
The Hurricane Electric page listed one observed peer, AS3249 Telia Eesti AS. The official page separately says that the organisation operates under its own ASN with upstream peering to Telia. The two records are consistent at the level of the names they present. They do not, however, provide a complete description of how traffic enters or leaves the network.
An observed peer in a public profile reflects what that product could infer or display from its data. It is not necessarily a list of every private interconnection, backup arrangement, customer relationship or path visible from every part of the internet. A single entry can therefore be reported as a single observed peer, but it cannot safely be described as the organisation's only relationship.
The commercial meaning is also unresolved. The public records used here do not contain a contract. They do not state pricing, term, capacity, exclusivity or service obligations. The official page uses the phrase upstream peering, while the third-party profile supplies an observed ASN relationship. Those statements can be quoted or paraphrased with attribution, but they cannot be transformed into a verified commercial agreement.
Nor does a peer count measure resilience. Resilience depends on more than how many names appear in one public table. Physical paths, equipment design, routing policy, private sessions, power, operational procedures and the failure being considered can all matter. None of those elements is documented by the five-source set. The record therefore cannot support a conclusion that the network is either resilient or fragile.
For a non-specialist, a useful mental model is a partial public view. The profile shows one relationship that appeared in its data. The company page describes a related upstream connection in its own terms. Together, those pieces help explain how AS31605 appears in the public record. They do not draw every line in the network.
This boundary is especially important because topology diagrams and peer counts often look authoritative. A neat table can create the impression of completeness even when its data comes from limited observation points. The responsible reading keeps the word “observed” attached to the peer and treats any broader topology question as open until a source with an explicit, suitable method answers it.
Reading the company page as evidence, not as an audit
The official page is indispensable for understanding why the directory candidate belongs in a data-center article. It provides the organisation's own explanation of Alloy Networks, links that brand to TITANIUM OÜ and describes enterprise infrastructure, a data center, an ASN and an upstream relationship. Without that page, the registry and routing sources would describe a network identity but say much less about the business context in which the organisation presents it.
First-party evidence is not defective simply because it is first-party. It is the appropriate source for statements about how an organisation names a division, positions its services or describes its own activities. The key is to preserve attribution. “The company says” and “the official page describes” are not evasive phrases; they tell the reader exactly whose claim is being reported.
Attribution also prevents a subtle chain of overstatement. The official page says the organisation owns and operates its own data center in Estonia. The publication category reflects data-center semantics. The registry names Titanium OU as the ASN registrant. Those facts fit together, but neither the category nor the ASN record independently inspects a building or confirms title to property. Repeating the company statement without attribution would make the combined record look more independently verified than it is.
The same principle applies to the upstream statement. The public BGP profile listed an observed peer whose name is consistent with Telia, while the company page describes upstream peering to Telia. That agreement is worth noting. It still does not establish the private terms, physical path or current condition of the relationship. Agreement between a first-party statement and a public observation can strengthen identity and context without proving every implied detail.
The page's description of purpose-built enterprise infrastructure, business systems, storage, mail and open-source mirror activity helps a reader understand the intended use case. It does not measure how much infrastructure exists, how heavily it is used or how users experience it. The statement that the company does not offer low-cost commodity cloud services is likewise a positioning statement, not a comparative performance test.
The practical rule is simple: use the official page for the organisation's own identity and service description, then look elsewhere for claims that require independent measurement or verification. This produces a fair account. It neither dismisses the company's description nor lets it stand in for evidence it was not designed to provide.
The data-center category is an editorial lens
The category company-region-global-type-datacenter tells readers how this article is organised within the publication. It reflects the candidate-level semantics supplied by the official page, which describes a data center and enterprise infrastructure. The topic network-resource-evidence signals that the article focuses on the records surrounding AS31605 rather than on a service assessment or a performance test.
Metadata is useful because it creates consistent navigation. A reader interested in network-resource evidence can find articles that explain registries, routing observations and infrastructure identities. A reader interested in data-center organisations can see why this subject belongs in that editorial group. The category and topic make those connections without adding a sixth source.
That last point is essential. A category cannot verify its own premise. Classifying the article as data-center related does not prove the size, location, ownership, staffing or operating condition of a facility. Those remain claims that must be tied to evidence. In this case, the official page supplies an attributed data-center statement, while the independent registry and routing sources supply network-identity evidence.
The global region label should be read in the same editorial sense. It organises the article in the publication's taxonomy. It is not a claim that Titanium OU has a global customer footprint, universal reach or facilities in multiple countries. The source set does not establish those propositions, so the metadata must not be paraphrased into them.
Separating taxonomy from evidence also protects future readers. Categories can change as a publication improves its organisation, while the underlying source record remains the same. If the article were moved to a different editorial grouping, that action would not alter the RDAP object, the RIPEstat observation, the Hurricane Electric profile or the company's own statements.
For this article, the category provides a useful lens: it explains why a company page discussing a data center is being read alongside ASN records. The evidence still carries the factual weight. The directory identifies the subject, RDAP records the administrative object, RIPEstat supplies the bounded announcement field, Hurricane Electric supplies the profile details and the official page supplies attributed business context.
Questions that would require different evidence
The five-source set answers an identity question well: how NETWORKS Titanium OU, Titanium OU, Alloy Networks, ALLOY-NETWORKS and AS31605 connect in public records. It also answers several bounded descriptive questions about the registry object and the captured routing profiles. Many practical questions remain open because they require different methods.
To evaluate reachability, a researcher would need observations from defined locations and times. A single announced=true field does not show whether every user could reach every service. Tests would need to state the destinations, vantage points, protocols and timing, and their results would still be measurements of those conditions rather than a universal verdict.
To evaluate performance, the evidence would need metrics such as latency, loss or throughput gathered through a disclosed method. Prefix counts, an ASN status and a peer name do not provide those measurements. Performance also changes with path, workload and time, so a credible study would need more than one unexplained number.
To evaluate resilience, a researcher would need evidence about physical and logical diversity, dependencies, failover behaviour and the failures under consideration. One observed peer cannot show whether paths share facilities or equipment. The absence of other peers from a public profile cannot prove they do not exist. A resilience conclusion without that information would be speculation.
To verify facility ownership or location independently, the evidence would need suitable corporate, property or physical documentation. The official page can be accurately reported as the company's statement, but the registry record concerns the ASN, not title to a building. A generated or illustrative data-center image would not provide proof either.
To assess route-origin authorisation comprehensively, a researcher would need the relevant route-origin data for the prefixes and times in question, together with the exact announcements being evaluated. The two valid labels in the captured profile are useful but do not automatically cover every possible prefix, origin, path or later change.
To assess service quality or customer outcomes, evidence would need to come from a suitable and transparent source rather than from identity records. The five sources contain no customer totals, contracts, service-level results or audited operating metrics. Their silence should not be read as either praise or criticism; it simply marks the boundary of this article.
Listing these unanswered questions makes the evidence more useful. Readers can see what the record establishes, what it suggests and what it leaves for another investigation. That is a stronger result than filling the gaps with assumptions based on technical-looking fields.
A step-by-step verification worksheet
A reader who wants to check this account can begin with the directory entry. Record the exact entity label and ASN. Do not yet make a routing or facility claim. The purpose of this first step is only to fix the editorial subject and avoid mixing records from similarly named organisations.
Next, open the RDAP object and confirm that the handle and number range refer exactly to AS31605. Note the registry name, status, registrant and event dates. Label those facts “administrative.” This simple label prevents the status from being mistaken for a live network test.
Then read the RIPEstat response with its time field visible. Record the product, resource, holder, announced value and query interval together. If any one of those elements is omitted, the resulting sentence may sound broader than the source. The observation should remain a product-specific snapshot.
The fourth step is to inspect the Hurricane Electric profile. Note the exact ASN identity, the IPv4 and IPv6 entries, the RPKI labels and the observed peer. Add the words “profile listed” or “profile displayed” to the notes. Those words preserve the distinction between what the page showed and what might exist outside its view.
Fifth, read the official page for the brand-to-organisation bridge and the organisation's own infrastructure description. Mark each such item “first-party.” The page is the right place to learn how Alloy Networks describes its division, data-center activity and ASN relationship. It is not an independent audit of physical assets or service results.
After collecting the notes, compare only fields that answer the same question. ASN and organisation names can be compared for identity consistency. A routing observation can be compared with another routing profile at a bounded level. A company description can be checked for consistency with the identity record. An administrative status should not be compared with latency or uptime because the source contains no such measurement.
Finally, write down the unanswered question before seeking another source. If the question is reachability, look for reachability measurements. If it is ownership, look for independent ownership evidence. If it is authorisation, inspect prefix-specific origin data. This question-first method reduces the temptation to reuse a convenient record for a purpose it cannot support.
The worksheet is intentionally repeatable. It can be applied to another ASN without assuming that the same names, counts or relationships will appear. Its value lies in the sequence: identity, administration, observation, independent profile, first-party context, comparison and explicit limits.
Why precise language produces a more useful record
Technical infrastructure reporting often becomes misleading through small changes in verbs. “Registered” becomes “operating.” “Observed” becomes “available.” “Valid” becomes “secure.” “Peer” becomes “exclusive upstream.” “The company says” disappears, leaving a first-party claim that sounds independently established. None of those changes requires an invented number, yet each changes what the evidence appears to prove.
The AS31605 sources make those risks visible. RDAP can accurately record an active object while saying nothing about current packet delivery. RIPEstat can report an announcement at a particular time without promising universal reachability. A BGP profile can display prefixes, validation labels and a peer without presenting a complete topology or commercial contract. A company can describe a data center without the other sources independently inspecting it.
Precision does not make the article less informative. It tells the reader exactly where confidence comes from. The identity chain is strong because the ASN, registry names, registrant and brand statement align across the records. The routing description is useful because its timestamp and products are named. The data-center context is relevant because the company statement is clearly attributed.
This approach also avoids turning neutral records into advocacy. The evidence neither endorses nor condemns Titanium OU. It describes an administrative ASN object, two bounded routing views and the organisation's own infrastructure positioning. It identifies the limits of each layer and leaves performance, ownership, resilience and customer outcomes to evidence capable of answering those questions.
For readers outside network operations, that separation is the central lesson. Public internet records are powerful when their purpose is respected. The directory helps locate the subject. The registry preserves the number-resource association. Routing products show parts of the running system from their own perspectives. The company page explains how the organisation presents itself. The clearest account is built not by choosing one layer as the whole truth, but by fitting the layers together without erasing their boundaries.