Task Retail Technology And The Hidden Operating Cost Of Restaurant Transaction Software

Summary

• Task Retail Technology is best understood as enterprise transaction software for hospitality operators, not simply as a point-of-sale vendor or a network-registration entity.
• Its public product surface spans point of sale, mobile ordering, kiosks, loyalty, digital signage, kitchen management, support and cloud-based transaction management, which means the operational question is whether those surfaces stay consistent across busy stores, franchise estates and changing menus.
• Public sources establish the product categories, Australian privacy-policy posture, support presence, group positioning and AS135634 network context, but they do not establish customer count, uptime, payment architecture, transaction volume, pricing, incident history or net labour savings.

Task Retail Technology Pty Ltd directory profile

The real product is not a terminal, it is transaction coordination

Task Retail Technology looks straightforward if it is reduced to the phrase point of sale. That reduction is misleading. A point-of-sale screen is only the most visible part of the transaction environment. In a restaurant or stadium concession, the hard work is not merely entering an item and taking a payment. The hard work is making sure menu configuration, prices, modifiers, tax treatment, loyalty rules, kitchen routing, customer-facing apps, self-service devices, refunds, reporting and support all remain aligned while the business keeps serving customers.

The company’s official material presents TASK as an end-to-end transaction management platform. It also describes TASK Group Holdings, incorporating Plexure and Task Retail Pty Limited, as developing and deploying cloud-based transaction management and mobile customer-engagement solutions primarily for hospitality. That language matters because it puts the company in the category of operational software rather than a simple hardware-attached checkout product. TASK is selling coordination across transaction surfaces.

The public product surface supports that reading. The company lists enterprise management, enterprise transaction management, point of sale, online ordering, loyalty, mobile order and pay, kiosks, digital signage and kitchen management. Each module has a different user and a different failure mode. A store manager cares whether a menu item appears with the right price and modifier rules. A customer cares whether an order submitted from a phone reaches the kitchen and payment system cleanly. A finance team cares whether transactions reconcile. A support team cares whether a store can recover when something fails during service.

This kind of software changes labour in a specific way. It can reduce manual order taking, reduce duplicate menu entry, shift customers toward self-service, and centralise reporting. But it does not remove operational work. It relocates much of that work into configuration, integration, permission design, monitoring, release management and exception handling. A hospitality operator that adopts a transaction platform still needs people who understand menus, stores, devices, payments, customer accounts, privacy obligations and support escalation.

That is why Task Retail is a useful company for technology coverage even without public evidence of model research or novel artificial intelligence. Its automation sits in the ordinary enterprise-software layer where reliability is measured by repeated low-margin tasks. A failed restaurant transaction is not spectacular; it is simply expensive, irritating and cumulative. The question is whether the platform can make many small transactions less fragile than the manual and fragmented systems it replaces.

Hospitality software fails in places that marketing pages rarely describe

Restaurants and hospitality venues do not buy transaction software because they enjoy software projects. They buy it because the existing work is fragmented. Orders may start with a staff member, a kiosk, a customer app, a web menu, a delivery channel or a table service device. Menus change by location, time of day, promotion, inventory and local rules. Staff turnover is high. Peak demand is uneven. A busy lunch or event window can expose problems that are invisible during a demonstration.

The public TASK pages describe POS, mobile order and pay, kiosk and support surfaces. Those pages are useful evidence of product scope, but they do not prove how the system behaves under load, how quickly a failed site is recovered, or how many integrations are needed in a typical deployment. The missing evidence is important. A transaction platform can look comprehensive while still requiring substantial customer work to standardise menus, map store processes, train staff, connect payment services, configure loyalty programmes, maintain devices and decide who owns failures.

For a hospitality operator, the practical automation target is not “efficiency” in the abstract. It is a collection of recurring tasks: enter an order accurately, send it to the right preparation point, apply the right price and promotion, connect the payment, attach loyalty where relevant, record the transaction, make the customer-facing status clear, and preserve the data needed for refunds, reporting and service support. If these tasks are split across unrelated systems, labour appears as rekeying, reconciliation, customer complaints and manager intervention.

Task Retail’s apparent value proposition is that more of that work can be coordinated through one platform. That could reduce visible front-counter work and lower the chance that a digital order diverges from the store system. But it also raises the consequence of platform errors. When the same environment ties together POS, mobile ordering, kiosks and loyalty, a bad configuration or poorly tested release can propagate across more channels. Centralisation reduces some forms of inconsistency while increasing the importance of change control.

The company’s public technical support page matters in this context. Support is not a decorative service for this category; it is part of the product. A restaurant transaction platform needs support because failures happen during service windows, involve non-technical staff, and often require a fast distinction between device, network, payment, menu, user and platform problems. The page does not disclose support hours, service-level agreements or incident response performance, so those facts cannot be assumed.

But the existence of a service-desk surface confirms that the product’s operating model includes ongoing support rather than one-time software delivery.

The product boundary is broader than POS and narrower than proven operational control

The safest reading of the public evidence is that Task Retail Technology provides a suite of hospitality transaction software, with public modules covering POS, mobile order and pay, kiosks and related operational surfaces. The official site positions the broader group as a cloud-based transaction-management and mobile-engagement provider. The LinkedIn profile similarly describes a cloud platform spanning digital customer-facing services, back-of-house and enterprise operations. These are useful public identity signals, but they remain company-controlled descriptions.

There is a temptation to fill the evidence gaps with assumptions. That would be a mistake. The public pages do not show the internal architecture, database design, release process, payment processor dependencies, hosting provider, observability stack, encryption model, redundancy plan, or per-customer customisation. They also do not show exact uptime, support response time, transaction throughput, gross margin, churn, customer expansion or store count. A technically serious article should treat those gaps as part of the story, not as an inconvenience to write around.

The company’s AS135634 registration adds a different kind of evidence. APNIC RDAP lists the handle AS135634, name TRT-AS-AP, country AU, active status, source APNIC, and a description naming Task Retail Technology Pty Ltd. That supports public network context. It does not prove peering relationships, traffic volume, data-centre footprint, product adoption, customer sites, routing design or incident history. A network registration can be relevant to a software company, but it is not a substitute for evidence about product reliability.

That distinction matters because directory entities can sometimes over-emphasise network evidence when the commercial company is actually a software provider. For Task Retail, the article thesis should foreground enterprise restaurant and hospitality transaction software. The network registration should remain secondary, a sign that the company has public network identity associated with its operations, not a claim that it is primarily a telecom operator or infrastructure carrier.

The same discipline applies to identity. The official privacy policy identifies Task Retail Technology Pty Ltd and commits to protecting personal information under Australian privacy laws. The contact page lists a Sydney contact at Suite 16/90 Mona Vale Road, Mona Vale NSW 2103, with phone and sales email details. These pages support a public Australian operating identity and contact surface. They do not establish complete ownership, all subsidiaries, current staffing, lease status, global revenue, or the legal terms of every customer deployment.

Automation in restaurants is often a management system, not a labour-saving switch

The public product pages imply several forms of automation. POS software can standardise order entry and transaction capture. Mobile order and pay can move order initiation to the customer’s device. Kiosks can shift ordering from staff to a self-service machine. Loyalty can automate offers, identity matching and rewards. Kitchen management can route orders to preparation areas. Digital signage can coordinate menu presentation. Enterprise management can centralise configuration and reporting.

None of these automations is free. Each one requires a control layer. A customer-facing mobile order path needs menu accuracy, payment handling, network availability, account logic, refund rules and customer support. A kiosk estate needs hardware deployment, cleaning, reboot procedures, accessibility choices, menu updates and failure fallbacks. A loyalty system needs customer identity, consent, offer logic and privacy controls. A kitchen system needs routing rules that fit the physical restaurant.

The work therefore moves. Some tasks may leave the cashier or floor staff, but new tasks arrive for operations managers, implementation teams, IT administrators and support desks. They must decide who can change a menu, which changes require approval, how stores are grouped, how promotions are tested, which devices are trusted, how refunds are handled, and what happens when an order is paid for but not received correctly by the kitchen.

This is where product reliability differs from feature availability. A page can say that mobile ordering exists. Production reliability asks whether orders can be completed repeatedly when customers are impatient, staff are busy, networks are imperfect, and menu data changes. A page can say that kiosks support self-service. Production reliability asks whether the kiosk remains useful when a printer fails, a payment is declined, an item is unavailable, a promotion has expired, or a customer needs help. A page can say that support exists. Production reliability asks how quickly the right person can diagnose the actual cause of failure.

Task Retail’s public material does not disclose the metrics needed to answer those questions. That does not make the company unimportant. It means a defensible assessment should stay modest. The available evidence supports a clear product surface and a plausible operating problem. It does not support a quantified claim that the software reduces labour overall, improves throughput by a specific percentage, or consistently performs under all service conditions.

Cloud-based hospitality systems create dependence as well as flexibility

The official group positioning refers to cloud-based transactional management and mobile customer engagement. Cloud delivery can be attractive in hospitality because a central platform can help synchronise menus, updates, reporting and customer-facing channels across many locations. A brand that operates multiple venues may prefer central control over local software islands. Cloud-based delivery can also make remote support, data aggregation and multi-channel ordering easier than a purely local stack.

The dependence cuts both ways. A cloud platform becomes part of the service chain. If central services are slow, misconfigured or unavailable, the problem may affect more than one store or channel. If an update changes behaviour, customers may see the effect at the kiosk, in the app and at the POS. If a privacy process is weak, customer data risk grows with integration depth. If an API or payment dependency changes, the restaurant may discover that its transaction environment has more upstream moving parts than the old store-level system.

The public sources do not identify Task Retail’s cloud provider, hosting architecture, redundancy design or monitoring practices. They do not disclose whether critical transaction paths can operate offline, what data is cached locally, how long stores can continue after a connectivity failure, or which functions degrade first. Those details are central to evaluating a hospitality transaction platform. A system that works only when every connection is healthy imposes a different operating cost from a system designed to degrade gracefully.

This matters for procurement. A buyer should not treat the cloud label as a quality guarantee. The buyer needs to know which parts of ordering, payment, kitchen routing, loyalty and reporting are local, which are central, which are third-party dependencies, and which are manual fallback procedures. A system can be easier to manage centrally and still be harder to troubleshoot locally. The net benefit depends on how responsibilities are divided.

For Task Retail, the unanswered infrastructure questions are not grounds for speculation. They are watchpoints. Public product breadth suggests that the platform sits close to critical business processes. The more channels it coordinates, the more important its change management, observability, access control and support model become. Without public detail, the responsible conclusion is that product scope is evident while operating resilience remains unproven from open sources.

Support is part of the architecture when the user is a venue operator

In developer tools, users may be expected to read logs, inspect traces and troubleshoot integrations. In hospitality operations, many front-line users do not have that luxury. They need a transaction system that either works or fails in a way that can be handled during service. That makes support and escalation part of the architecture even when they are not represented in a product diagram.

Task Retail’s support page indicates that the company maintains a service-desk surface for hospitality brands. The page does not disclose detailed terms, but the existence of support is consistent with the product category. POS, mobile ordering, kiosks and loyalty are not static tools. They touch store operations, customer expectations and revenue capture. When they fail, the customer cannot always wait for a software ticket to move through a slow queue.

A mature transaction platform needs several layers of recoverability. Store staff need immediate fallback steps. Managers need enough visibility to know whether a problem is local or central. Support teams need logs and account context. Product teams need release records. Integration owners need a way to distinguish an upstream payment or identity problem from a platform bug. Executives need reporting that separates temporary customer frustration from structural failure.

Public sources do not show how Task Retail handles those layers. That uncertainty should moderate any claim about automation. A software suite can automate order paths but still create heavy exception-handling work if failures are hard to diagnose. Conversely, a less flashy system with strong support and rollback processes may create more value than a feature-rich platform with weak operational visibility. The economic question is not how many modules exist; it is how much reliable work the customer gets after support, integration and supervision are counted.

The contact page says the company maintains offices on three continents. That suggests geographic reach, but it does not establish 24-hour support coverage or local implementation capacity in every market. A procurement team would still need to verify support hours, escalation rights, service-level targets, release windows, data residency, privacy responsibilities and the division of duties between vendor and customer.

Privacy and customer identity are operational issues, not policy decoration

Task Retail’s privacy policy identifies Task Retail Technology Pty Ltd as the operator and refers to protecting personal information under Australian privacy laws. It lists a Privacy Officer contact at the Mona Vale address, with phone and email details, and shows a last-updated date of 30 June 2025. That evidence supports a current public privacy contact surface and a stated legal posture. It does not prove independent compliance certification, audit results or the detailed implementation of privacy controls.

Privacy matters because hospitality transaction software often touches customer identity. Mobile order and pay, loyalty and customer engagement can create records that go beyond anonymous food sales. A customer may provide a name, phone number, email address, payment reference, order history, loyalty status, device information or location context. A platform that connects ordering and engagement can make the customer experience smoother, but it can also consolidate more personal data into vendor-managed systems.

The operating burden again shifts. Someone must decide how long data is retained, who can access it, how consent is obtained, how deletion requests are handled, how marketing preferences are respected, how breach responsibilities are divided, and how privacy practices differ across countries. The vendor can provide tools and policies. The customer still has duties. A restaurant brand that treats loyalty and mobile ordering as pure revenue channels may underestimate the privacy work attached to them.

The available TASK privacy evidence is useful because it gives a concrete operator name, contact surface and update date. It is not enough to claim that deployments are low risk. A serious customer would still need security documentation, data-processing terms, subprocessors, hosting-region detail, access-control design, incident notice commitments and evidence of operational controls. In a platform that spans POS, mobile ordering and loyalty, privacy is not an isolated legal page. It is tied to architecture.

That makes Task Retail a good example of enterprise software that creates both convenience and governance demand. The customer may gain a unified transaction and engagement environment. It also needs stronger internal ownership of data flows. The net value depends on whether the platform reduces scattered handling of customer information more than it increases dependence on a central vendor-managed environment.

The economics depend on successful transactions, not module count

The public evidence reviewed here does not disclose pricing. Without pricing, no one can calculate the exact cost per order, per store, per kiosk, per loyalty member or per successful transaction. That is a major gap. Enterprise hospitality software can be priced through licences, modules, stores, devices, implementation services, support levels, usage, payment relationships or custom contracts. Different structures create different incentives.

The economic value should be measured against completed work. If mobile order and pay reduces queue pressure, the customer needs to know whether the saved labour and increased throughput exceed subscription, implementation, support and device costs. If kiosks move ordering work from staff to customers, the customer needs to count hardware maintenance, customer assistance, downtime and accessibility support. If enterprise management centralises menus, the customer needs to count the labour saved in stores against the labour added in central configuration and approval.

A platform with many modules can become more valuable if the modules share data and reduce duplicated work. It can also become more expensive if each module adds its own configuration, training and failure surface. The public TASK product breadth is therefore neither automatically good nor automatically bad. It expands the possible value of the platform and expands the due-diligence burden.

For high-volume hospitality customers, the decisive metric is often not the headline licence price. It is the cost per accepted order after failures, refunds, support, staff training, maintenance and management time. A small reduction in order friction can be valuable across many transactions. A small increase in failure rate can also become expensive quickly. Public sources do not provide the transaction-level evidence needed to decide which effect dominates for TASK customers.

The stronger conclusion is structural. Task Retail sells into a market where software economics depend on repeated ordinary tasks. Claims about efficiency should be tested through transaction completion, staff intervention, menu-change effort, support tickets, refund rates, release-related disruption and customer adoption across channels. A buyer that evaluates only product coverage will miss the largest costs.

Competition is not only other POS vendors

Task Retail competes in a crowded field, but the relevant alternatives are broader than a list of POS brands. A hospitality operator can continue with store-level systems and manual reconciliation. It can buy separate tools for POS, loyalty, ordering and kiosks. It can use a general commerce or payment stack. It can build custom integrations around existing systems. It can outsource more digital ordering to third-party marketplaces. It can avoid certain self-service channels altogether.

Each alternative changes control. A single platform can reduce integration burden if it genuinely coordinates the main transaction surfaces. Separate best-of-breed tools can offer flexibility but create more reconciliation work. Marketplace dependence can lower internal software burden while handing customer relationships and fees to another party. Internal development can fit unusual operations but requires technical staff and long-term maintenance. Staying manual may be rational for smaller operators if software complexity exceeds the benefit.

The public TASK material positions the company toward enterprise and multi-channel hospitality environments. That implies the platform is most defensible where the customer has enough operational complexity to value central coordination. A single-location restaurant with simple needs may not value the same breadth. A large brand with many menus, devices, customer channels and reporting requirements might.

The main competitive question is whether TASK offers a better operating system for hospitality transactions than a customer could assemble from alternatives. The answer depends on evidence that is not public in the reviewed sources: integration depth, implementation time, partner ecosystem, hardware flexibility, payment support, uptime, customer service, upgrade process and contract economics. Product pages establish a market position. They do not establish competitive superiority.

This is also why cloud and automation language should be treated carefully. Cloud delivery and self-service tools are now common in the category. The differentiator is less likely to be the existence of a kiosk page or mobile-order page, and more likely to be how consistently the system handles real estate complexity: menus, stores, staff roles, kitchen routing, loyalty rules, payment exceptions and support escalation.

The main failure modes are ordinary and consequential

The most important failure modes for a hospitality transaction platform are not exotic. A menu update may not propagate correctly. A kiosk may show an unavailable item. A mobile order may be paid but not routed clearly. A loyalty offer may apply incorrectly. A kitchen screen may receive orders in a sequence that confuses preparation. A refund may require manual work. A store may not know whether a failure is local connectivity, device hardware, payment service, central software or user error.

These failures have different owners. Store staff handle immediate customer frustration. Managers handle refunds, labour allocation and local workarounds. IT teams handle device and network problems. The vendor handles product defects and central service issues. Finance teams handle reconciliation. Privacy or legal teams handle personal-data problems. Automation that hides this ownership model during sales can disappoint customers after deployment.

Public TASK sources do not document incidents or failure rates. That absence should not be filled with imaginary outages. It should instead guide the questions a customer asks. How does the platform detect a failed order handoff? What retry behaviour exists? What happens if a customer-facing device loses connectivity after payment? Can stores operate in a reduced mode? Can managers see which channel failed? How are changes tested before a multi-site release? How are support cases prioritised during service peaks?

The company’s service-desk surface is relevant, but not sufficient. Support is valuable only if it has enough telemetry, authority and process to resolve failures. A support team that cannot see the right logs or trigger the right rollback will become another relay point. A platform that exposes actionable status to both customer and vendor can reduce the cost of failures. The public pages do not show which model TASK uses.

For this reason, the strongest article judgement is cautious. Task Retail appears to address a real operational problem. Its product breadth is plausible for enterprise hospitality. Its public sources show a coherent transaction-software identity. But the available evidence does not prove reliability at scale, and reliability is the central issue for software that sits between customers, staff, kitchens and payments.

What would change the judgement

Several facts would materially improve confidence in Task Retail’s operating value. Public uptime history would show whether the platform has sustained production reliability. Implementation case studies with deployment scale, channels used, support burden and transaction metrics would clarify whether customers move beyond pilots. Architecture detail would show how the system separates local operation from central services. Security and privacy documentation would clarify data controls. Pricing and contract information would make it possible to estimate cost per successful transaction.

Evidence of release discipline would also matter. Hospitality transaction systems change often: menus, promotions, loyalty rules, payment requirements, integrations and customer interfaces all evolve. A public release-note trail can help show active development, but the reviewed capsule does not provide enough release evidence to assess cadence or regression risk. Customers need to know not only what features exist, but how change is introduced without disrupting service.

Independent customer evidence would be especially valuable. Company-controlled product pages are useful for product scope. Independent customer feedback, support records, verified deployments, public procurement material or carefully described case studies would make the operating picture stronger. Without that, readers should separate product positioning from proven customer outcomes.

The AS135634 record would matter more if paired with technical evidence about how Task Retail uses network infrastructure in production delivery. On its own, it is context. It should not dominate the article. The more material evidence sits in the software surface: POS, mobile ordering, kiosk, support, privacy and enterprise transaction management.

The broader lesson is that hospitality transaction software should be judged by repetition. A demonstration order is easy. Thousands of ordinary orders across different stores, devices, menus and customer behaviours are harder. Task Retail’s public materials show that it wants to be judged in that system layer. The unresolved question is how much of that system layer it can control reliably, and how much work remains with the customer.

Deployment evidence has to be gathered at the store edge

The most revealing evidence for a system like TASK would come from the store edge rather than from a module list. A restaurant brand evaluating the platform would want to know how much configuration work is required before the first site is live, how many menu and pricing exceptions appear during rollout, how often staff need to intervene in customer-initiated orders, and whether support tickets fall after the platform is stabilised. These are not abstract implementation details. They decide whether the software is reducing work or simply moving it from cashiers to operations and IT teams.

The correct trial would follow repeated tasks across several channels. A customer would test a normal counter order, a kiosk order, a mobile order, a loyalty redemption, a menu change, a refund, a device interruption and a peak-period recovery path. It would measure how much of each task is completed by the system, where a person has to step in, how long the intervention takes, and whether the same result is achieved at another site. The point is not to create a dramatic benchmark. It is to measure ordinary completion.

Public TASK sources do not provide that evidence. They show a product category and a plausible control surface. They do not show task-completion rates, support-ticket volumes, menu-change error rates, payment exception frequency, release rollback time or customer adoption by channel. A buyer should therefore treat the public pages as a starting map, not as proof of operating performance. The next layer of diligence would need customer references, implementation documentation, support data and security material under normal procurement controls.

There is also a governance test. If a central office can update menus, promotions, prices and loyalty rules across multiple sites, the customer must know who approves those changes and how mistakes are caught. A poorly governed central platform can create faster errors. A well-governed one can reduce local inconsistency. The technology value depends on that operating discipline. It is not visible in the product labels, but it is visible in deployment artefacts such as approval workflows, audit trails, role definitions, release notes and incident reviews.

For Task Retail, this makes the article’s conclusion narrower than a product endorsement. The company’s public footprint supports coverage because it operates in a consequential enterprise-software layer. The evidence does not justify saying that the software consistently lowers labour cost or improves every hospitality workflow.

The more useful judgement is that Task Retail addresses a real coordination problem, and that the proof of value would come from repeatable store-level evidence: fewer manual corrections, cleaner menu governance, faster exception handling, reliable channel consistency, and support processes that keep the customer from becoming the hidden systems integrator.

The supervision cost is the story

The immediate appeal of a platform such as TASK is simple: fewer fragmented systems, more self-service, more central control and less manual handling. The hidden cost is supervision. Someone has to supervise configuration. Someone has to supervise releases. Someone has to supervise permissions. Someone has to supervise privacy. Someone has to supervise exceptions. Someone has to supervise whether the software is reducing work or merely changing who does it.

That is not an argument against Task Retail. It is the normal test for serious enterprise software. The company’s public product surface addresses real transaction problems in hospitality. POS, mobile ordering, kiosks, loyalty and support are all meaningful parts of the operating environment. The evidence supports a company whose value depends on integration and repeated reliability rather than novelty.

For customers, the right procurement question is therefore practical: which tasks become easier, which tasks move to another team, and which failures become more expensive because more channels depend on one system? If a platform can answer that with evidence, it can justify its complexity. If it cannot, module breadth becomes a burden.

Task Retail Technology’s public footprint is enough to warrant coverage as a technology company in the enterprise software layer. It is not enough to declare the platform a proven labour-saving system across hospitality. The better judgement is narrower and more useful: Task Retail is trying to turn restaurant and hospitality transactions into a centrally managed software environment, and the success of that effort depends less on the existence of POS or kiosk modules than on the reliability, support, privacy controls and supervision costs that surround every ordinary order.

Public source basis

This assessment uses public company, partner, registry and industry records as the bounded evidence base. Task Retail's company and employment footprint is checked against its public LinkedIn profile (https://www.linkedin.com/company/task-retail-technology), the SEEK company profile (https://au.seek.com/companies/task-retail-technology-968636), and APAC CIO Outlook's company coverage (https://www.apacciooutlook.com/task-retail-technology). The transaction-software and partner context is read through Tyro's XchangePoint partner page (https://www.tyro.com/pos-partners/task-retail-technology-xchangepoint/), the Bendigo Bank PC-EFTPOS accredited-companies document (https://www.bendigobank.com.au/siteassets/business/businessdocuments/pc-eftpos_accredited_companies.pdf), LoyaltyCentral's vendor entry (https://www.loyaltycentral.works/vendors-2/task-1), EFTPOS New Zealand's integrated-POS vendor page (https://eftpos.co.nz/integrated-eftpos/pos-vendors), and The Shout's XchangeExec item (https://theshout.com.au/xchangexec-real-live-point-of-sale/).

Corporate-history and adjacent market context are checked against Plexure Group's explanatory memorandum (https://www.takeovers.govt.nz/assets/Transactions/Plexure-Group-Limited-2021-Explanatory-Memorandum.pdf), TSK's public annual report (https://www.mcguinnessinstitute.org/wp-content/uploads/2023/11/TSK-Annual-Report.pdf), and Oracle's certified third-party interfaces document for OPERA 5 (https://docs.oracle.com/cd/E53533_01/docs/Certified%20Third-Party%20Interfaces%20-%20OPERA%205.pdf). The network-resource caveat is limited to APNIC's RDAP record for AS135634 (https://rdap.apnic.net/autnum/135634). None of these sources proves store-level uptime, labour savings, customer retention, margin, support response time, private architecture or current contract performance; those remain the open questions in the article.