Quality Attributes Software and the Building-Data Trap

Summary

Quality Attributes Software's historical record runs from a 2007 integration of iBPortal with Beck Technology's DProfiler to the 2012 introduction of IntelliFace, both framed around turning building and resource data into operational decisions.
A February 2013 company release said four named organizations had contracted to use IntelliFace and intended to install it, but that announcement does not establish completed deployments, measured savings, renewals, continuing use or current customer relationships.
The lasting lesson is about software lifecycle and lock-in: connectors, data definitions, baselines, histories, dashboards and institutional knowledge can become critical building assets even when current vendor ownership, support and service availability cannot be established from the public record.

Quality Attributes Software, Inc directory profile

The useful question begins after the launch

Technology histories are usually told from the beginning. A product appears, its maker describes a neglected problem, partners and customers are named, and the market is invited to imagine a better operating model. That sequence is particularly persuasive in building technology because the underlying problem is real. Commercial buildings and campuses contain equipment from different generations, control systems from different manufacturers and records maintained by different departments. A layer that can collect those signals, give them common meaning and present them to an operator has an obvious appeal.

Quality Attributes Software, or QAS, fits that familiar opening. In the surviving record, its products were presented as connective software for building performance. The earlier iBPortal was described in 2007 as acquiring and reporting live performance data while comparing energy use with design-stage expectations. IntelliFace arrived in 2012 with a broader resource-management pitch. QAS said it could interface with existing systems, collect facility data, analyse it and display energy and sustainability information to several kinds of users.

The more revealing question starts later: what happens when the launch material remains readily visible but current operating evidence does not? A historical release can prove that a company made a statement on a date. It can identify a product name, a proposed capability, a transaction or an announced contract. It cannot, by itself, prove that software is still offered, that a deployment was completed, that support continues or that a customer still relies on it. Those distinctions are not editorial niceties. They determine whether a buyer is evaluating an available service, an inherited technical estate or merely a set of old claims.

QAS therefore matters as a lifecycle case. The public material supports a coherent account of what the company and its partners were trying to build. It does not support treating QAS as a currently verified cloud operator or active software-as-a-service vendor. Nor does that limitation prove that no QAS-related operation exists anywhere. It means the available evidence does not close the gap. For owners of long-lived facilities, that gap is itself useful: it exposes the diligence that should have been designed into the software relationship from the start.

A short record of a long ambition

The earliest substantive point in the record is May 2007. Quality Attributes and Beck Technology announced an integration between Quality Attributes' iBPortal, short for Intelligent Building Portal, and Beck Technology's DProfiler with RSMeans. The proposition joined two different moments in a building's life. DProfiler established estimates and mechanical-equipment baselines during planning and design. iBPortal was described as acquiring, trending, displaying and reporting live data once the building was operating. The aim was to compare actual energy use and cost with the planned baseline.

That was more than a dashboard pitch. It attempted to carry an economic assumption from the design model into daily operation. Air handlers, chillers, boilers, cooling equipment, hot-water systems and renewable-energy equipment were among the kinds of assets discussed in the period coverage. If actual performance moved away from the baseline, managers would have information with which to investigate. The accounts described a possible feedback loop between the building as budgeted and the building as used. They did not independently demonstrate the accuracy, reliability or commercial scale of that loop.

A later leadership reference complicates the chronology without resolving it. A 2014 Silicon Prairie News profile of a different company, Igor Inc., said Dwight Stewart and his co-founders had exited Quality Attributes Software in 2011. The reference is useful as entrepreneurial background. It says something about one group associated with QAS and its subsequent activity. It does not establish what happened to every QAS asset, product, customer obligation or legal interest after that exit.

In November 2012, NetWorth Services announced that it had acquired a controlling interest in QAS, which it described as headquartered in Bayville, New Jersey. The acquirer portrayed QAS as a sustainability and energy-management software company and tied its investment case to IntelliFace. This is solid evidence that NetWorth publicly claimed the transaction at that time. It is not a map of later ownership, and it does not establish who controls any QAS-related intellectual property or obligation today.

Later that month, QAS introduced IntelliFace as a sustainability resource and energy-management system. The company release placed it in the cloud and said it could collect, manage, analyse and store data from measurable resources across a facility. It also described configurable visual displays and an occupant-facing GreenTouchscreen. In February 2013, QAS announced that four organizations had contracted to use the system and were expected to install it.

The dated record is therefore compact but meaningful: a building-performance integration in 2007; a reported founder exit in 2011; a controlling-interest announcement and a new product introduction in 2012; and a set of contract announcements in 2013. The public material reviewed for this account does not provide an equivalent chain of current official product documentation, service terms, uptime records, pricing, support commitments or verified recent customer use. The timeline should end where the evidence ends, rather than being silently extended into the present.

iBPortal tried to join the model to the building

The iBPortal partnership reveals the most durable part of the QAS idea. Buildings are designed with assumptions, then operated amid exceptions. A model may contain expected loads, equipment choices and cost estimates. An occupied building encounters weather, changing schedules, maintenance delays, tenant behaviour, retrofits and equipment that does not perform exactly as specified. The economic value of a design baseline depends on whether someone can compare it with operating reality and decide what to do about the difference.

The 2007 accounts described DProfiler with RSMeans as a planning and conceptual-design tool that could create cost estimates, models, drawings and related documents. Mechanical equipment data would establish an expected energy-cost baseline. iBPortal, in turn, was described as monitoring live building performance and reporting information about energy use and cost. The intended connection was clear: design information should not become a static archive once construction ends. It should remain available as an operating reference.

That connection is technically and institutionally demanding. Data from a chiller or boiler is not valuable merely because it reaches a database. The system has to know which asset produced it, what unit it uses, whether the sensor is trustworthy, how often values arrive and which design assumption provides the comparison. It must distinguish a genuine performance change from a meter replacement, a naming change or a gap in collection. It must preserve enough history to tell an operator whether a deviation is exceptional or routine.

None of those requirements can be assumed from a partnership announcement. The coverage supports the reported feature set and the parties' stated purpose; it does not supply an independent test of implementation quality. But it does show why facility-data products become difficult to replace. Their value is not confined to executable code. It accumulates in mappings between equipment and records, in baseline choices, in naming conventions and in the practical understanding of the people who use the outputs.

This was an early form of a problem that now appears under many labels. Owners want to connect models, controls, meters, maintenance information and business decisions. Vendors promise a common layer. Yet the common layer can become another dependency if its representations are proprietary, its connectors are poorly documented or its operating assumptions live only in the heads of a small team. The better the layer becomes at interpreting a building, the more costly it may be to remove without an explicit exit design.

iBPortal's historical significance is therefore not that it proves a surviving product line. It is that it made the lifecycle argument directly. Planned energy costs and live performance belonged in the same decision system. Once an owner accepts that premise, software continuity becomes part of asset continuity. A failed export, an undocumented calculation or the loss of a connector specialist can impair the owner's understanding of physical equipment that may still have decades of useful life.

IntelliFace broadened the pitch from equipment to resources

IntelliFace widened the frame in 2012. QAS described it not only as an energy tool but as a sustainability resource-management system. The release addressed properties, facilities and campuses, and connected the product to energy efficiency, water conservation, carbon emissions and waste management. It claimed the application could interface with existing systems or platforms in different formats, gather facility data, process it quickly and present an account of energy flow.

The breadth was commercially attractive. A campus does not experience energy, water, waste and emissions as isolated reporting categories. They share buildings, schedules, capital plans and management attention. A common software layer could, in principle, let a facilities team see how resource use changes across sites and then communicate selected information to finance staff, sustainability officers or occupants. The product description also referred to geographic flexibility and dashboards tailored to different audiences.

The GreenTouchscreen is an important detail because it extended the proposed operating surface beyond engineers. QAS described a public display that would use live data to explain a facility's sustainability features and progress, with the aim of influencing occupant behaviour. That turned the data platform into both an analytical system and a communications system. The same underlying measurements could support internal diagnosis, management reporting and a public-facing narrative.

Each additional audience increases the consequences of data design. Engineers may need raw values, alarm context and equipment-level history. Executives may want normalized trends and financial exposure. Occupants need a legible explanation that does not overstate causality. If one platform serves all three, definitions and calculations acquire institutional authority. A number on a screen can become a budget assumption, a public commitment or evidence offered in a sustainability discussion.

Here again, the correct tense matters. QAS said in 2012 that IntelliFace had these abilities. The release is evidence of the company's positioning and intended product architecture. It is not an independent benchmark of scale, accuracy or realised savings. Terms such as "real time," "any format" and effectively unlimited collection were part of the vendor's launch language. A careful account can report the ambition without adopting the superlatives as verified performance.

The launch nevertheless identifies a real integration problem. Facility estates rarely begin with a blank sheet. A new analytics product has to coexist with building-management systems, meters, databases and local practices already in place. The promise to interface with almost anything is therefore central to adoption. It is also where future dependency concentrates. Every special adapter that makes a legacy system intelligible creates value on the way in and potential friction on the way out.

That is the paradox of integration software. Its selling point is neutrality: it sits above heterogeneous systems and gives the owner a common view. Its risk is that the common view becomes intelligible only through the integrator's private mappings. A genuinely portable platform leaves the owner with documented interfaces, exportable history, reproducible calculations and control over credentials. A less portable one may leave a polished dashboard over a set of dependencies that no replacement can easily reconstruct.

The contract announcement is a lead, not an outcome

On 27 February 2013, QAS announced that the University of Connecticut, Temple University, Johns Hopkins University and National Rural Utilities Cooperative Finance Corp. had contracted to use IntelliFace. The release said the organizations would install the system at their facilities. That is meaningful commercial evidence for the date: QAS publicly named four counterparties and described intended installations soon after the product introduction.

It is not the same as evidence that installation was completed. The distinction is visible in the announcement's own future-facing language. A contract may precede technical discovery, site preparation, integration, acceptance testing and operational handover. It may cover a pilot rather than an estate. It may be changed, delayed or ended. Even a successful installation does not by itself establish that the customer achieved measurable energy savings, renewed the arrangement or continues to use the product years later.

No independent statement from the four named organizations is included in the available material for this account. There are no completion notices, measured-result studies, renewal notices or current customer pages that close those questions. It would therefore be inaccurate to call the organizations current QAS customers or to present the announcement as proof of savings. The defensible statement is narrower: QAS said in 2013 that the organizations had contracted to use IntelliFace and were expected to install it.

This evidentiary distinction should be routine in enterprise software reporting, yet it is often lost. Commercial announcements compress several stages into one line. For an owner, those stages carry different risks:

Stage	What it can establish	What it cannot establish on its own
Contract announced	A vendor publicly represented that an agreement existed	Completion, scope, acceptance, value or continued use
Installation started	Technical work began at a site	Full integration, reliable data or user adoption
Operational acceptance	Agreed criteria were reportedly met	Long-term savings, renewal or current support
Measured outcome	A defined result was observed over a stated period	Causation beyond the method or persistence after the period
Renewal or current reference	A relationship continued at a later date	Universal product performance or support for other customers

The table is not a claim about what happened at any named institution. It is a way to keep unlike forms of evidence separate. In the QAS case, the public record supplied here reaches the first stage. Moving it farther would require additional records from the vendor, customers or other credible observers.

The distinction also matters to anyone inheriting an old facility-data environment. A product name in a procurement archive does not tell a new team whether the system reached acceptance, which buildings were included or whether the data now visible came from the original installation. The contract, implementation documents, asset lists, acceptance criteria and change history need to be reconciled. Otherwise the institution risks treating an announced scope as an operating fact.

Ownership changed while the product story accelerated

The November 2012 controlling-interest announcement adds a second lifecycle issue: software can change hands while customers still depend on its representations of their assets. NetWorth Services said it had made a substantial investment in QAS and acquired a controlling interest. It described QAS as based in Bayville and promoted IntelliFace as the next stage of the business.

An acquirer announcement can establish the transaction the acquirer said it completed. It does not answer every continuity question. Control of a company, ownership of particular code, responsibility for customer contracts, possession of historical data and employment of key engineers may align, but they are not automatically identical. Later reorganizations or transfers can separate them further. The available record does not establish the subsequent ownership chain, present legal control or current support responsibility for QAS products.

The 2014 reference to Dwight Stewart and his co-founders exiting QAS in 2011 sits nearby in time but should not be forced into a complete corporate narrative. "Exit" can describe several forms of founder departure or transaction. The later NetWorth announcement described its own controlling-interest acquisition. Without the underlying agreements and later records, the two statements are points on a timeline, not a licence to infer all the steps between them.

For software owners, this is not merely corporate history. People carry architectural knowledge. A founder or senior engineer may know why a connector handles one meter differently, why a baseline excludes a particular period or why an alert threshold was chosen. When ownership and personnel change, a customer needs evidence that this knowledge has been converted into maintained documentation, testable code and support capability.

The same applies to data custody. A facility platform may contain years of readings, asset metadata and user-defined calculations. An ownership change should trigger direct questions about who holds the data, who can access it, where it is hosted, which terms survive the transaction and how the customer can retrieve a usable copy. A reassuring corporate announcement does not substitute for contractual and technical answers.

Facility-data software becomes infrastructure by accumulation

The usual image of software lock-in is a subscription that is expensive to cancel. Facility-data lock-in is more subtle. The software may become indispensable through years of accumulated interpretation, even if the original licence price is no longer the largest cost. Six layers of dependency tend to build on one another.

The first layer is connection. Building systems speak through controllers, gateways, databases, files and vendor-specific interfaces. A facility platform has to authenticate, collect at the right interval and recover from gaps. Some connections may be standard; others may depend on custom code or local network exceptions. The resulting connector estate is a technical asset. If its specifications and credentials cannot be transferred, replacing the application means rediscovering the building from the edge inward.

The second layer is identity. A point called "CHWST" in one control system must be associated with a particular chilled-water supply temperature, a physical location, a unit and an asset. Naming differs across buildings and contractors. Software that creates a consistent asset model saves users from that disorder. But if the model cannot be exported in a documented form, the consistency belongs to the application rather than to the owner.

The third layer is calculation. Energy intensity, avoided cost, expected consumption and carbon estimates all depend on choices. Weather normalization, occupancy schedules, tariff periods, missing-data treatment and baseline dates can change the result. A dashboard can make the number look objective while hiding those choices. Portability requires formulas, versions and assumptions, not just a spreadsheet of displayed values.

The fourth layer is history. Time-series data becomes more useful as it grows. It reveals seasonal patterns, degradation and the effects of maintenance or retrofit decisions. Yet a long archive can be difficult to move. Export limits, timestamp conventions, changed sensor names and proprietary compression may reduce a seemingly complete transfer to an unusable collection. The owner needs to know whether history can be extracted with context intact.

The fifth layer is action. Alerts, reports and recurring reviews become part of how staff run a site. Teams learn which alarms deserve attention, which readings are unreliable and which weekly report drives a capital decision. Those habits can persist even when no formal procedure records them. Removing the application then disrupts not only data access but the institution's rhythm of noticing and responding.

The sixth layer is representation. An occupant display, executive report or sustainability page may depend on the same calculations. Once an organization communicates a number publicly, it needs continuity in definition and provenance. A replacement platform that produces a different value may be more accurate, but it creates a reconciliation problem. Staff must explain whether the building changed, the method changed or both.

This accumulation is why a facility-data platform can become infrastructure without controlling the equipment directly. It mediates understanding. The boilers and chillers may continue to run if the analytics layer disappears, but operators can lose a shared account of performance. Decisions become slower, comparisons become disputed and institutional knowledge retreats into individual memory.

QAS's historical product descriptions touch each part of this pattern: connections to existing systems, live data, baselines, trends, dashboards and communication to occupants. The record does not tell us how completely any installation realised those ideas. It does show the architecture of dependence that buyers should examine whenever a software layer claims to unify a heterogeneous estate.

Lock-in can survive without an active subscription

The phrase "vendor lock-in" often implies deliberate commercial restriction. That is only one form. An organization can be locked into an abandoned or weakly supported system because migration costs are high, interfaces are obscure or no one is confident that a replacement will reproduce trusted reports. The vendor does not need to be exerting pressure. Dependency can persist through inertia and uncertainty.

Buildings intensify the problem because physical assets and software turn over at different speeds. Mechanical equipment may remain in service for decades. Control systems are upgraded in stages. Analytics applications, hosting arrangements and software companies can change much faster. A platform selected midway through a building's life may disappear from easy view while the connected equipment, meters and reporting duties remain.

There is also a difference between technical operation and institutional usefulness. An old application may still open and display values. That does not mean it is secure, supported or correctly interpreting current conditions. Sensors may have been replaced. Tariffs may have changed. New space uses may invalidate the baseline. A green status indicator can conceal a model that has drifted away from the building it once described.

Conversely, the absence of a current marketing site does not prove that every installation stopped functioning. Some enterprise systems continue in customer environments long after public sales activity fades. Support may be private, transferred or handled by local specialists. That possibility is why the QAS record should not be turned into an obituary. The correct conclusion is that current operation and support are not verified by the available evidence.

For an owner, the response is the same whether the uncertainty comes from acquisition, product retirement or simple neglect: treat the software as an inherited asset that requires fresh diligence. Establish what runs, who can legally and technically support it, which data it holds, which decisions depend on it and how the institution would leave it. Waiting for a failure converts an orderly investigation into an emergency migration.

An efficiency promise should arrive with an exit design

Building-energy software is sold on improvement: lower consumption, clearer performance, faster fault detection and stronger reporting. Those benefits are plausible only if the data remains trustworthy and the service remains governable. Procurement should therefore evaluate reversibility at the same time as capability. An exit design is not pessimism. It is part of owning the result.

Commercial continuity comes first. The buyer should identify the contracting entity, the owner of the relevant product rights and the party responsible for support. Change-of-control provisions should explain what happens to licences, hosted data, service obligations and subcontractors. Product retirement terms should specify notice periods and assistance. If critical knowledge depends on a small team, the customer should know what documentation and source access would remain after that team changes.

Architecture comes next. A claim to connect with any system should be translated into a list of actual interfaces, versions and responsibilities. Which protocols are native? Which connectors are custom? Who maintains them after a building-control upgrade? Where are credentials stored? Can the customer operate collectors independently of the hosted application? A generic interoperability statement is not an inventory.

Data ownership must be operational rather than ceremonial. A contract may say the customer owns its data while the service offers only limited reports. The meaningful test is whether the customer can obtain raw readings, timestamps, quality flags, asset relationships, units, annotations, user changes and calculation definitions in documented formats. Exports should be tested before renewal, not first attempted during termination.

Calculation portability is equally important. A platform's most valuable output may be a derived metric rather than a raw measurement. The owner needs the baseline period, exclusions, normalization method, emission factors, tariff assumptions and version history. If those cannot be reproduced outside the product, the organization does not fully control the number it uses to make decisions.

Security and service evidence should be current. Hosting location, access controls, logging, incident response, backup, recovery and software maintenance all change over time. A launch-era description of a cloud application cannot answer present questions about those controls. Nor can an old customer announcement establish current service levels. These matters require dated documents and testable commitments.

Operational acceptance should be defined before installation. The customer needs to know what counts as a connected point, an accurate trend, a reconciled bill or a usable alert. It should preserve test results and discrepancies. Without acceptance evidence, later teams cannot tell whether an odd value is a new fault, an old limitation or a feature that was never delivered.

Outcome measurement requires a counterfactual. A reduction in energy use may reflect weather, occupancy, equipment replacement, tariff changes or operational action. Software can help identify and sustain improvements, but a contract or installation does not prove savings. Buyers should define the method, period and responsible analyst before publicizing a result. The QAS contract announcement is a useful reminder of how far the statement "will install" sits from a defensible statement about value.

Finally, retirement should be rehearsed. The owner should periodically export a representative data set, restore documentation, rotate a credential and reproduce a key report outside the primary user interface. It should know which functions can be interrupted safely and which reports have legal, financial or public significance. These exercises expose dependency while there is still time to correct it.

The practical standard is simple: if a platform becomes the memory of the building, the building owner needs custody of that memory. Access to a screen is not custody. A transferable model, intelligible history, documented calculations and tested recovery are much closer.

How to assess an inherited QAS-era environment

There is no evidence here that any particular site still runs iBPortal or IntelliFace. But if an owner encounters those names in an archive, on a server or in a facilities contract, the historical record suggests a disciplined way to investigate. The goal is not to assume the system is obsolete or current. It is to establish the facts of that environment.

Start with observation. Record application names, versions, hostnames, running services, collector devices, network destinations and user groups without making changes. Identify whether the software only reports data or also sends commands. That boundary is crucial. An analytics outage is different from an interruption to control, even when both appear on the same screen.

Then map dependencies from physical point to reported value. Choose several consequential measurements and trace them through the controller, gateway, collector, database, calculation and display. Note units, timestamps and transformations. This exercise often reveals that a nominally central platform depends on local scripts, shared folders or undocumented manual adjustments.

Preserve the semantic layer. Export asset names, point mappings, locations, equipment relationships, tags, formulas, alarm thresholds and comments. Screenshots are useful for orientation but are not a substitute for structured data. If the system cannot export these elements, document them through supported interfaces before attempting replacement.

Test history as data, not as a chart. Obtain samples across different years and buildings. Check timezone handling, missing intervals, quality markers and changes in point identity. Compare a displayed aggregate with a calculation from exported readings. A successful CSV download can still omit the context required to reproduce an annual total.

Reconstruct the baseline. The 2007 iBPortal proposition depended on comparison with design-stage expectations. An inherited environment may still contain such baselines, but their origin and validity need to be established. Find the model, assumptions, tariff and equipment scope. Determine whether renovations, occupancy changes or meter replacements have made the comparison misleading.

Identify current authority. A name in a 2012 transaction announcement cannot answer who now has the right or capability to license, modify or support the software. Seek current contracts, invoices, licence notices, support correspondence and legal records. Verify contacts independently. Do not send building credentials or data to an address merely because it appears in old material.

Separate preservation from endorsement. Keeping an old system available long enough to understand it does not mean accepting its security or accuracy. Use appropriate isolation, backups and access restrictions while the assessment proceeds. If the application affects control, involve the facility's controls specialist and change-management authority before testing.

Design replacement around outcomes, not screens. A new product does not need to mimic every dashboard. It must preserve the measurements, calculations, alerts and decisions that remain valuable, while eliminating functions that no longer serve a purpose. This is also the moment to give the owner clearer data rights and a tested exit path.

Run old and new interpretations in parallel where feasible. Differences should be investigated rather than averaged away. One platform may apply a different timezone, baseline, emission factor or missing-data rule. Reconciliation creates a documented bridge between histories and protects the credibility of future reporting.

At the end, retain an evidence package: architecture, exports, calculation definitions, acceptance results, decisions about discarded data and the authority under which the old service was retired. That package prevents the next generation of operators from facing the same uncertainty. It also turns a fragile application dependency into institutional knowledge the owner controls.

Silence in the current record has a precise meaning

The temptation with a historical technology company is to resolve ambiguity with a categorical label. "Active" and "defunct" are both stronger than the QAS evidence permits here. The record confirms dated activity. It does not provide current official proof of an operating cloud service, an active service catalogue, pricing, support terms, uptime, present customer deployments or current corporate control.

This is a limitation of the available public evidence, not a universal negative. Private contracts may exist. Software may remain inside customer environments. Rights may have moved through transactions that are not represented in the cited material. None of those possibilities can be promoted to fact either. Responsible analysis leaves the uncertainty visible.

Several kinds of evidence could change the assessment. A current official domain tied to a verified legal entity could show an active offering. Recent product documentation and support terms could establish maintained availability. A customer statement could confirm present use and scope. Corporate filings or transaction records could clarify control. Security documentation, uptime reporting and a dated service catalogue could support a current cloud-operation claim.

Until such evidence appears, historical present tense should be resisted. It is accurate to say QAS introduced IntelliFace in 2012. It is not accurate, on these materials, to say QAS currently provides IntelliFace. It is accurate to say QAS announced four contracts in 2013. It is not accurate to call the named organizations current customers or beneficiaries of verified savings.

The discipline is valuable beyond this one company. Enterprise buyers routinely encounter websites, releases and directory entries that persist after the underlying commercial reality has changed. Dates, authorship and evidence type should travel with every claim. The result may sound less decisive, but it is more useful to someone making a procurement, migration or risk decision.

The wider field continued without proving a QAS lineage

Building-energy analytics did not stop with the QAS-era announcements. The underlying need to collect time-series data, compare conditions and support operating decisions remained visible in later industry material. That continuity of the problem, however, should not be confused with continuity of a particular company or product.

Two contextual documents illustrate the boundary. A 2016 operations report from the Association of Energy Engineers belongs to the broader institutional world of energy-efficiency practice, but the material available for this account does not provide QAS-specific text that links the report to QAS operations. An Iowa economic-development document likewise offers regional context but does not establish a QAS product, transaction or current service. They are background sources, not bridges across the missing years.

A later patent record is more technically specific. Google Patents lists a building energy-management system with energy analytics, a 2016 priority date and Johnson Controls Technology Co as the assignee. Its metadata and technical subject matter show that building time-series analytics remained an area of development after the principal QAS record. The patent page itself warns that legal-status and assignee information may be inaccurate and is not a legal conclusion.

The patent does not establish ownership, succession, influence or any other relationship with QAS. It should not be used to fill the corporate gap. Its value is comparative: the problem QAS described belonged to a durable technical field in which larger building-technology companies and other developers continued to work. That makes provenance more important, not less. Similar functional language can appear in unrelated systems, and shared subject matter is not evidence of shared lineage.

For a buyer, category continuity can create false comfort. If many modern platforms offer building analytics, an old installation may appear easy to replace. But the generic function is only the surface. Migration depends on the specific asset model, data quality, calculations and operating practices accumulated locally. A healthy market for new tools does not automatically make an inherited data estate portable.

QAS leaves a governance lesson, not a current-service claim

The QAS story is strongest when kept within its evidentiary limits. The company and its partners described a thoughtful problem: buildings needed a way to compare planned energy performance with live conditions, gather data across existing systems and present resource information to different audiences. The 2007 iBPortal integration and the 2012 IntelliFace launch show an evolution from lifecycle energy-cost comparison toward a broader facility-resource layer.

The 2012 ownership announcement and 2013 contract release show commercial movement around that idea. They also demonstrate why dated statements must not be stretched. A controlling-interest announcement is not a present ownership chart. A product launch is not a current service catalogue. A list of organizations that would install software is not a record of completed deployments or measured outcomes.

What remains is a useful pattern. Facility software starts as a tool and becomes a repository of interpretation. It learns which point belongs to which asset, which baseline matters, which anomaly deserves attention and which number an institution is prepared to publish. That knowledge can outlast a version, a support team and a corporate identity. If it is not documented and portable, the owner may possess the building while renting access to its memory.

Modern buyers should treat interoperability claims as testable exit claims. They should require structured exports, reproducible metrics, connector inventories, current support evidence and a transition plan. They should distinguish a vendor's account of intended capability from independent proof of operation, and a commercial announcement from a measured result. They should also preserve uncertainty rather than hiding it behind a convenient status label.

Quality Attributes Software cannot be verified from these sources as a current cloud operator or active SaaS provider. The sources also do not prove the absolute absence of any surviving operation, private support arrangement or installed system. The defensible conclusion is narrower and more consequential: the historical record is substantial enough to show the ambition, but not current enough to close the lifecycle.

That open end is the point. Buildings endure, data accumulates and software companies change. The buyer who plans only for implementation is buying half a system. The other half is the ability to understand, transfer and continue the service when the original story no longer supplies the answers.