Ideas, observations, and useful links from CTS Companies.

A price used to look like a small fact. It sat on a shelf, in a catalog, or in a quote, and the difficult questions were mostly commercial: Is it competitive? Is it profitable? Who approved the discount?

Now a price can be the final output of a much larger system. It may reflect inventory, location, time, a promotion, a customer segment, browsing behavior, purchase history, or data supplied by another company. The number may still fit on a price tag. The decision that produced it may not.

In January 2025, the Federal Trade Commission published initial staff findings from an ongoing surveillance-pricing market study. The study examined how intermediaries can use personal and behavioral data in tools that influence the prices or promotions consumers see. It was not a final rule, an enforcement policy, or a finding about every retailer. It was an early look at a system that deserves clearer questions.

The broader operational question is simple: if data helps produce a price, can the organization explain the data flow behind it?

A price is no longer only a pricing decision

Consider the ordinary-sounding instruction, “show a better offer to likely buyers.” That may require a customer profile, a segmentation rule, a model or rules engine, a channel where the offer appears, an experiment log, and a decision about whether the customer sees the same offer elsewhere. It may also require information from a retailer, an advertising platform, a loyalty system, or a third-party data provider.

At that point, pricing has become a workflow. And workflows need owners.

The FTC’s initial staff perspective described inputs such as location, demographics, browsing patterns, shopping history, and interactions such as mouse movements. The study did not establish that every retailer uses every input, nor does it convert every variable price into misconduct. It does make one management problem harder to ignore: a business can create a consequential customer-facing decision without anyone being responsible for the whole chain.

The three questions behind the number

First: what data enters the pricing decision? A location used to estimate delivery cost is not the same thing as a browsing history used to infer willingness to pay. An organization should be able to name its inputs and their sources without relying on the phrase “the platform does that.”

Second: what rule turns those inputs into an offer? The rule may be a simple promotion table, a vendor feature, or a more complicated model. The important distinction is not whether it feels technical. It is whether someone can describe the purpose, limits, and exceptions well enough to test the result and answer a reasonable customer question.

Third: who can explain the outcome? Marketing may own the campaign. Sales may own the discount authority. Finance may own margins. IT may manage the systems and integrations. Privacy or legal may review the data use. If nobody owns the explanation across those boundaries, the organization has not merely delegated a task; it has delegated accountability into a hallway.

Transparency is an operations requirement

People sometimes hear “transparency” as a copywriting project: add a sentence to a policy page and continue enjoying lunch. But a disclosure can be accurate only if the underlying process is understood. A customer-facing explanation depends on records of what data was used, what vendor or system processed it, what version of a rule applied, and who approved the program.

That is not an argument for documenting every routine price adjustment like a space launch. It is an argument for matching documentation to consequence. A standard wholesale price list needs ordinary controls. A system that changes an individual customer’s offer based on personal information deserves a clearer inventory, an accountable owner, a review path, and a way to investigate an unexpected result.

Start before the pricing tool arrives

The useful preparation is not a grand policy that tries to forecast every algorithm. It is a short working map. List the pricing and offer systems already in use. Identify what customer or behavioral information enters each one. Record which team owns the business purpose, which team owns the technical connection, and who can approve an exception. Then ask a practical test question: if a customer asks why this offer appeared, can we give a truthful explanation without reverse-engineering our own process?

The FTC’s study remains ongoing, and its initial findings should not be described as a final rule or universal finding about retailers. Its value as an operational prompt is available now. When a price becomes a data flow, the number is only the visible part of the decision. The organization still has to own the rest of it.

A jet engine is a collection of impressive objects: fan blades, turbine blades, sensors, fuel systems, and metal parts expected to perform in conditions most office equipment would regard as personal.

It is tempting to think the constraint is the engine itself.

Today’s aerospace news points somewhere else. Reuters reports that GE Aerospace is buying Consolidated Precision Products, a manufacturer of critical metallic engine components, for $12 billion. The purpose is to help secure capacity for precision castings—parts that sit deep inside an engine and have become a stubborn production bottleneck. Reuters’ account of the transaction describes the deal as part of a longer effort to make aerospace production more reliable.

The interesting question is not merely why GE wants to own more of its supply chain. It is why an organization capable of designing some of the world’s most advanced machinery would spend that much to gain more control over a process that begins with liquid metal.

The answer is that capacity is not a machine count.

A casting must become a part that meets exact requirements for shape, strength, heat resistance, and internal integrity. Doing that consistently requires equipment, materials, process controls, inspection, trained people, and a great deal of accumulated knowledge.

It also requires information to arrive in the right place, in the right form, at the right time.

The machine is only one part of the production system

A factory can have a machine, an order, and a shortage at the same time.

The missing ingredient may be a current drawing. It may be a material certification. It may be a quality record that cannot be located, an engineering change that did not reach the floor, a supplier update trapped in email, or an approval that belongs to someone who is unavailable.

None of those problems looks like a manufacturing bottleneck at first. They look administrative.

But production does not experience them as administrative. Production experiences them as waiting.

This is where IT becomes part of manufacturing capacity. Not as a separate department that keeps printers working, but as the system that allows a complicated organization to know what it is making, which version is correct, what changed, what passed inspection, who owns the next decision, and what must happen before work can continue.

A manufacturer does not need every system to be fashionable. It needs the critical systems to be dependable and connected enough that people are not rebuilding the truth from spreadsheets, inboxes, paper travelers, and memory.

Data quality is a production issue

Manufacturers sometimes talk about data as though it belongs to finance, IT, or the people who enjoy dashboards.

But the data that matters on a production floor is not abstract. It is operational:

Which revision of the drawing is approved?

Which material lot went into this job?

Which inspection results belong to this serial number?

Has the customer approved the deviation?

Which supplier promised which delivery date?

Who can decide whether the job proceeds, stops, or changes?

A wrong answer can create rework. No answer can create a queue.

That is the quiet connection between information systems and physical output. Good data does not make a turbine blade. It makes it possible for the right people to make the right turbine blade, prove what happened to it, and respond when something changes.

The same principle applies well beyond aerospace. An automotive supplier may need traceability for a part run. A defense contractor may need to show that controlled information was handled through an approved process. A medical-device manufacturer may need records that connect a batch, a test result, and a release decision.

In each case, the product is physical. The ability to produce it reliably depends on a chain of information.

The real test is what happens when something changes

Most systems look adequate when the work is routine.

The test comes when an engineer changes a specification, a supplier misses a date, an inspection fails, a customer asks for an exception, or a key person is out for a week. Can the organization identify the affected work? Can it notify the right people? Can someone authorize the next step? Can it later explain why that decision was made?

If the answer depends on finding the one person who “knows how we do this,” the process may be functioning. It is not yet resilient.

That is why the most valuable IT work in a manufacturing business is often unglamorous: organizing documentation, securing access without blocking the floor, improving system integration, protecting the records that prove quality, and making ownership visible when an exception occurs.

The goal is not to turn every plant into a software project. It is to make sure the information surrounding the work is as reliable as the work itself needs to be.

GE’s acquisition will not make precision casting simple. It is evidence that difficult capacity is worth bringing closer to the center of the business.

For manufacturers, the practical lesson is smaller and more immediate: when output is constrained, do not inspect only the machines. Follow the data, the approvals, and the handoffs around them. The bottleneck may be waiting in an inbox.

**Source:** Reuters, “GE Aerospace bets on ‘black art’ of castings to secure jet engine supply”.

An AI policy often begins with a list of names. ChatGPT: yes or no. Copilot: yes or no. Some other tool with an unusually cheerful gradient: perhaps, pending a meeting.

The list feels concrete because it has logos on it. It is also the part most likely to age badly. Products change, features change, contracts change, and the same model can be harmless in one workflow and consequential in another.

The better opening question is not Which AI tool is allowed? It is What is this workflow allowed to receive, produce, decide, and leave behind?

That shift matters because the useful unit of governance is not the model or the vendor. It is the workflow: the specific path through which information enters, is processed, becomes an output, and sometimes turns into a business action.

1. What data may enter this workflow?

“Can we use AI for this?” is usually shorthand for a more precise question: may this particular information enter this particular workflow?

A generic event invitation is not a customer contract. A public product description is not a spreadsheet of employee compensation. A list of meeting topics is not a support ticket history. Good policy gives people a usable way to recognize those differences: public information, ordinary internal work, confidential business material, regulated data, and information governed by a customer or partner commitment.

The important detail is not merely whether a provider says it has strong security. It is whether the proposed use fits the organization’s rules for that kind of information. NIST’s Privacy Framework is useful here because it treats privacy as enterprise risk management and includes the data-processing ecosystem: the other entities, services, and relationships involved when information moves through a business process.

Start by writing down the permitted inputs for each approved workflow. A marketing brainstorming assistant may accept public material and approved internal copy. A workflow intended to summarize a customer record may require an entirely different review. The point is not to produce a classification taxonomy so grand that no one uses it. It is to prevent a familiar shortcut from becoming an unexamined data route.

2. What may the workflow produce or decide without human review?

AI systems can draft, sort, summarize, recommend, route, and increasingly initiate actions. Those verbs deserve different rules.

A draft may be useful precisely because a person will revise it. A recommendation may be useful because a person will weigh it against context the system cannot see. A message to a customer, a change to a record, a purchasing decision, a security response, or an employment-related decision deserves a more deliberate boundary.

One practical policy question is: What is the last point at which a person must review this before it changes the organization’s position? The answer may vary by workflow. A tool may create a first-pass meeting summary without a formal gate. It should not quietly send a customer commitment, alter a system of record, or decide an exception because its prose sounds confident.

NIST’s generative-AI profile and AI Risk Management Framework both emphasize that organizations must adapt risk management to their own context and risk tolerance. That is not an invitation to vague caution. It is a reason to name the decision boundary clearly enough that an employee knows when an assistant is helping and when it is substituting for accountable judgment.

3. What new record, retention, and customer-commitment obligations does it create?

Every new workflow has an afterlife. It may create prompts, uploads, logs, generated files, audit records, drafts, and copies in connected business systems. It may also create a promise—explicit or implied—about how customer information is handled, how long it remains available, or what happens when someone asks for it to be corrected or removed.

People often ask one narrow question: whether a model trains on their data. That can matter, but it is not the whole record question. The broader question is: if this interaction matters six months from now, where is the record, who can retrieve it, what retention rule applies, and what agreement governs it?

This is where a policy becomes operational rather than decorative. Before approving a workflow, identify its record owners and its retention setting. Check whether it changes a customer commitment. Decide whether the output needs to be preserved, reviewed, or routinely deleted. An organization does not need a committee for every prompt; it does need someone able to answer these questions for the workflows that matter.

One brief example

A connected application can be a useful illustration, but it is not the center of the story. If a workflow reads a project folder and produces a summary, the policy questions are still the same: what files may enter, whether anyone checks the summary before it is used, and what new copy or record exists afterward. The connection is simply where those decisions become visible.

Tool lists will keep changing. The three questions will not. They give an organization a way to evaluate the next product without pretending that a logo is a governance model.

The permission screen is one of the least theatrical moments in office technology. A person clicks a useful-looking application, signs in with a work account, and sees a list of requests: read your profile, access files you can access, maintain access to data you have given it. The button says Accept. Somewhere, a meeting begins on time.

It is easy to see this as a pop-up between a person and their work. It is closer to a small contract.

The screen is assigning a relationship among an employee, an outside application, and the organization’s information. It says what the application may do, under whose authority, and sometimes whether that authority reaches beyond one person. The decision may be perfectly reasonable. The awkward part is that the contract is often accepted by the person who needs the calendar plug-in, not by the person who will later have to explain where the data went.

The important distinction is not technical trivia

Microsoft Entra documentation separates two broad kinds of permission. Delegated permissions let an application act on behalf of a signed-in user, within what that user can access. Application permissions, sometimes called app roles, are for an application acting without a signed-in user; depending on the permission, they can reach data across the organization.

That is not a rule that every delegated request is harmless and every application permission is alarming. It is a reminder to ask a better question than, “Do we trust this logo?” Ask: What can this application reach when the employee is not looking, and whose access is it using?

Microsoft notes that delegated access does not let an application exceed the signed-in user’s access, while an app-only permission can allow access to the data associated with that permission without a user present. The difference is about scope and persistence, not just the number of items in a consent dialog.

Consent creates an owner, whether anyone names one or not

A sensible organization does not need to ban every third-party application. Plenty of useful services need calendar access, file access, or single sign-on to do the job they were bought to do. The useful discipline is to make the decision legible.

For a small organization, that usually means recording four ordinary things: the application and publisher, the business purpose, the permissions granted, and the person or role that will revisit the decision. Add the date and the employee or department using it, and the record becomes much more useful when a vendor changes terms, an employee leaves, or an unfamiliar app appears in an access review.

This is why the permission screen behaves like a contract. It creates a continuing obligation. Nobody would sign a supplier agreement and then assume it would never need renewal, review, or an exit plan. Software access deserves the same modest skepticism.

Tenant-wide consent changes the question

Some requests need an administrator because they ask for higher-privilege access. Microsoft describes tenant-wide admin consent as sensitive because it can grant an application’s publisher access to significant portions of organizational data or to highly privileged operations. It also notes that tenant-wide consent can make the application available to all users unless access is otherwise restricted.

That does not mean the administrator’s job is to become a ceremonial no. It means the decision should be proportional to the reach of the request. A reviewer should be able to answer: Who controls this application? Which feature requires each permission? Is the request aligned with the stated purpose? Can access be limited to the people who actually need it? What happens when the business relationship ends?

Microsoft recommends restricting user consent to applications from verified publishers and selected permissions, and it offers an admin-consent workflow for organizations that want users to request review instead of improvising around a blocked prompt. That turns an inconvenient screen into a visible work queue. The goal is not friction for its own sake. It is a way to distinguish a useful tool from an unowned doorway.

A small review routine beats a grand policy

Start with the applications already connected to Microsoft 365. Review the ones that can read mail, files, calendars, contacts, or directory data; the ones with organization-wide consent; and the ones nobody can clearly connect to a current business purpose. For each, decide to keep it, narrow it, reassign its owner, or remove it.

Microsoft provides ways for administrators to review and revoke permissions granted to enterprise applications. That makes the task manageable, but not automatic. A technical list can show that an application has access. It cannot tell you whether the organization still wants the relationship.

The next permission screen will still arrive at an inconvenient moment. That is fine. The useful change is to recognize it as a question about ownership before it becomes a question about cleanup.

Over Christmas 2024, a company called Cyberhaven reported an awkward kind of security failure.

Cyberhaven sold a browser extension designed to help companies control sensitive information moving through web applications. The extension could help identify when a person was pasting, uploading, or otherwise moving company information through a browser.

Then attackers used a phishing campaign to compromise access to Cyberhaven’s Chrome Web Store developer account and published a malicious update to the extension.

The update came through the same channel that normally delivered improvements and security fixes. To many users, it would have looked like nothing at all: the browser quietly updated an approved piece of software.

The episode became part of a wider campaign against Chrome-extension developers. But it also contains a smaller, more useful lesson for an ordinary business.

The browser is no longer just where people look things up.

It is where they do the work.

A browser session can contain an employee’s Microsoft 365 identity, a payroll portal, a banking site, a customer relationship system, a vendor invoice, a Teams meeting, a shared file, an AI prompt, and the approval button for something expensive. The person may be working from the office, a kitchen table, a hotel, or a customer site. From the business’s perspective, the location matters less than the session.

The browser is the branch office.

The strange part of the Cyberhaven story

The obvious reading of the Cyberhaven incident is that browser extensions can be dangerous. That is true, but it is not the most interesting part.

The more interesting fact is that Cyberhaven’s extension existed because the browser had already become important enough to protect. It was a security product for the place where people handle company information all day.

Its compromise demonstrated the same point from the other direction.

The browser was not merely a window onto the company’s systems. It was a place with access to them.

That distinction is easy to miss because most of us still carry an older mental picture of business technology. The office has a network. The network has a firewall. Employees have laptops. Applications live somewhere else—in a server room, a cloud tenant, or a vendor’s data center.

In that picture, the browser is a fairly uninteresting rectangle between the employee and the real infrastructure.

But consider a normal Tuesday morning.

A controller signs in to Microsoft 365, opens an invoice from a supplier portal, downloads a spreadsheet, approves a payment, sends a file to an accountant, and asks an AI tool to clean up a draft memo. A salesperson opens a customer record, joins a video call, uses an extension to schedule a meeting, and signs into a proposal system. An operations manager uses a web dashboard to review production or dispatch information.

None of these activities necessarily requires a company server. None necessarily passes through a physical office.

Nearly all of it passes through a browser.

A branch office has more than an address

The old branch office had obvious things to protect: doors, keys, filing cabinets, network equipment, and the occasional copier that had developed opinions of its own.

The browser has equivalents.

It has an entrance: the sign-in page and the persistent session that follows.

It has filing cabinets: cached data, downloaded files, saved passwords, autofill information, browser history, and synchronized profiles.

It has visitors: websites, advertisements, embedded scripts, web forms, and links from people who would very much like you to believe they are someone else.

It has outside contractors: extensions that can request permission to read or change information on specific sites.

It has a loading dock: uploads, downloads, printing, copy/paste, and data entered into web forms.

And, increasingly, it has a front desk that recognizes people well enough to let them make consequential decisions without asking for their password again.

That is why "which browser is safest?" is usually too small a question.

Chrome, Edge, Firefox, and other mainstream browsers all receive security updates and offer meaningful protections. The decision that changes the outcome is usually less glamorous:

"What is a company-approved browser session allowed to reach, remember, move, or authorize?"

CISA’s browser-security guidance makes this practical. Browsers are exposed to malicious sites, advertisements, downloads, scripts, plug-ins, and extensions; organizations should manage configuration, updates, and add-ons accordingly. That is not an argument for turning every employee into a security analyst, or for making ordinary work unbearable. It is an argument for treating the browser as part of the business environment.

Convenience has quietly become infrastructure

The most consequential browser settings often begin as conveniences.

A saved password avoids another login.

Sync makes a new laptop feel familiar.

An extension removes a tedious step.

A persistent sign-in prevents an interruption during the day.

Each choice makes sense in isolation. Together, they can create a working environment that no one has explicitly designed or agreed to own.

That is the trap.

A business may have strong Microsoft 365 settings, managed laptops, MFA, endpoint protection, and a good firewall. Yet an employee can still be signed into company systems through a browser profile full of unreviewed extensions, personal synchronization, saved credentials, and a dozen open tabs.

The question is not whether the employee was careless. The question is whether the company ever decided what a work browser should be.

Microsoft’s Edge for Business documentation reflects how much this has changed. It treats the work browser as a distinct environment, capable of separating work and personal browsing. Microsoft also documents controls for managing extensions and, for organizations with the applicable licensing and management, limiting risky browser-based sharing actions such as uploads, copy/paste, and printing.

Those are useful capabilities. They are not a reason to buy every possible control.

A control that prevents the accounting team from doing ordinary work will eventually produce a workaround. A security setting with no owner will eventually become an exception. And a policy that exists only in a PDF has very little influence over what happens in a browser tab at 4:47 on a Friday afternoon.

The goal is not an impressive browser-security program.

The goal is an intentional one.

Start with the work that crosses the threshold

A small business does not need a sweeping "enterprise browser" initiative to begin.

Start with three ordinary web workflows:

• Sending a payroll or financial file to an outside provider
• Signing into Microsoft 365 or another critical business application from a personal device
• Uploading or pasting company information into an AI, vendor, or web-based service

For each workflow, ask five questions:

1. Which identity is being used?
2. Does the device need to be managed?
3. What data can leave through the browser?
4. Which extensions or browser features can touch that activity?
5. If something looks unusual later, will anyone be able to see what happened?

The answers will usually reveal the real priorities.

Perhaps company identities should only be used in a managed work profile on personal devices. Perhaps the finance team needs a smaller, reviewed extension list. Perhaps an AI policy is not really an AI policy until it says what may be pasted into an outside web service. Perhaps browser sync is acceptable for bookmarks but not for passwords or extensions.

The correct answer will vary by business. The important thing is that it is an answer—not merely an accumulation of defaults.

The front door moved

The Cyberhaven incident was unsettling because the compromised software was not an obscure game, a suspicious toolbar, or a forgotten piece of free software. It was a tool intended to help secure browser-based work.

That does not mean companies should distrust every extension or avoid web applications. It means the browser deserves the same kind of attention we once reserved for a branch-office network.

Someone should own the standard.

Extensions that can touch company accounts or information should be intentional.

The business should know where work identities may be used, what data can leave through a browser, and what happens when an employee needs an exception.

The old branch office required a lease, a network diagram, and someone carrying a box of cables.

The new one often begins when an employee opens a tab.

Drive through Saline Township, just outside Ann Arbor, and much of the landscape still looks like the Michigan countryside: corn and soybean fields, silos, grain elevators.

And then there are the cranes.

Behind construction fencing, a project known as The Barn is rising on more than 250 acres. Reuters describes the $16 billion development as part of the Stargate AI infrastructure buildout involving Oracle, OpenAI, Related Digital, Blackstone, and Walbridge. It has also turned a township of roughly 2,400 people into one of the country’s more visible arguments over data centers.

Residents have raised questions about farmland, groundwater, noise, traffic, taxes, electricity, and whether a project this large belongs there at all. The township board rejected the requested rezoning in September 2025. The developers and landowners sued two days later. A consent judgment eventually allowed the project to proceed.

All of which sounds like a land-use dispute—until you get to one number.

1,383 megawatts.

That is the electric service covered by DTE’s special contract for the facility. Suddenly, this stops looking like a building with a great many computers in it. It starts looking like infrastructure.

The cloud’s disappearing act

For most of the history of business computing, technology had an obvious physical location. There was a server in the closet, then several servers in a room. Someone worried about the air conditioning. Someone else worried about the generator. There were racks, cables, blinking lights, and a handwritten warning taped to something important.

Then came the cloud. One of its great conceptual achievements was making all that machinery disappear. Microsoft 365 is not somewhere in the way the old Exchange server was somewhere. Salesforce does not appear to have an address. ChatGPT arrives through a browser window.

Except nothing disappeared. We moved the computers, and then we put millions of them together.

That distinction mattered little to most people while the buildings housing those computers were simply another industrial load on a vast electrical system. AI is changing the scale. Lawrence Berkeley National Laboratory now estimates that data centers could account for 11.8% of U.S. electricity use by 2030, with scenarios ranging from 9.5% to 15.3%. Those are modelled scenarios, not destiny, but even the range shows how quickly the assumptions are changing.

PJM, the regional grid operator serving all or parts of 13 states and Washington, D.C., says data-center growth in its footprint could add roughly 30 gigawatts of demand between 2025 and 2030. The U.S. Energy Information Administration reports that national electricity demand grew about 0.1% annually from 2005 through 2019, then about 1.7% annually from 2020 through 2025, with data centers driving part of the newer growth.

The cloud had not become weightless. We had simply stopped looking at what it weighed.

A computer now needs an infrastructure plan

Technology moves quickly. Infrastructure does not. A company can order thousands of AI processors. A utility cannot necessarily produce another substation, transmission line, power plant, or storage project on the same schedule.

Electricity must travel through particular equipment to a particular place. Transformers have lead times. Transmission projects require planning. Generation and storage have to exist when the load arrives. Choosing where to put computing capacity has therefore become different from choosing where to put an ordinary commercial building.

DTE did not simply plug The Barn into the wall. It sought Michigan Public Service Commission approval for special contracts governing electric service. The commission imposed conditions intended to keep existing customers from bearing unrecovered project costs. Those protections include financial commitments, minimum billing, early-termination provisions, and a requirement that the data center’s load be reduced before other customers during an emergency load-shed event.

That is a remarkable journey for the server room. It has moved from the IT department to township boards, utility executives, state regulators, and regional grid planners.

Who owns the risk?

There are reasonable arguments for building facilities like this. They represent enormous private investment. Developers promise construction work, permanent jobs, and substantial tax revenue. AI may create real economic and scientific value.

There are also reasonable questions:

• Who pays for the infrastructure required to serve the project?
• What happens if the projected demand does not materialize—or arrives faster than expected?
• Can existing customers be insulated from the cost and reliability risk?
• How much land and water will the project require?
• How confident should anyone be in a five- or ten-year forecast for an industry changing this quickly?

Those questions are not anti-technology. They are the questions communities ask about every other form of consequential infrastructure.

For years, technology policy mostly dealt with what computers did: privacy, cybersecurity, communications, and automation. Communities are now dealing with what computers physically require:

• buildings and land;
• transformers, generators, and storage;
• fiber, cooling, and water;
• electricity and people.

The digital economy has become large enough that its physical foundations are visible again.

The server room was always somewhere

There is a useful lesson here even for companies that will never build a data center. Businesses increasingly depend on infrastructure they cannot see. Their email, applications, backups, and artificial intelligence all live somewhere else.

We describe those relationships in digital terms: uptime, redundancy, cybersecurity, recovery time, and service levels. Beneath them is a physical supply chain. That does not mean businesses should abandon the cloud or worry about the electric grid every time they open Outlook. It means technology did not become less physical when we moved it to the cloud. It became so convenient that we stopped noticing the physical part.

AI may be bringing that era to an end.

In Saline Township, the server room is no longer hidden behind a locked door at the end of the hallway. It covers hundreds of acres and has its own electric-service agreement.

Now the neighbors know exactly where it is.

People often say documentation is important in the same tone they use for exercise. Everyone agrees. Very few people want to do it at the end of a long day.

The problem is not that organizations lack information. It is that the information they need most is often trapped in someone’s memory.

What memory hides

Memory is excellent at preserving the shape of a problem and poor at preserving the exact detail required to solve it six months later. Someone remembers that a vendor “handles the phones,” but not which portal contains the administrator account. Someone knows a backup exists, but not whether it has ever been restored.

These are not failures of intelligence. They are failures of external memory.

Write the reason, not just the setting

A useful record says more than “port 4 connects to the firewall.” It explains what depends on that connection and what would break if it changed. A useful access record says more than “Jane is an admin.” It explains why that access exists and when it should be reviewed.

The stranger test

Documentation is ready when a competent stranger can use it without a guided tour from the person who wrote it. The stranger does not need every detail. They need the sequence, the owner, the dependency, and the warning.

This is why short documentation often beats a giant manual. A two-page recovery map can be more valuable than a hundred pages of screenshots that no longer match the system.

Documentation as continuity

For a 20–100-person organization, documentation is not bureaucratic overhead. It is how the business preserves decisions when people are unavailable, roles change, or an incident compresses three days of work into thirty minutes.

The best time to write it is before the emergency. The second-best time is immediately after discovering that nobody knows.

Every application arrives with a persuasive little story. It will save time. It will make collaboration easier. It will finally organize the thing everyone has been organizing badly in spreadsheets.

Sometimes that story is true. The trouble begins later, when the app becomes part of the organization’s nervous system without anyone deciding that it should.

The app is never only the app

A new service creates at least five new questions. Who owns the account? Which people can administer it? What data enters it? How does it connect to email, identity, or file storage? What happens when the champion who introduced it leaves?

Those questions are not arguments against buying software. They are the difference between adopting a tool and accumulating a dependency.

The invisible support queue

Every system creates small requests. A password reset. A new employee. A former employee whose access remains open. A report that only one person knows how to produce. A vendor invoice that no longer has an obvious owner.

None of these requests feels large enough to stop a purchase. Together, they form a second job.

The exit test

Before adopting an application, ask how the organization would leave it. Can data be exported in a useful format? Are integrations documented? Does the company own the administrator account? Is there a contract renewal that will surprise someone?

The exit test improves the entry decision because it forces the organization to see the relationship as reversible—or to admit that it is not.

A better purchase conversation

Instead of asking only whether an application solves today’s problem, ask what new system it creates around the problem. Who will maintain it? Who will notice when it fails? What information will become difficult to retrieve if the tool disappears?

For a small or midsize business, the best technology stack is not the one with the fewest applications. It is the one whose dependencies are understood.