EAM Software: What Buyers Should Understand Before Evaluating It

The short answer

Enterprise asset management software, usually shortened to EAM, is software for managing physical assets across their whole life: acquisition, operation, maintenance, condition, risk, renewal and disposal. There is no hard boundary between EAM and CMMS. Products sold under both labels overlap heavily, vendors move between the two names, and public buyers ask for lifecycle capability under either heading. Choosing between them by definition does not work.

The distinction that does hold up in practice is not feature count. It is how long the decision chain is. A maintenance system has to get the right work done and record what happened. A lifecycle system has to carry that record forward until someone decides whether the asset should continue to be maintained at all, and that decision usually belongs to people outside maintenance.

The E in EAM is not primarily “more features.” It is a longer decision chain.

P-104 and the point where maintenance stops being the whole question

P-104 is a pump. It runs, it receives preventive maintenance, it occasionally fails, it gets repaired. For years, everything about P-104 that matters can be handled inside maintenance: schedule the work, do the work, record the work, order the parts.

Then the pattern changes. The bearing has been replaced three times in two years. The seal is failing more often than the maintenance plan assumed. The motor was rewound once. Vibration readings have been drifting. Nobody has done anything wrong, and each individual repair was correct.

At some point somebody asks a different kind of question: should we keep repairing this pump?

That is the moment the question leaves maintenance. Answering it needs evidence maintenance produced, but the decision, the money and the timing usually sit elsewhere.

Answering it properly requires knowing what has been spent on P-104 and over what period, what condition it is actually in rather than how old it is, what happens to the process if it stops, whether a rebuild would reset its condition or merely postpone the problem, what a replacement would cost and how long procurement would take, whether that money exists in any budget, and how P-104 compares to every other asset competing for the same money.

Each of those is a separate question with a separate owner. The software question is whether the information survives the trip between them.

The Asset Decision Chain

The following chain is a CMMSBuyersGuide framework. It is a way of describing how far information about a physical asset has to travel in a particular organisation, and it is used throughout this guide as the evaluation structure.

Work → History → Condition → Risk → Intervention → Timing → Capital Need → Portfolio Priority

Each link is a different kind of statement about the same asset.

• Work: what was done, by whom, using what, at what cost.
• History: the accumulated record of that work over time, attached to the asset rather than to the people who did it.
• Condition: an assessed judgement of the current state of the asset, distinct from its age and from its failure count.
• Risk: what the consequence and likelihood of failure are, which depends on the asset's role, not only on its condition.
• Intervention: what kind of action the situation calls for — continue maintaining, rebuild, refurbish, replace, retire, or accept the risk.
• Timing: when that intervention should happen, and what changes if it happens later.
• Capital Need: what the intervention costs, when the money is required, and which budget it belongs to.
• Portfolio Priority: how this asset ranks against every other asset competing for the same constrained funding.

Most organisations operate somewhere along this chain rather than at the end of it. Nothing about being further along the chain is better. It reflects who has to make decisions with the information and how far ahead they have to make them.

The Information Escalation Point

The Information Escalation Point, also our framework, is the link in the chain where information about an asset has to leave the maintenance function and be trusted by someone else.

It is the most useful single thing to identify before evaluating software, because everything before it can be handled inside a maintenance system, and everything after it depends on the record being legible, attributable and defensible to people who were not involved in the work.

• Who, outside maintenance, has to act on information about our assets?
• What decision are they making, and on what cycle?
• What evidence do they currently accept, and where does it come from today?
• If maintenance's record were the only input, would they act on it?

Spokane Transit's solicitation is a documented example of the escalation point being written into the procurement itself: the same asset records are expected to be used by maintenance analysts, technicians and foremen, and also by finance, procurement, planners and management. When a buyer lists those user groups against one system, they are describing where their information has to travel.

Five things that are not the same thing

Most confusion in EAM evaluations comes from treating these as interchangeable. They are not, and a system can hold some of them and not others.

Age is not condition

Age is a fact about the calendar. Condition is a judgement about the asset. A twelve-year-old pump in a clean, lightly loaded duty may be in better condition than a four-year-old pump running continuously in an abrasive service. Replacement planning built only on installation dates will replace the wrong assets in the right order.

Public buyers separate these explicitly. Mobile asks to track remaining useful life, condition, criticality and potential risk as four distinct attributes, and separately to record installed dates, removed dates and original costs. Padre Dam asks for age, condition and install date alongside consequence of failure, probability of failure, risk and estimated remaining useful life. They are listed apart because they are different data.

Condition is not criticality

Condition describes the state of the asset. Criticality describes what depends on it. A badly degraded asset with a standby unit beside it and a healthy asset with no redundancy are not the same problem, and no condition score alone will tell you which to deal with first.

Condition and criticality together are not risk

Risk is the combination: how likely failure is, and what happens when it occurs. Padre Dam's requirement list makes the structure visible by asking for consequence of failure and probability of failure as separate captured attributes, with risk alongside them rather than instead of them.

Maintenance history is not condition

History is evidence about condition. It is not condition itself. Three bearing replacements in two years is a strong signal, but it does not say whether the shaft is worn, whether the alignment was ever corrected, or whether the duty changed. Some systems hold rich history and have nowhere to record an assessed condition; others hold a condition rating with no history behind it explaining how it was reached.

None of them is a decision

A condition score of 3, a criticality of high and a risk rating of 14 are not an instruction. Somebody still has to decide what to do, when, and with whose money. The gap between good asset information and an actual decision is where most lifecycle initiatives stall, and software does not close it by itself.

A system can be excellent at recording condition and still leave every decision exactly where it was.

The Intervention Ladder

“Repair or replace” is a false binary. Our Intervention Ladder sets out the range of actions that an asset decision can actually produce.

1. Continue as planned — maintain to the current strategy, no change.
2. Change the maintenance strategy — different tasks, different intervals, added monitoring.
3. Repair — restore function after a specific failure or defect.
4. Refurbish or rebuild — restore a substantial part of the asset's condition and expected remaining life.
5. Partial replacement — replace a major component while retaining the asset.
6. Full replacement — replace the asset, usually with a different specification.
7. Redesign or eliminate — change the process so the asset is no longer needed in that form.
8. Accept and run to failure — a deliberate decision, with a plan for the failure.
9. Defer — decide not to decide yet, with a review point.

The important point for software evaluation is that several of these are neither maintenance work nor a capital project. A rebuild may be funded from maintenance in one organisation and from capital in another. A strategy change produces no work order at all. A deferral produces nothing at all unless the system can record a decision that has no task attached to it.

This is also where the difference from predictive maintenance becomes clear. Condition monitoring tells you something is changing. The ladder is about what the organisation does with that, and how far up the ladder it is allowed to act.

Repair or replace is several questions wearing one coat

When somebody asks whether to replace P-104, they are actually asking a set of questions that different people answer with different evidence.

• What has this asset cost us, over what period, and is that cost rising?
• Is the current condition recoverable by intervention, or is the asset near the end of what it can be restored to?
• What is the consequence if it fails unexpectedly, and how long would recovery take?
• What would a rebuild achieve, and how long would it last?
• What would replacement cost, including installation, downtime and procurement lead time?
• Does the replacement change anything else — spares, training, controls, energy, compliance?
• Whose budget pays, and in which year?

Mobile's requirement set puts several of these into one place deliberately. Requirement 2.49 asks for a backlog of assets needing repair and/or replacement that displays estimated useful life, lifecycle status, condition code, replacement date and cost. Requirement 2.52 asks to report total cost of maintenance for one or many assets. Requirement 8.3 asks to track vehicle lifecycle costs including purchase price, depreciation, operating expense, maintenance costs, salvage value and replacement cost.

Spend history, condition, remaining life and replacement cost only answer the question together. Held in four different systems, they answer it slowly or not at all.

The Capital Escalation Chain

Our Capital Escalation Chain describes what has to happen for a maintenance observation to become funded work.

Observation → Assessed condition → Identified need → Costed proposal → Prioritised candidate → Budget submission → Funded project → Delivery → Asset record updated

Every step is a translation, and every translation is a place where information is lost, re-entered or reinterpreted. The technician's note about shaft movement becomes a condition code, which becomes a line in a replacement backlog, which becomes a costed candidate, which competes against other candidates, which may or may not be funded, and which — if built — has to come back and update the asset record so the cycle can start again.

Mobile's requirements 2.33 and 2.34 address the far end of this chain: tracking capital improvement, special and in-house projects, and linking all costs, resources, requirements, contracts and work orders to a project identifier. Requirement 8.27 addresses the forecast end, generating vehicle replacement schedules based on lifecycle data.

A technical need is not a funded plan

An engineer's conclusion that an asset should be replaced in the next two years is a technical need. It becomes a plan only when a budget line exists, in a specific year, with an owner.

Systems differ sharply on whether they can hold both states and tell them apart. Some record only the technical need and leave funding invisible. Some record only approved projects and lose everything that was identified but not funded. The second is more damaging, because the unfunded items are the ones that recur and the ones that eventually fail.

• Can the system distinguish an identified need from an approved and funded one?
• Can a need be recorded with no funding and stay visible?
• Can we see what was proposed but not funded, per year?
• Can the same need be re-proposed without losing its earlier history?

Deferred decisions are decisions

The most common outcome of an asset decision is deferral. Not now. Next year. When there is money. After the shutdown.

Deferral is a legitimate decision, and it carries consequences: risk accumulates, cost estimates go stale, and condition continues to degrade while nobody is looking at the record. It is also the outcome most likely to leave no trace in software, because it produces no work order, no project and no transaction.

A system that cannot record a deferral will, a year later, present the same asset as though it had never been considered — with none of the reasoning, none of the accepted risk, and none of the review date attached.

If deferral leaves no record, the organisation relearns the same asset every budget cycle.

Decision Half-Life

Decision Half-Life, our term, is how long an asset decision stays valid before the evidence behind it needs refreshing.

A condition assessment made three years ago and a replacement cost estimated four years ago do not carry the same weight as ones made last month, but in most systems they look identical: a number in a field, with no visible age.

• When was this condition assessment made, by whom, and against what criteria?
• When was this replacement cost estimated, and on what basis?
• Has anything happened to the asset since — failures, rebuilds, duty change — that would invalidate it?
• Does the system show the age of an assessment, or only its value?

Mobile's requirement 2.42, asking that custom inspection observations use weighted scoring by asset type with definable weights to produce a condition score, is relevant here for a second reason: if the weighting can be redefined, then a condition score's meaning depends on when it was produced and under which weighting. That is a governance question as much as a software one.

Decision Provenance

Decision Provenance, also ours, is the ability to reconstruct why a past asset decision was made, from the evidence that existed at the time.

It matters because asset decisions are revisited and challenged. A replacement deferred three years ago is questioned after a failure. A rebuild that did not last is reviewed. A regulator, an auditor or a new manager asks how a condition rating was arrived at.

• What the condition was judged to be, and on what evidence.
• What options were considered and what each was estimated to cost.
• What was decided, by whom, and on what date.
• What assumptions the decision rested on.
• What was expected to happen as a result.

Very few systems hold all of this natively, and many organisations do not need all of it. It is worth knowing which parts you need before a demo, because provenance is almost never volunteered by a vendor and is difficult to add afterwards.

Assumptions, forecasts and the problem of false precision

Lifecycle forecasting produces confident-looking numbers from uncertain inputs. A remaining-useful-life figure depends on an assumed service life, an assumed duty, an assumed maintenance standard and an assumed failure behaviour. A replacement-cost forecast depends on an assumed price base and an assumed year.

None of that makes forecasting useless. It makes the assumptions part of the data. A forecast whose assumptions are invisible cannot be corrected when conditions change, and cannot be defended when it is questioned.

• Where are the assumptions behind a remaining-useful-life figure recorded?
• Can a default service life be overridden for a specific asset, with a reason?
• Can we see how a forecast changed over time, and why?
• Can two scenarios be compared without overwriting the first?

The feedback loop from capital back to maintenance

The chain is usually drawn in one direction, from maintenance up to capital. The return path matters just as much and is more often broken.

When an asset is replaced, the new asset arrives with a different specification, a different maintenance requirement, a different spares list and a different warranty position. If that does not flow back into the maintenance system, the organisation maintains the new asset according to the old asset's plan.

• The preventive maintenance strategy has to be rebuilt for the new asset, not inherited unchanged.
• The spare parts holding for the old asset may now be obsolete stock.
• Warranty conditions may change what maintenance is permitted and by whom.
• History has to be handled deliberately: kept against the position, closed against the retired unit, or both.
• Condition and remaining life start again, and the old values must not silently carry over.

The question of whether history belongs to the physical unit or to the position it occupies is treated in detail in the guide on equipment maintenance software and CMMS, and the rebuilding of the maintenance rule is covered in how to build a preventive maintenance program in a CMMS.

Spokane Transit's requirement for warranty management alongside asset registry and work management, and its statement that history must tie to components and parts through the asset lifecycle, is one buyer writing this return path into the specification.

Portfolio competition: the last link

The final link in the chain is the one furthest from maintenance and the least discussed in software demonstrations. Assets do not compete against a standard; they compete against each other for the same constrained funding.

That requires comparability. A pump, a roof, a switchgear panel and a vehicle have to be expressed in terms that can be ranked against each other: condition on a common scale, consequence of failure in comparable terms, cost in the same year's money.

Spokane Transit's requirement that condition be tracked using user-defined criteria for each asset class and type, on a user-defined rating scale, is precisely this problem being specified: different asset classes need different criteria, but the outputs have to remain comparable. Mobile's requirement 2.47 does the same by asking for condition with useful life estimates by asset type, across signs, bridges, culverts, street lights and roads.

If your organisation never has to rank unlike assets against each other, you do not need this link — and you should not buy for it.

Enterprise does not mean big company

The word enterprise in EAM is routinely read as a statement about organisation size. It is more accurately a statement about how many functions share the same asset record.

A small water district whose asset decisions involve engineering, finance and a board has a cross-functional decision chain. A large manufacturer where every maintenance decision is made and funded inside the plant may have a short one. Size and chain length are not the same variable.

Padre Dam is a useful illustration. The procurement is for a CMMS. The requirements include consequence of failure, probability of failure, risk, estimated remaining useful life, replacement costs, depreciation, and planning and forecasting for rehabilitation and replacement needs. The decision chain is long; the label on the procurement is not.

What public buyers ask enterprise asset management to do

Public solicitations are useful evidence because the buyer writes down what the system must support before any vendor answers. The documents below were read in full. They show organisations asking for condition, criticality, risk, remaining useful life, repair-or-replace evidence and capital-replacement forecasting inside the same procurement as work orders and preventive maintenance.

Spokane Transit Authority's enterprise asset management solicitation lists the business functions the software must support. Alongside an asset registry, work requests, work planning and management, warranty management and inventory, it names Asset Condition and Assessment as a required function, described as the capability to designate and track the condition of assets based on user-defined criteria for each asset class and type using a user-defined rating scale. It also names Planning and Budgeting, described as the capability to calculate and analyse all costs associated with the operation and maintenance of the various assets, asset classes and asset types, and Reporting and Analytics, which the agency labels decision support. The background section states the agency holds over $350 million in capital assets across its fleet and facilities, with an additional $420 million in assets scheduled to be acquired over the next five years, and that asset inventory, maintenance workflow and history with ties to components and parts through the asset lifecycle are necessary to ensure a state of good repair. The planned user list spans maintenance analysts, IT, finance, supervisors and analysts, procurement and warranty, maintenance management, technicians and foremen, facilities staff and planners.

The City of Mobile's enterprise asset management requirement matrix goes furthest on the chain from condition to replacement. Requirement 2.37 asks for the ability to maintain, track and document the remaining useful life, condition, criticality and potential risk for an asset or facility — four separate attributes on one line. Requirement 2.42 asks that the system define custom inspection observations with weighted scoring by asset type, where the weighted scoring results in a condition score on the asset and the weights can be defined. Requirement 2.40 asks for a notification based on the condition documented on an inspection or test. The lifecycle requirements sit beside them. Requirement 2.46 asks for expected lifecycle data at a system, subsystem and component level. Requirement 2.47 asks to track condition with useful life estimates by asset type, giving signs, bridges, culverts, street lights and roads as examples. Requirement 2.48 asks for asset lifecycle information including purchase order or contract, purchase date and cost, in-service date, projected and actual retirement dates and expected life.

Requirement 2.49 is the one that crosses the boundary outright: the ability to add assets to a backlog noting the need for asset repair and/or replacement, where the backlog displays estimated useful life, lifecycle status, condition code, replacement date and cost. A maintenance observation, a condition code and a forecast replacement cost appear in the same record. The fleet section carries the same idea into vehicles: requirement 8.3 asks to track all vehicle lifecycle costs including purchase price, depreciation, operating expense, maintenance costs, salvage value and replacement cost, and requirement 8.27 asks the system to generate vehicle replacement schedules based on lifecycle data. Requirements 2.33 and 2.34 ask to track capital improvement, special and in-house projects and to link all costs, resources, requirements, contracts and work orders to a project identifier.

A repair-or-replace backlog carrying condition, useful life, replacement date and replacement cost is maintenance evidence already formatted as capital evidence.

Padre Dam Municipal Water District's solicitation is worth reading closely because the document is a CMMS procurement, not an EAM one, and it asks for lifecycle capability anyway. Its asset management section defines asset management as managing infrastructure capital assets to minimise the total cost of owning and operating them while delivering the desired levels of service, and describes it as a continuous process guiding acquisition, use and disposal over the entire life of the assets. The system is then asked to support that in three parts: capture asset attributes including age, condition, install date, consequence of failure, probability of failure, risk and estimated remaining useful life; track financial attributes including install costs, replacement costs and depreciation value; and support planning and forecasting for rehabilitation and replacement needs. The integration section separately asks about importing operations data from the plant historian to trigger maintenance and to support condition monitoring and assessment.

Williamson County's enterprise asset management solicitation shows the breadth side of the same word. The county is procuring a single EAM environment covering six functional areas — public portal, service requests, work orders, asset management, inventory management and facilities maintenance — on an initial ten-year term, replacing an environment that currently includes separate systems for fleet asset management and for work order and asset management. The detailed functional requirements sit in a spreadsheet attachment that is not publicly downloadable, so nothing beyond the scope and structure above is attributed to this document here.

One competitively solicited cooperative contract splits the same supplier's scope into two named groups. The CMMS group lists work orders, preventative maintenance, service requests and costing and planning for labour, parts, materials and equipment. The EAM group lists an asset register with analytics, and lifecycle strategies, risk modelling, reporting and decision support. Budgeting solutions for operating, capital and salary planning are listed separately again. That structure is useful as one documented example of how a procurement can distinguish day-to-day maintenance capability from lifecycle, risk and decision-support capability while contracting for both together. It is not a definition of the categories, and nothing here treats it as one.

Deciding where your chain ends

This is the decision the label cannot make for you. Work through the chain and mark the last link your organisation genuinely operates at today, and the last link it will need within your planning horizon.

• If the chain ends at Work and History, a maintenance system is the right scope, and lifecycle capability will sit unused.
• If it ends at Condition and Risk, you need assessed condition and criticality as first-class data, held consistently, with history behind it.
• If it ends at Intervention and Timing, you need the ability to record decisions — including deferrals — that are not work orders.
• If it ends at Capital Need, you need costed, dated, defensible candidates that a budget process will accept.
• If it ends at Portfolio Priority, you need comparability across unlike asset classes, and the governance to keep the scales meaningful.

Two organisations can reach opposite conclusions here and both be right. A longer chain is not a sign of maturity; it is a description of who decides. Buying capability for links you do not operate produces fields nobody fills, which makes the data unreliable for the links you do operate.

If the comparison you are actually making is between two named categories rather than a chain length, the CMMS and EAM comparison and the CMMS and asset management software comparison approach the same ground from the category side, and the CMMS and ERP guide covers what happens when finance owns the asset record.

The EAM Depth Test

Every vendor in this market will say yes to lifecycle management, condition assessment and capital planning. The tests below are designed so that a yes has to be demonstrated, and so that the demonstration reveals depth rather than presence. Run them on your own asset, with your own asset classes, in a single sitting.

Test 1 — The condition test

Ask them to record a condition assessment on an asset. Then ask what that condition is based on, where the criteria are defined, whether the criteria can differ by asset class, who is allowed to change them, and what happens to previously recorded scores when the criteria change.

Watch for condition that is really just a dropdown with no definition behind it, and for criteria that are global rather than per asset class.

Test 2 — The age-versus-condition test

Ask for a list of the assets most in need of replacement. Then ask exactly which fields produced that list. If the answer is installation date and an assumed service life, say so out loud and ask how an asset in poor condition but young, or in good condition but old, appears in the same list.

Test 3 — The escalation test

Take a maintenance finding — a technician records that a pump is deteriorating — and ask them to carry it all the way to a costed replacement candidate without leaving the system and without re-entering the asset. Note every manual step, every export and every place where someone has to retype something.

Test 4 — The intervention range test

Ask them to record each of these outcomes against one asset: change the maintenance strategy, rebuild, replace next year, accept the risk, and defer with a review date. Ask which of the five produce a record that will still be visible in twelve months, and what form each record takes.

Most systems handle replace. The revealing ones are accept the risk and defer.

Test 5 — The deferral test

Defer a replacement, with a reason and an accepted risk. Then ask to see, a simulated year later, every asset that was deferred last year, why, by whom, and what was accepted. If the answer involves a note field, ask how it would be reported on across two thousand assets.

Test 6 — The provenance test

Point at a replacement candidate and ask: who decided this, when, on what condition evidence, against what alternatives, and at what estimated cost at the time. Then change the condition score and ask whether the original basis is still retrievable.

Test 7 — The assumption test

Ask where the remaining useful life on an asset comes from. Ask to override it for one asset with a documented reason, and then ask how someone reading the figure next year would know it had been overridden and why.

Test 8 — The cost-history test

Ask for total maintenance cost on a single asset over five years, broken into labour, parts and contractor spend, and then ask what is included and what is not — overheads, downtime, standby, temporary repairs. Then ask for the same figure across an asset class.

Test 9 — The long-horizon test

Ask to see a forecast of replacement need several years out, then ask what drives each year's total, and what would happen to the forecast if one asset's condition were revised today. A forecast that cannot be traced back to the assets that produced it cannot be defended in a budget meeting.

Test 10 — The comparability test

Put two genuinely different asset classes side by side — a pump and a roof, a vehicle and a switchgear panel — and ask the system to rank them for intervention. Ask what makes the two condition scores comparable, and who is accountable for keeping them so.

Test 11 — The return-path test

Replace the asset in the demo. Then ask what happened to its preventive maintenance strategy, its spare parts, its warranty position, its history and its condition record. Ask specifically whether the old condition score carried over to the new asset.

Test 12 — The unfunded test

Propose three replacements and fund one. Ask to see the two that were not funded, a year later, with their original justification intact and their condition updated. This is the single most common gap between a system that supports capital planning and one that merely records approved projects.

Questions worth asking before you shortlist

About your own organisation

• Where does our decision chain actually end today?
• Who outside maintenance has to act on asset information, and on what cycle?
• What evidence do they accept now, and who assembles it?
• How many asset decisions do we make a year, and how many are deferred?
• What happens today when a replacement is needed but not funded?

About condition and risk

• Do we have assessed condition, or only age and failure counts?
• Are our condition criteria written down, and do they differ by asset class?
• Do we record consequence of failure separately from likelihood?
• Who is allowed to change a condition rating, and is the change visible?

About decisions

• Can a decision that produces no work be recorded at all?
• Can we see what we decided about an asset three years ago, and why?
• Can an unfunded need survive from one budget cycle to the next?
• Can we tell an identified need apart from an approved one?

About the capital chain

• Who translates condition into a costed candidate today, and how long does it take?
• Which budget pays for a rebuild, and which for a replacement?
• Can we produce a multi-year replacement forecast that traces back to individual assets?
• When a project is delivered, what updates the asset record?

About scope

• Which links in the chain will we genuinely operate in the first two years?
• Which fields will nobody fill, and what does that do to the rest of the data?
• Would a maintenance system plus a disciplined annual process meet the need?
• What would have to be true for us to outgrow that?

What changes after this evaluation

Before an evaluation like this, the question asked of a vendor is whether the system does enterprise asset management. Every vendor says yes, and the answer carries no information, because the phrase does not have a fixed meaning across the market.

Afterwards the questions are specific and hard to answer falsely: what condition is based on, whether criteria differ by asset class, how a maintenance finding becomes a costed candidate, which interventions can be recorded, what happens to a deferral, whether an unfunded need survives a budget cycle, where a remaining-useful-life figure came from, how two unlike assets are made comparable, and what happens to the maintenance plan when the asset is replaced.

Those questions are answerable in a demonstration, and the answers differ substantially between products regardless of the label on the box. The related decision about how deep your maintenance model itself has to go is covered in the CMMS and maintenance management software guide, and the planning side in maintenance planning software.

Decide how long your decision chain is, then buy the system that can carry information to the end of it — and no further.