Summary
- The legal and network identities align unusually well. Platinum Hedgehog Consultancy Limited was incorporated in England in December 2019, the matching domain was registered that month, RIPE records named the company as a Local Internet Registry in January 2020, and AS39715 was assigned to it in February 2021.
- The commercial evidence points in the opposite direction. Companies House shows dormant accounts for every completed year through 2024, the public domain displays a parking page, and no public catalogue, customer terms, service-level promise, security statement or support schedule was found. An active company and an active route are not evidence of an active customer service.
- The network record is narrow but meaningful: one IPv4
/24was visible throughout the observation window, its route origin was RPKI-valid, and current route collectors saw it through Cloudflare. LMAX maintains several registrations and supplies the technical and abuse contact. Those links establish operational dependencies, not ownership, product performance or a right for a platinumhedgehog customer to call either company for help.
The most important finding is the boundary of the evidence
Research on a small infrastructure name often begins with a search for a product page and ends, too quickly, with one of two conclusions. A polished website is accepted as proof of a functioning service, or the absence of one is treated as proof that nothing real exists. platinumhedgehog fits neither conclusion. Its public commercial surface is almost empty, while its internet-number-resource surface is specific, current and technically coherent.
That combination makes it a useful test of infrastructure diligence. A company can be incorporated, hold an address allocation, originate a route and maintain an abuse contact without offering a public cloud or hosting product. Conversely, a service brand can sell hosting without holding any address space or autonomous-system number of its own. The records answer different questions. Conflating them creates a false assurance that is especially dangerous when a buyer is trying to locate responsibility for data, outages or security events.
The Companies House overview identifies Platinum Hedgehog Consultancy Limited as an active private company, number 12376422, incorporated on December 23, 2019. It gives a registered office in Addingham, West Yorkshire and classifies the business under other information technology service activities. Those details establish a legal identity and a place for formal correspondence. They do not establish that the company is trading, employing engineers, accepting customers or supplying any particular technology.
The filing history supplies the decisive counterweight. Accounts for 2020, 2021, 2022, 2023 and 2024 were all filed as dormant. The latest confirmation statement, dated December 2025, reported no updates. Companies House explains that a company is dormant for its purposes when it has had no significant accounting transactions during the relevant financial period. Dormancy is therefore not a stylistic label. It sharply limits what can reasonably be inferred about a customer-facing operation.
At the same time, the company is attached to live internet resources. The RIPE registration for AS39715 names the network platinumhedgehog and the registrant Platinum Hedgehog Consultancy Limited. The address registration for 195.12.36.0/24 connects the same legal entity to 256 IPv4 addresses. Current route observations show that block being announced. The accurate conclusion is not that the company is fictitious, nor that it is a proved service provider. It is that the public record supports resource stewardship more strongly than commercial delivery.
That difference should govern every later claim. A purchaser needs to know what is sold, who signs the agreement, who operates the service, which assets carry it, who can change them, who handles an incident and how the customer leaves. The present evidence answers only parts of the identity and network questions. It leaves the sale, contract, operating model and customer remedy largely unanswered.
A coherent identity formed across fourteen months
The identity timeline is compact enough to be persuasive. Nominet's registration response for platinumhedgehog.co.uk dates the domain to December 10, 2019. Thirteen days later, the company was incorporated. The RIPE organisation registration was created on January 8, 2020, and the IPv4 allocation followed two days later. AS39715 was assigned on February 12, 2021. These dates are consistent with a legal entity formed partly to hold or administer internet-number resources.
Companies House also makes the control structure legible. The officers page lists Andrew Stewart Millar as both director and secretary from incorporation. The significant-control page records him as holding at least 75 per cent of shares and voting rights, with the power to appoint or remove directors. That is a much clearer accountability chain than an anonymous hosting storefront.
Clarity about control is valuable, but it is not the same as depth of organisation. One director can competently administer a narrowly defined asset. The same structure can also create key-person risk if customers depend on rapid decisions, account recovery, abuse handling or out-of-hours escalation. The record does not say how many people perform technical work, whether duties are delegated, or who can act if the director is unavailable. It does not identify an operations team employed by Platinum Hedgehog Consultancy Limited.
The registered office and network registration both use the Addingham address. That consistency lowers the risk of matching the wrong company to the network. It does not show that network equipment, staff or customer data are in Addingham. RIPE's own requirements distinguish the legal country and contact information of a resource holder from network geolocation. A postal address is an accountability point, not a data-centre map.
The domain adds another identity signal, but not a product signal. When examined, platinumhedgehog.co.uk resolved to a Fasthosts shared-hosting address and displayed a domain-parking page. It did not present a service catalogue, corporate history, customer login or support material. The HTTPS version did not provide a usable page during the observation. The domain remains registered and has working mail-routing information, so this is not the same as an abandoned name. It is simply not a public service surface.
That separation is revealing. The company's web name does not sit in the company's own /24; it uses a third-party shared-hosting address. There is nothing inherently wrong with that. Many network operators keep their public website away from operational address space to reduce common failure or simplify administration. Yet it means a successful visit to the domain would not test AS39715, and a failure of the domain would not establish a failure of the company's routed block.
The identity evidence therefore deserves a qualified high mark. The legal name, domain, address, director, company number, RIPE registrant and ASN label fit together. What remains absent is an explanation of purpose. A prospective customer cannot tell from those records whether the company was formed as a personal consultancy, a resource-holding vehicle, a network experiment, a related company's administrative arrangement or the beginning of a service that never opened publicly. That question must be answered by the company, not filled with assumptions.
Dormant accounts and live routes can coexist, but they do not explain each other
The apparent contradiction at the centre of platinumhedgehog is an active route attached to a company that has repeatedly filed dormant accounts. It is tempting to resolve this by choosing one record and dismissing the other. A better approach is to preserve both facts and ask what operating arrangement could reconcile them.
Companies House guidance on dormant accounts says dormancy means no significant accounting transactions during the period, aside from a narrow set of excluded items such as initial subscriber shares and certain filing fees. The filings therefore weigh strongly against claims of ordinary paid consultancy, hosting subscriptions, payroll, supplier bills or customer revenue in the company through the end of 2024. They do not prove that no one maintained registrations or equipment associated with the company name.
RIPE explains that a member acting as a Local Internet Registry can manage number resources, contact details, billing information and resource certification through its member portal. Membership normally carries financial and administrative obligations. The public records reviewed here do not show who pays those obligations, whether another party acts on the company's behalf, or how any such arrangement is accounted for. It would be reckless to allege an error in either record without the underlying agreements and accounts. It would be equally reckless to pretend the tension does not matter.
For a buyer, the issue is less accounting theory than enforceable responsibility. If platinumhedgehog is offered as a service, the customer should ask whether Platinum Hedgehog Consultancy Limited is the contracting provider or merely the registered holder of number resources. The invoice beneficiary, service operator, support team and resource holder should be named separately where they differ. The agreement should explain which party can change routes, terminate service, respond to abuse reports and authorise recovery.
The period matters. The latest public accounts cover the year ending December 31, 2024. They do not state what happened after that date. The route registration for the /24 was created in February 2025, and current observations show the route in 2026. A company can cease to be dormant after a financial year and reveal that only in a later filing. The next accounts were due after the date of this review. That timing prevents the dormant filings from being extended automatically into 2025 or 2026.
Even with that caveat, no public commercial material closes the gap. There is no current platinumhedgehog product page explaining a 2025 launch, no customer terms naming a service, and no public price or order mechanism. The post-2024 network activity is evidence that the resource is used. It is not, by itself, evidence that the company began selling a service.
This is why corporate freshness should be checked at the moment of contracting. A current set of accounts, confirmation statement and certificate can confirm legal standing. A signed statement can identify whether the company has begun trading. An invoice and bank account can confirm the payment counterparty. None of those documents establishes network performance, but they prevent a customer from paying one legal entity for a promise operationally controlled by another without understanding the split.
AS39715 is real, small and newly visible in its present form
An autonomous-system number is a routing identity. It lets a network originate routes under a defined policy and appear as a distinct participant in the Border Gateway Protocol. It does not indicate company size, revenue, server count or service quality. In platinumhedgehog's case, the number-resource footprint is unusually easy to describe because it is so compact.
AS39715 is the current routing identity. Its only observed IPv4 announcement is 195.12.36.0/24, representing 256 addresses. The RIPEstat announced-prefix view showed that single prefix continuously visible during the observation interval from June 30 to July 14, 2026. The routing-status view reported one IPv4 prefix, no observed IPv6 announcement and visibility from all 326 IPv4 collector peers included in that snapshot.
These observations establish reachability in the public routing system at the times measured. They do not establish that all 256 addresses were assigned, responsive or used by a service. They do not identify applications, customers, facilities, bandwidth or traffic levels. A /24 can carry a material production workload, a protected endpoint, a laboratory, an unused reserve or a mix of functions. Route visibility reveals a path to the block, not what waits at the destination.
The dates also require care. The IPv4 allocation was registered in January 2020, the ASN in February 2021, but the route registration linking 195.12.36.0/24 to AS39715 was created in February 2025. That does not prove the prefix was silent before then, because registration and observation histories have different coverage. It does show that the current route has a recent administrative milestone well after incorporation and after the latest dormant year then on file.
RIPEstat's historical status contains an even sharper warning against easy chronology. Its earliest observation associated with the number AS39715 predates Platinum Hedgehog Consultancy Limited by many years and involves a different prefix. An autonomous-system number can have a history that is not the history of its current holder. The authoritative present registration date and legal entity must therefore anchor company claims; an old collector timestamp must not be turned into a claim that platinumhedgehog has operated since 2006.
The absence of an observed IPv6 route is similarly narrow evidence. It means the collectors did not see AS39715 originate IPv6 during the snapshot. It does not show that the people involved lack IPv6 skill, that no related network uses IPv6, or that a future service could not support it. For a current purchase, however, it means a buyer cannot point to public routing evidence of platinumhedgehog-originated IPv6. Any dual-stack requirement would need direct technical proof and a written scope.
A small footprint can be an advantage when the purpose is narrow. Fewer prefixes make ownership, route authorization and change monitoring easier. They can also create concentration. If the sole /24 is withdrawn, misconfigured or filtered, there is no second platinumhedgehog prefix visible in the public table to provide an independent origin. Whether that matters depends entirely on the undisclosed function. It would be critical for a customer service built wholly on the block and less important if the range serves one protected auxiliary system.
The registered policy points to LMAX; the observed route points to Cloudflare
The most consequential relationships in the technical record are not disclosed on a corporate website. They appear in the maintenance, contact and routing fields. The AS39715 registration declares imports from AS41477 and AS39498 and exports AS39715 to both. RIPE identifies those two networks as LMAX Limited and LMAX Digital Group Limited. The platinumhedgehog registrations are maintained under the LMAX maintainer, while the technical and abuse role is LMAX IS Networks with an lmax.com address.
That is strong evidence of operational involvement. It means LMAX-controlled credentials or personnel maintain important public registrations, and LMAX receives the published abuse contact. It is not enough to conclude that LMAX owns Platinum Hedgehog Consultancy Limited, owns the address block, sells a platinumhedgehog product or guarantees its availability. Companies House lists an individual, not LMAX, as the person with significant control. No reviewed corporate filing records LMAX as an owner.
Current route observation adds a different dependency. The RIPEstat looking-glass view for the /24 returned 368 paths across its collectors at the review snapshot. Every one had AS13335, Cloudflare, immediately before AS39715. The routing-status summary likewise reported one observed neighbour. Cloudflare Radar identifies AS39715 by the platinumhedgehog name, while a current third-party ASN view also shows Cloudflare as the only observed upstream.
The difference between declared policy and observed path is not necessarily an error. A registry statement can lag an operational change, describe permitted relationships that are not currently visible, or omit a protection arrangement. A route collector sees paths selected at particular observation points, not every private or backup connection. The evidence supports a precise statement: Cloudflare was the sole immediate upstream visible in the collected routes at that time, while the public routing policy named two LMAX networks.
For operational diligence, that distinction matters more than the brand names. A customer should ask which party supplies transit, which supplies route protection, which controls announcements, which can withdraw the prefix and what happens if the visible Cloudflare path is unavailable. It should ask whether the LMAX relationships are standby paths, management relationships, historical declarations or active private connections not exposed to collectors. The answer belongs in a network diagram backed by a support schedule.
No amount of public path counting proves physical diversity. Hundreds of collectors repeating the same immediate upstream increase confidence that the route is broadly visible, but they do not create hundreds of independent links. The common AS13335 hop is evidence of a shared routing dependency. It says nothing by itself about the number of ports, cities, routers, fibres or data centres beneath that relationship.
The support boundary is equally important. An abuse address operated by LMAX gives outsiders a plausible channel for reports involving the block. It does not tell a customer that LMAX will accept an availability ticket, restore an application or discuss a contract. A customer of a hypothetical platinumhedgehog service would need a named route for service support distinct from abuse reporting. Without that, the clearest technical contact may still have no duty to the buyer.
A valid route origin is good hygiene, not a service certificate
The strongest security control visible in the public record is route-origin authorization. The RIPEstat RPKI validation response marked the current announcement valid. It found a Route Origin Authorisation allowing AS39715 to originate exactly 195.12.36.0/24, with a maximum length of /24.
This is meaningful. RIPE explains that RPKI lets a resource holder make a cryptographically verifiable statement about which autonomous system may originate a prefix. Networks performing route-origin validation can reject a conflicting unauthorized origin. Setting the maximum length to the exact /24 avoids authorizing more-specific routes under that statement. For a single-prefix network, that is sound and legible routing hygiene.
RPKI answers only the origin question. It does not validate the entire path between a user and AS39715. It does not prove that Cloudflare or LMAX will remain available, that route changes require two-person approval, that credentials are protected, or that monitoring will catch an outage. It does not authenticate a website or encrypt customer data. RIPE's own BGP origin-validation explanation is explicit that present functionality concerns authorization of the origin, not full path validation.
Nor does a valid origin show that the service at an address is safe. A correctly originated server can run vulnerable software, expose credentials, mishandle personal data or fail silently. A malicious customer can use legitimately routed space. Route authorization reduces one class of control-plane ambiguity; it does not replace endpoint security, access management, logging, backups or incident response.
The control is still useful as evidence of maintained administration. Someone with appropriate resource authority created or maintained the authorization. The route registration and current announcement agree on the origin. That alignment lowers the risk of a simple origin mismatch and gives a buyer a monitorable invariant. If the prefix appears from another origin or loses valid status, an alert can be raised before application users report a problem.
A serious service agreement would turn that public hygiene into an operating obligation. It would require valid authorization for all advertised prefixes, change control for routing credentials, monitoring of route visibility and origin state, and a response path for leaks or withdrawals. It would name who owns each action across Platinum Hedgehog Consultancy Limited, LMAX, Cloudflare and any hosting operator. The present public record does not supply that agreement, so the control should receive credit without being inflated into assurance.
There is no public enterprise-software workflow to evaluate
The fixed classification places enterprise software automation among the relevant topics, but platinumhedgehog publishes no application or control panel that can be tested against it. There is no public account-creation flow, provisioning interface, monitoring console, support portal, billing page or documentation set. The parked domain does not claim that users can create servers, allocate addresses, configure routes or automate any business task.
This absence changes the technical question. It would be inappropriate to invent a workflow from the presence of an ASN. Number resources might support software operated under another brand, or they might be held for a narrow network purpose. The registration fields themselves are maintained through systems run by RIPE and other operators; that administration is not evidence that platinumhedgehog sells enterprise software.
If a private offer exists, the buyer should require a demonstration built around a complete accepted operation. For a network service, that could be allocation of an address, authorization of a route, deployment of a service, observation from outside networks, handling of a controlled change and documented reversal. For consultancy, it could be a defined engineering deliverable with review, handover and support. For hosting, it could be provision, access control, monitoring, backup, restore and deletion. The offered outcome must come from the seller, not from the category attached to the name.
Automation claims should then be measured by work removed and supervision added. A portal that creates a route quickly may save operator time while increasing the risk of a fast misconfiguration. An automatic abuse response may shorten containment while creating false suspensions. Monitoring may detect withdrawal while still requiring a skilled person to distinguish a provider incident from a deliberate change. Useful metrics would include change success, rollback time, false alert rate, incident acknowledgement and reviewer minutes per accepted action.
The current evidence cannot supply any such metric. It contains no customer count, service history, response-time record, availability result or recovery test. It would be misleading to estimate these from the route's visibility. A prefix seen by every RIPE collector in one snapshot can still support an application with poor authentication or no customer support. A service can also be valuable without public benchmarks if a buyer verifies it privately and writes measurable duties into the contract.
The right conclusion is therefore not that the automation is weak. It is that no platinumhedgehog automation product is publicly established. This distinction protects both readers and the company. It avoids criticizing a product that may not exist, while preventing an empty label from receiving unearned credit.
British registration does not settle data locality
The region code GB is well supported at the legal and registration levels. Platinum Hedgehog Consultancy Limited is incorporated in England, the registered office is in West Yorkshire, and RIPE gives the resource holder's country as the United Kingdom. The domain uses a UK registrar and resolves to a Fasthosts shared-hosting range registered in Britain. Those facts make the identity British.
They do not prove where the routed /24 is physically served or where any customer data would be stored. RIPE's requirements analysis explains that the database supports authoritative number-resource registration and operational coordination; geolocation is not one of its purposes, and location fields can be incomplete or user-maintained. A country code for the resource holder is not a rack coordinate.
The observed Cloudflare hop further complicates a simple locality story. A globally distributed network can announce or carry a route through many locations while the origin address space belongs to a British entity. Collector paths can show where routing information is visible, but not necessarily where packets terminate, where storage sits or where an engineer accesses a system. The LMAX contact address in London is similarly a support and registration clue, not proof that the service is hosted there.
A locality-sensitive buyer needs a layer-by-layer map. The legal layer names the contracting company and governing law. The resource layer names the holder of addresses and ASN. The routing layer identifies origin and transit relationships. The compute and storage layer identifies facilities and subprocessors. The support layer identifies where privileged access can occur. The backup layer identifies where copies and logs remain. platinumhedgehog's public evidence covers parts of the first three layers and almost none of the last three.
This is especially important for migration. A customer cannot assume that addresses allocated to the provider can move with an application. The agreement should distinguish portable customer-owned resources from provider-owned addresses, specify renumbering support and set a timetable for data export. Domains, encryption keys and deployment instructions should remain under customer control where possible. A British registration becomes useful sovereignty evidence only when it is connected to the actual service and exit path.
There is no basis here to say that data has left Britain, remained in Britain or been processed at all. There is no public customer-data notice to evaluate. The responsible statement is narrower: the legal and number-resource identities are British, while workload and data locality are undisclosed. Any procurement relying on UK residency would need explicit facility, copy, access and transfer terms.
Local support labour is visible only through someone else's network role
The public support surface is thinner than the technical record. The parked domain offers help from Fasthosts, but that help concerns the parked domain service, not AS39715 or a platinumhedgehog customer product. Companies House provides a registered office, not an incident desk. The RIPE registrations identify an administrative contact and route technical and abuse matters to LMAX IS Networks.
This is enough for basic network coordination. An operator noticing abusive traffic or a registration issue has an attributable channel. It is not enough for a customer deciding whether local support labour justifies a purchase. No platinumhedgehog page states support hours, languages, severity levels, acknowledgement times, escalation authority or resolution objectives. No page distinguishes billing help from engineering help or account recovery from abuse response.
The LMAX role may represent substantial technical competence, but competence and obligation are different. A third party can maintain routing information without accepting support duties to the resource holder's customers. It may act under a private agreement whose scope is narrower than the buyer expects. Only a contract can identify whether LMAX is a subcontractor, related operator, emergency contact or merely the maintainer of public registrations.
Key-person risk remains visible on the corporate side. One individual holds corporate control and both officer roles. That can produce fast decisions and direct accountability in a small operation. It can also leave no public substitute for signing, escalation or account recovery. A material customer should identify at least two authorized contacts, verify how privileges are revoked and establish what happens if the principal cannot respond.
Local support has value when it shortens the path from symptom to action. The relevant measure is not whether a telephone number has a British country code. It is whether the person reached can inspect the affected system, coordinate with Cloudflare or LMAX, make an authorized change, preserve evidence and communicate a recovery estimate. The reviewed record does not show that chain.
A controlled support test would be proportionate if a private offer is made. The buyer could request a low-severity network clarification, an account-security change and an escalation exercise. It should record acknowledgement, useful engagement, ownership transfer and resolution separately. It should confirm the identity checks used for sensitive changes without attempting to bypass them. The findings should then become contractual duties rather than remain impressions from a helpful conversation.
Security accountability spans four separate surfaces
platinumhedgehog's public evidence exposes four security surfaces that should not be collapsed into one. The first is corporate authority: who can bind the company and approve sensitive action. The second is resource authority: who controls the LIR account, route registration and RPKI statements. The third is live routing: who carries and protects the announcement. The fourth is any application or customer service using the addresses.
The company filings clarify the first surface. RIPE and RPKI clarify part of the second. Current path observation illuminates part of the third. The fourth is almost entirely dark. There is no published security policy, trust centre, vulnerability-reporting page, data-processing statement or incident history for a platinumhedgehog service. The LMAX abuse mailbox is not a substitute for those materials.
The division of authority creates plausible failure modes even when every party is competent. Corporate approval can be delayed while a technical maintainer is ready to act. A route can remain valid while an application credential is compromised. An abuse report can reach LMAX while the contractual provider lacks a customer communication plan. A Cloudflare path can be healthy while the origin system is unavailable. Monitoring must follow the actual chain rather than treat a green route as a green service.
Privilege governance deserves particular attention. The public registrations are maintained under an LMAX maintainer, while the company remains the named holder. A buyer should ask who has login rights, how many people can change the route, whether strong authentication is required, whether actions are logged, and how emergency access is controlled. It should ask who can alter the ROA and how an accidental authorization is reversed. The public record cannot answer these questions.
Abuse handling needs its own contract. The address registration publishes a channel, which is better than an unreachable range. Yet customers need to know what evidence triggers filtering or suspension, which assets can be affected, how false attribution is challenged and who communicates a remedy. A rapid block can protect the network while causing harm if it disables an unrelated service on the same account or prefix.
Recovery spans all four surfaces. Corporate contacts must authorize action, resource administrators must preserve route control, transit providers must carry the prefix, and application operators must restore data and service state. A credible plan should identify independent credentials and documentation available when the main domain or network is unreachable. Nothing in the current record proves such a plan exists, so resilience must be tested before dependence grows.
The commercial question begins before price
There is no public platinumhedgehog price to compare. More importantly, there is no public unit of sale. A buyer cannot tell whether it would be purchasing consulting hours, address use, routed connectivity, hosting, managed security or access to software. Without that boundary, even a low quote is impossible to evaluate because the buyer cannot see which labour and risks remain on its own side.
If the offer is address or network service, the quote should specify the prefix, origin, transit arrangement, traffic policy, filtering, route-change authority and exit terms. If it is hosting, it should add compute, storage, backup, facility, monitoring and restoration duties. If it is consultancy, it should state deliverables, accepted evidence, intellectual-property rights and support after handover. Each model has different supervision costs.
The dormant filings make prepayment and continuity questions especially salient. They do not prove inability to perform a future contract. They do show that the historical company record does not evidence a normal stream of trading activity through 2024. A buyer should therefore verify current trading status, insurance where relevant, invoicing details and capacity to meet the proposed obligation. It should avoid a long dependency until delivery has been observed.
Network dependence also has a price. Current public paths share Cloudflare as the immediate upstream. Public registration maintenance and contact duties involve LMAX. A quote from platinumhedgehog should reveal whether those third-party costs and obligations are included, which terms can be passed through, and what happens if either relationship changes. The cheapest arrangement may transfer provider coordination to the customer during an incident.
Exit is likely to dominate the downside. Provider-held IPv4 addresses are scarce and sticky: applications, allowlists, reverse records and counterparties can become dependent on them. If the customer cannot take the addresses away, it needs a renumbering plan. Data and configuration must be exportable independently of the domain, support portal and primary network. The agreement should reserve enough time to migrate before routes or accounts are withdrawn.
A staged purchase would fit the evidence. Start with a non-critical, reversible task. Keep customer-controlled names, keys, monitoring and deployment instructions. Exercise a route or service change, a support escalation and an exit. Pay for the delivered boundary rather than the suggestive value of an ASN. Scale only after the seller demonstrates repeatable operations and names the people and counterparties that make them possible.
A buyer can verify the proposition without demanding a large-company facade
Small operators should not be required to imitate a multinational's website to be credible. A lean company can provide excellent specialist work through direct relationships. The right standard is not marketing volume; it is whether the operator can make its service boundary attributable, testable and recoverable.
For platinumhedgehog, the first verification step is legal. Obtain a current company record and the latest accounts, confirm whether trading began after 2024, match the signer to corporate authority and match the payment destination to the contract. Ask whether Platinum Hedgehog Consultancy Limited itself will perform the work. If another company operates the service, name it and state whether the buyer has a direct remedy against it.
The second step is resource control. Confirm that the proposed service actually uses AS39715 or 195.12.36.0/24 if those records are part of the pitch. Ask who holds the RIPE account and RPKI authority, who maintains the registrations and how access is protected. Require the current route to remain validly authorized and monitored. Do not accept an unrelated ASN as evidence for the product being purchased.
The third step is network operation. Request a test endpoint for the exact service, observe routes from the customer locations that matter and identify the immediate provider relationship. Ask why the public policy names LMAX networks while current observations show Cloudflare. The answer may be entirely reasonable; the purpose of the question is to expose the current design, backup path and responsible contacts.
The fourth step is service acceptance. Define an operation that matters, carry it from request to verified outcome and then reverse it. Measure human touchpoints as well as software behaviour. Record what happens when a request is ambiguous, an approval is missing or a third party must act. A successful happy path is useful, but a controlled failure reveals the operating surface.
The fifth step is continuity. Simulate loss of the public domain, the primary contact and the visible route one at a time. Verify that documentation, credentials, backups and escalation details remain available. For a routed service, test renumbering or withdrawal under controlled conditions. For consultancy, test whether another qualified person can use the handover material.
This process is proportionate because the public evidence is narrow, not because the company name is unusual. The same checks should apply to a familiar brand when legal, network and support roles are split. platinumhedgehog merely makes the separation easier to see.
What the record supports, and what it refuses to support
The public record supports a concise positive case. Platinum Hedgehog Consultancy Limited is an identifiable British private company with a stable registered address and concentrated control. It is the named holder of a UK /24 and AS39715. The prefix is currently visible, the route origin is validly authorized, and the public registrations expose technical and abuse contacts. The legal, domain and resource dates form a coherent identity timeline.
It also supports a decisive limitation. The company filed dormant accounts for every completed year visible through 2024. Its domain is parked. No public offer explains a product, customer, contract, price, service level, support schedule, security control or recovery duty. The network resources therefore cannot be treated as proof of a customer-facing cloud or consultancy service.
The relationship evidence is real but bounded. LMAX maintains registrations and supplies network contacts; current collectors see Cloudflare immediately upstream. These facts explain parts of the operating surface. They do not establish ownership, endorsement or customer remedies. They do not show where equipment or data sits. They do not reveal whether backup paths exist outside public observation.
The uncertainty is not a minor disclosure to place at the end of an otherwise confident profile. It is the main commercial fact. A buyer has enough evidence to know whom to ask and what resources to reference, but not enough to know what would be delivered. That is a better starting position than anonymous infrastructure, yet it remains a starting position.
The rational verdict is therefore conditional. platinumhedgehog can be credited as an attributable British number-resource identity with a small, active and well-authorized IPv4 route. It should not be credited as a proved service operation until the company supplies a current trading explanation, a specific offer, named operating relationships, measurable support and a recoverable exit. An active route shows that the name matters on the internet. Only a contract and repeated accepted outcomes can show that it matters to a customer.