Summary

  • The strongest identity evidence is IANA's allocation of private enterprise number 45417 to HCO Computer Products, doing business as ZGO Tech Hosting, with Sam Jazaerli named as the contact.
  • A 2015 mail-filtering support exchange independently places Jazaerli in a hands-on webmaster role for ZGO and reveals a real operating concern: preserving suspected spam so users, rather than an automatic filter alone, could decide what was legitimate.
  • A third-party IP index associates ZGO with an Irvine address, the hcocomm.com domain and AS16276, but describes the connection as including parent IP owners. That is an upstream or hosted-resource clue, not proof that ZGO owned the autonomous system, originated a prefix or ran a facility.
  • No current public service catalogue, service-level commitment, facility list, support schedule, backup policy, incident record, customer scale or data-location statement is established by the available evidence. A buyer therefore needs direct documentary proof before treating the hosting name as current operating assurance.

The revealing fact is how little the name settles

ZGO Tech Hosting sounds specific. It combines a short brand, a technology label and a service category in four words. A procurement team encountering it on an old invoice, an asset inventory or an IP lookup could easily read the name as a complete description: a US hosting provider called ZGO, presumably operating infrastructure and supporting customers. The public record does not justify that compressed conclusion.

What it does justify is narrower and more interesting. The IANA Private Enterprise Numbers registry contains an entry for HCO Computer Products, doing business as ZGO Tech Hosting, and names Sam Jazaerli as the contact. A 2015 MagicSpam support thread carries a post signed by Jazaerli as ZGO Tech Hosting's webmaster. A third-party IP database associates the ZGO name with an Irvine, California address, hcocomm.com and AS16276, while explicitly describing its ASN links as including parent IP owners. The BTW directory entry keeps the entity visible as a US company record whose service clues and relationship gaps can be compared with those of other infrastructure actors.

Those fragments line up well enough to support a historical identity. They do not line up into a current service specification. The record does not establish what ZGO sells today, whether the trading name is active, where customer workloads run, who owns the hardware, what parts of service delivery are subcontracted, which legal terms apply, how support is staffed, or what happens during a prolonged outage. It does not show a status page, public incident history, service-level document, data-processing statement, backup schedule, recovery objective or exit procedure.

That difference between identity and assurance is the core of the ZGO case. It is tempting to treat a sparse provider as a miniature version of a large cloud company and fill the blank spaces with standard industry assumptions. Yet small operators often have a different shape. One business may resell capacity from an upstream platform. Another may manage customer accounts on rented servers. Another may combine computer sales, web administration and hosting under one trading name. Each can provide useful service. Each leaves the customer with a different control boundary.

The only responsible way to evaluate ZGO is therefore to keep each public signal in its own lane. The IANA record supports a named organisational identity and contact. The forum post supports historical hands-on involvement in email administration. The IP index supports an association with an address, domain and larger network context. The directory supports discovery and comparison. None of them alone, or together, proves current production capacity or outcomes.

That may sound like a limited conclusion. In infrastructure research, it is a valuable one. It prevents an organisation from mistaking a searchable name for a recoverable service.

IANA supplies the best identity anchor

The most authoritative public anchor is not a corporate marketing page. It is an entry in IANA's registry of private enterprise numbers. The registry assigns decimal number 45417 to "HCO Computer Products /dba ZGO Tech Hosting" and lists Sam Jazaerli as the contact. The wording matters. It connects a base business name, HCO Computer Products, to ZGO Tech Hosting as a doing-business-as name. It also gives the record a human point of attribution.

Private enterprise numbers are used in network-management and related technical namespaces so organisations can define vendor-specific identifiers without colliding with other organisations. That is a real technical trace. Someone acting for HCO Computer Products sought or maintained an organisational identifier under a recognised global registry. The entry is stronger identity evidence than a scraped company list because IANA is the registry responsible for the allocation.

It is equally important to understand what the entry is not. A private enterprise number is not an autonomous system number. It is not an IP prefix. It is not a licence to operate a network. It does not locate a server, establish a customer base or certify a managed service. The decimal value cannot be read as capacity, age, quality or commercial scale. It says that an organisation has a private enterprise namespace and identifies the organisation and contact associated with it.

That modest function still matters operationally. Vendor-specific management objects can appear in monitoring systems, device telemetry, management information bases and enterprise integrations. If a customer encounters an identifier rooted in an organisation's private enterprise number, the registry gives the customer a starting point for attribution. It can help distinguish one vendor's namespace from another. It can also help an engineer decide which party ought to document an object or explain a trap, extension or identifier.

But attribution decays if the surrounding records do not stay current. A stable registry entry can persist while the business changes domains, products, owners, staff or service models. A contact can remain listed after responsibility moves elsewhere. The namespace may still be present in old software or appliances long after a product is retired. This is why the IANA entry should be treated as a durable identity anchor, not a live-service monitor.

For ZGO, the dual name raises immediate contract questions. Would a present-day customer contract with HCO Computer Products, ZGO Tech Hosting or another legal entity? Which name appears on bills? Which name owns the domain and customer portal? Which party controls any monitoring identifiers rooted at 45417? Which party receives a security report or legal notice? A doing-business-as relationship can be perfectly ordinary, but a buyer needs it resolved across the entire service chain.

The contract, payment record, technical account, support identity and incident contact should point to the same accountable operator or explain clearly why they do not.

The named contact adds useful continuity because Jazaerli appears again in the 2015 support exchange. That independent trace makes it less likely that ZGO is merely an accidental string in a registry. Still, continuity of a person's name across two records is not evidence of current authority. It supports a historical link. Current authority requires current confirmation.

This is the first principle in assessing ZGO: use the strongest record for exactly what it can prove. IANA can anchor identity. It cannot certify the service wrapped around that identity.

The network clue points upstream, not inward

The most obvious route to overstatement is the AS16276 association. Myip.ms places ZGO Tech Hosting among records on its AS16276 page, alongside an Irvine address, hcocomm.com and several telephone numbers. On the same page, the index's hosting-company table is dominated by OVH businesses, with OVH SAS listed first. The ZGO row itself labels the linked ASN field as including parent IP owners.

That wording is decisive. It means the row is not presenting a clean claim that ZGO owns or originates AS16276. It is associating a named IP-address owner or hosting record with a network that may sit above it in the delivery chain. The relationship could reflect rented server capacity, an assigned address, a historical reverse record, a customer object inside a provider's database or another hosted-resource arrangement. The page does not identify which one.

An autonomous system is a routing identity. To show that an organisation operates one, an analyst would normally look for a current registry record, routing-policy objects, originated prefixes, route visibility, contact data and a consistent organisation name. To show that a hosting brand uses somebody else's autonomous system, the bar is different: a customer address, server observation or provider assignment may be enough to establish use. These are not equivalent findings.

ZGO's available evidence supports only the weaker proposition. The name has been associated by a third-party index with a larger hosting network context. The evidence does not establish a ZGO autonomous system, a ZGO-originated prefix, a peering policy or a ZGO-operated backbone. It does not show whether the address association is current, exclusive or representative of all services. It cannot locate a customer's data inside a specific building or even guarantee that a listed address was used for production rather than administration.

This distinction has practical consequences. If ZGO resold or managed capacity supplied by a larger provider, the customer would depend on at least two control planes. ZGO might control billing, account configuration, customer support, operating-system administration and application recovery. The upstream provider might control the physical host, core network, address allocation, facility access and parts of abuse handling. An outage could cross that boundary. So could a security complaint, a routing problem, a hardware failure or a demand to recover data from a failed machine.

The buyer needs to know which party owns each action. Can ZGO reboot the physical host or only the virtual machine? Can it replace a disk? Can it announce or move an address range? Can it obtain upstream traffic records? Can it escalate an abuse block? Can it restore a snapshot if the upstream account is suspended? Does the customer have any direct rights against the underlying provider, or only rights against ZGO?

None of those questions implies that reselling is inherently weak. Managed service can be valuable precisely because the reseller handles configuration, migration and human support that a hyperscale platform leaves to the customer. The problem begins when the service boundary is invisible. A brand name may cause the buyer to attribute physical and network controls to the front-line provider even when those controls live elsewhere.

The Irvine address deserves the same restraint. Myip.ms lists 16812 Hale Avenue in Irvine in the ZGO row. That is an identity and locality clue in a third-party database. It is not a facility record. A street address can be an office, mailing address, workshop, former business location or administrative contact. Without corroborating facility documentation, it should not be described as a data centre, network point of presence or support floor.

The result is a network picture with one visible edge and a large unlit interior. ZGO appears to have touched real hosting infrastructure in a larger provider context. The public record does not reveal the depth, duration or current state of that relationship. A buyer should therefore ask for a current dependency diagram, not assume one from an IP page.

One support exchange reveals an actual production problem

The 2015 MagicSpam thread is the smallest source in the record and perhaps the most useful. In it, a user posting as sjazaerli asks for messages classified as spam to be delivered to a user's spam folder rather than deleted, so the user can decide whether each message is spam or legitimate mail. The signature identifies Sam Jazaerli as webmaster for ZGO Tech Hosting. MagicSpam's support team replies that its product did not then support quarantine or spam folders and says such a feature was on the planned path for a later product series.

The exchange supports several bounded findings. ZGO had a person publicly acting in a webmaster capacity. That person was dealing with a mail-filtering product. The operational concern was not abstract security marketing; it was the fate of messages after automated classification. The desired outcome was preservation and user review rather than irreversible deletion.

That is a revealing hosting problem because spam filtering is a decision system operating under uncertainty. A filter examines signals and classifies mail, but a false positive can hide a customer order, password reset, legal notice, invoice or personal message. Deletion reduces storage and review work while raising the consequence of a mistaken classification. Quarantine or folder delivery preserves evidence and gives the user a chance to correct the machine's decision, but it transfers work to the user and requires retention, access and explanation.

ZGO's question therefore shows a healthy instinct about reversibility. It sought a design in which an automatic control did not have the final word. That does not establish that the requested configuration was implemented. The vendor's reply indicates that the capability was unavailable in that product at that time. The thread also does not reveal how many mailboxes were involved, what other filtering layers existed, whether users received alerts, how long suspicious mail was retained or how restoration worked. It is evidence of a requirement and an interaction with a supplier, not evidence of a completed service outcome.

Still, it gives the public assessment a genuine technical centre. Hosting is often described through servers, storage and bandwidth. Customers experience it through decisions: whether a message arrives, whether a password reset works, whether a domain resolves, whether a backup can be found, whether a suspended account can be restored. Those decisions depend on records that can be inspected and changed.

The spam-folder request contains the basic elements of accountable automation. There is an input, a classification, an action, a possible error, a human reviewer and a recovery path. A mature service would add provenance and controls around each step. Which filter rule fired? What score or signal caused the classification? Was the action delivery, tagging, quarantine or deletion? Who could release the message? Was the release recorded? Could a customer tune the rule without weakening protection for every mailbox? What happened when storage limits were reached?

These are not only questions for old mail systems. They are the same design questions that now govern automated abuse detection, account suspension, malware scanning, backup retention and fraud controls. An infrastructure provider creates value by making repeated decisions safely. If every decision requires manual work, the service becomes expensive and inconsistent. If decisions are fully automatic and irreversible, mistakes become destructive. The durable middle ground is automation with visible state, bounded authority, auditability and a human escape path.

The forum thread also reveals the role of the upstream vendor. ZGO could ask for a feature, but the product supplier controlled whether that feature existed. If ZGO's customer expected quarantined mail, ZGO's ability to meet that expectation depended on MagicSpam's product at that point. This is another example of a layered service boundary. The hosting brand may own the customer relationship while a software supplier owns a critical control. A contract should make that dependency legible.

Enterprise automation is mostly record discipline

The assigned technical question for ZGO is whether records remain fresh, governed, attributable, queryable and recoverable under repeated use. The public evidence does not show a modern automation platform, and there is no basis for inventing one. It does, however, show exactly why those properties matter.

Consider a single hosted mailbox. The system has an account owner, a domain, DNS records, authentication settings, storage limits, routing rules, filtering policy, aliases, forwarding addresses, logs, billing state and recovery contacts. Each item may be correct on the day the mailbox is created. Reliability depends on keeping the whole set coherent as employees leave, domains renew, passwords change, invoices fail, filtering rules evolve and infrastructure moves.

Freshness means that the record reflects present reality. An old phone number in an IP database may be a historical clue, but it is poor recovery data. A former webmaster in a registry may establish continuity, but a customer needs the current authorised person. A support portal can look live while its escalation mailbox goes unanswered. Good automation must detect or expose stale state rather than repeat it confidently.

Governance means that not every actor can change every record. A support technician may reset a mailbox without being allowed to transfer a domain. A billing operator may restore a suspended account without gaining access to customer content. An upstream provider may replace hardware without changing application credentials. The service is safer when these authorities are separated and documented.

Attribution means that a customer can determine who or what made a consequential change. If mail disappeared, did a user delete it, did a filter reject it, did a retention policy expire it, did a storage limit bounce it or did an administrator alter routing? If a website went offline, did the domain expire, did an address change, did the host suspend the account or did the application fail? Without attribution, support becomes guesswork.

Queryability means that the records can answer operational questions in time to matter. A provider should be able to locate all services tied to a customer, all domains using a name server, all accounts affected by a failed host, all messages caught by a rule or all backups created before an incident. This is where enterprise software earns its place: it reduces the human search burden while preserving context.

Recoverability means that records and services can be restored without relying on the same failed component. Account recovery should survive the loss of the primary mailbox. Backups should survive the loss of the production host. Support evidence should survive a portal outage. A customer export should not depend entirely on an administrator whose access is being disputed. Recovery is a property of the whole chain, not a checkbox attached to storage.

ZGO's public traces show fragments of that chain. The IANA record provides an identity namespace. The IP index provides address and upstream associations. The support post provides a person, a product dependency and a desired review path. What is missing is the connective tissue: current account policy, role assignment, change history, support escalation and recovery evidence.

For a prospective customer, this creates a simple evaluation method. Do not ask only whether ZGO uses automation. Ask what repeated task is automated, what record drives the action, how the record is updated, who can override the result and what evidence remains afterward. A confident answer is more useful than a list of product names.

US identity does not answer the locality question

The BTW directory places ZGO in the United States, and the third-party IP record associates it with an Irvine address. These facts support a US identity context. They do not settle data sovereignty or locality.

There are at least four locations in a hosted service. The contracting entity has a legal location. Support staff work from one or more locations. The service runs in a physical or cloud region. Backups, logs and supplier systems may sit somewhere else. A US business address answers only part of the first question, and even there a buyer still needs to verify the contracting identity.

The AS16276 association complicates the picture because it suggests an upstream infrastructure layer. If ZGO used capacity from a larger provider, the relevant data location would depend on the particular product and region assigned to the customer, not the reseller's mailing address. An account could be administered in California while its server ran elsewhere. A backup could cross another jurisdiction. Abuse or support records could be processed in a supplier's system. The available public evidence does not identify any of those locations.

Locality is also more than the country in an IP geolocation field. Address databases can reflect registration, routing or inferred geography rather than the exact place where data rests. Virtual machines can move. Traffic can pass through several networks. A provider can store primary data and backups in different regions. A customer asking where its data is located needs a contractual and architectural answer, not a coloured pin.

For ZGO, a credible locality statement would identify the legal service provider, the region of primary compute, the location and operator of backups, the systems used for support and billing records, and any cross-border subprocessors. It would explain what changes when the customer selects a region and whether support personnel can access content from elsewhere. It would also say what evidence a customer receives after a migration.

No such public statement appears in the available record. That absence is not evidence that data moved across borders or that ZGO ignored locality. It means locality is unverified. A regulated or security-sensitive buyer should treat it as an open contractual requirement.

This is an important commercial distinction. A small US provider may offer valuable local accountability: a reachable person, a familiar legal environment, hands-on migration and support that understands the customer's systems. Those benefits can justify using an intermediary even when the hardware belongs to a larger platform. But the customer should pay for an explicit local-support service, not infer data locality from the operator's address.

Support labour is part of the product

The forum exchange provides one historical example of human support work: a webmaster identifying a customer-impacting limitation, explaining the desired behaviour and asking the software vendor for a better control. That is the sort of labour that can make a small provider valuable. It translates an end-user problem into a technical request and carries it across a supplier boundary.

Yet one post from 2015 cannot establish a current support organisation. It does not show coverage hours, response targets, escalation depth, staffing, language, ticket volume or incident practice. It does not show whether Jazaerli was an employee, owner, contractor or sole technical contact. The correct inference is that hands-on administration existed at that point, not that any particular support promise exists now.

Buyers often undervalue this distinction because support is hard to compare before something fails. A service may appear inexpensive when the customer assumes that a skilled person will investigate mail flow, restore an account, chase an upstream provider and explain the incident. If the contract includes only infrastructure access, those tasks return to the customer's own staff. If the provider performs them but does not document the boundary, the relationship depends on individual memory and availability.

The supervision cost can be measured. How many minutes does the customer spend deciding whether an alert is real? How many handoffs occur before an upstream issue reaches the right operator? How long does it take to identify the account owner? How many exceptions require a senior administrator? How often must the customer repeat evidence because ticket history is fragmented? These measures reveal whether a service is actually removing work or merely relocating it.

For ZGO, the mail-filtering example suggests a practical support test. Ask the provider to walk through a false-positive case. A legitimate message is classified as spam. What can the user see? What can support see? Can either party restore the message? Is the action logged? Can the rule be tuned for one domain or mailbox? What evidence can be exported? If the filter is supplied by another company, who opens the upstream case and keeps the customer informed?

The same exercise can be applied to a failed server, expired certificate, lost domain credential, compromised administrator account or corrupted backup. A provider that can demonstrate the chain is selling operational support. A provider that can only name the underlying tools is selling access plus hope.

Local support is therefore not proved by a US address or telephone number. It is proved by named responsibility, reachable channels, durable case records, escalation authority and recovery performance. The ZGO record gives a historical hint of that labour. It leaves the present service open.

What a buyer should request before relying on ZGO

The evidence gap is large enough that due diligence should begin with identity and scope, not a generic security questionnaire. The first request should be a current contracting statement. It should identify the legal entity, explain the relationship between HCO Computer Products and ZGO Tech Hosting, name the authorised signatory and match the names used for billing, support and domain ownership. If private enterprise number 45417 is still used, the operator should explain where it appears and who maintains the related definitions.

The second request should be a service inventory. It should say whether ZGO currently provides shared hosting, virtual servers, dedicated systems, domain administration, email, managed applications, equipment sales, consulting or some combination. Each service should have a clear owner. A broad brand should not force the customer to guess which parts are included.

Third comes the dependency map. If another provider supplies network, compute, storage, filtering, control-panel or backup functions, ZGO should identify the dependency at the level needed for risk assessment. The customer does not necessarily need every confidential commercial term. It does need to know which party can fix each failure, where data may travel and what happens if the supplier relationship ends.

Fourth is network evidence. The buyer should ask which addresses, prefixes and autonomous systems are used for the proposed service; which organisation originates them; how abuse reports are handled; whether addresses can change; and what happens to allowlists during migration. The Myip.ms association with AS16276 should be treated as a question to resolve, not an answer to repeat. A current route and allocation explanation can show whether the old index still reflects anything relevant.

Fifth is the account-control model. The provider should demonstrate multi-user access, role separation, strong authentication, recovery contacts, change logs and a process for removing former staff. The customer should retain enough independent control over domains and credentials to exit safely. A service that works only while one personal mailbox remains available has a hidden single point of failure.

Sixth is the mail and security decision model. If automated filtering, abuse detection, malware scanning or suspension is part of the service, the provider should explain the action taken at each severity. Reversible actions should be preferred where practical. The customer should know how to review a decision, request release, tune policy and recover from a mistake. The 2015 spam-folder request makes this especially relevant because it records a past concern about irreversible handling.

Seventh is backup and recovery proof. A policy is useful, but a recent restore record is better. The buyer should ask what is backed up, how often, where copies reside, how long they are retained, who can initiate a restore and what is excluded. A sample recovery exercise can reveal whether account records, DNS, databases, mail and customer-managed encryption keys are actually covered.

Eighth is support evidence. The provider should name normal channels, urgent channels, coverage windows and escalation owners. It should distinguish a response acknowledgement from technical resolution. If an upstream vendor must act, the service terms should explain how ZGO manages that case and communicates with the customer.

Ninth is incident evidence. Even a small operator can maintain a concise history of material service interruptions, root causes and corrective actions. A buyer is not looking for a claim of perfect uptime. It is looking for evidence that failures are detected, explained and used to improve controls. Silence reveals less than a well-documented failure.

Tenth is exitability. The buyer should know how to export data, domains, DNS records, mailboxes, certificates, logs and configuration; how long access continues after termination; what assistance costs; and when retained copies are deleted. Migration is not an edge case. It is the final recovery path when a service or relationship no longer works.

These requests may appear demanding for a lightly documented provider. They can be scaled to the service. A small website does not require the paperwork of a bank. It still requires a known owner, recoverable credentials, tested backups and a way to leave. The objective is proportional evidence, not bureaucratic volume.

The provider also benefits. A compact assurance pack would replace uncertain third-party traces with current facts. It could clarify that an address is an office rather than a facility, that a network belongs to an upstream provider, that a retired product no longer applies, or that a historical contact remains responsible. Transparency can make a small operator more credible without making it look larger than it is.

The commercial test is work removed, not features named

The commercial question is whether reliability, locality, support and migration benefits justify the service boundary compared with alternatives or self-management. The current public record cannot answer that for ZGO because it contains no current pricing, service scope or outcome measures. It can, however, define the calculation.

A customer should start with the work the provider claims to remove. That may include server administration, mail filtering, domain renewals, certificate management, monitoring, backups, supplier escalation and incident communication. Each task has a baseline internal cost. The service is valuable if it performs the task more reliably or cheaply while leaving the customer with enough visibility and control.

Then add the work the service creates. A reseller relationship can add account reconciliation, vendor handoffs and dependency review. Automated filtering can add false-positive review. Outsourced backups can add restore testing and data-location review. A thin support model can add repeated explanation whenever a new person handles a case. These are supervision costs, and they belong in the price comparison.

Risk has to be priced as well. A low monthly fee is less attractive if the customer cannot recover a domain, verify a backup or identify the party responsible for an upstream suspension. Conversely, a small provider may be worth a premium if it supplies a named human who understands the environment, keeps durable records and takes responsibility across supplier boundaries. The decisive product may be accountability rather than compute.

Useful measures are operational. Track successful restore rate, time to recover an account, time to escalate an upstream failure, percentage of changes with an attributable record, number of false-positive mail decisions, minutes spent reviewing each accepted exception and completeness of customer exports. These metrics connect service claims to repeated work.

ZGO's 2015 support post offers a miniature version of the trade-off. Deleting suspected spam reduces retained content and review effort but increases the cost of a false positive. Delivering it to a spam folder increases user review and storage but preserves reversibility. The right choice depends on error rates, message value, retention limits and user capability. A trustworthy provider should be able to explain that trade-off and show how the chosen policy is governed.

The same logic applies to hosting more broadly. Automation can reduce labour, but only if its mistakes are visible and recoverable. Upstream infrastructure can reduce capital cost, but only if dependency and escalation are managed. Local support can reduce customer effort, but only if the support function is reachable and durable. A brand can simplify procurement, but only if the legal and technical identities align.

Until ZGO supplies current evidence on those points, the rational buying posture is conditional. Do not reject the provider merely because its public footprint is small. Do not grant it assurance merely because its name appears in technical registries. Request a scoped demonstration and price the remaining uncertainty.

A bounded verdict

ZGO Tech Hosting is not an empty name. IANA ties it directly to HCO Computer Products through a private enterprise number and a named contact. The MagicSpam thread independently shows that contact acting as ZGO's webmaster and dealing with a concrete mail-handling problem. Myip.ms adds an Irvine identity clue and an association with a larger hosting network. Together, these records support a historically real technology and hosting context.

They do not establish a current hosting platform. The public evidence does not show present ownership, service catalogue, infrastructure boundary, customer base, facility, service level, support schedule, security architecture, data locality, recovery performance or migration process. The AS16276 trace is particularly easy to misuse: the index's own parent-owner wording makes it unsuitable as evidence that ZGO owned the network or originated routes.

The strongest positive signal is not scale. It is the old request to preserve suspected spam for human review. That exchange shows someone at ZGO thinking about an automated control's failure mode and seeking a reversible outcome. It is a small but meaningful example of operational judgement. The limitation is time and scope: a historical support question cannot stand in for a current service commitment.

ZGO should therefore be assessed as an identifiable operator with thin current service evidence. A buyer can use the public record to ask precise questions: who contracts, which services remain active, which supplier controls the infrastructure, where data sits, who handles incidents, how automatic decisions are reviewed and how the customer exits. Those answers must come from current evidence supplied by the operator.

That is the broader lesson behind the hosting name. Infrastructure assurance is not assembled by accumulating labels. It is built from attributable records that remain useful when something goes wrong. ZGO's public trail gives the market a place to begin. It does not yet give the market permission to stop.