Three decisions a day, made without a record

00 — Start here

Where to go from here

What is in here

Sections 00 to 08 are the work. Sections 09 to 12 are how you keep it running. Section 13 onward is reference — look things up in it, do not read it through.

How to read the labels

Claims in this document are tagged so you can tell what is established from what is not. The distinction matters more than usual here, because we have seen your process maps and no other record.

Nothing in this guide is a finding about Southern Components' performance. No quote, job, invoice, inspection or payroll record was accessed. Where a number appears, it is either public data we recomputed or an illustration, and it says which.

01 — Your process, as your own map shows it

What each system owns

The maps use four data sources, and they divide the work cleanly. This matters because it tells you which system to ask for which question — and it corrects two assumptions we were working from before we saw it.

The seven stages, and what each one writes down

Stages marked in red are where a decision is made and nothing records it.

The three decisions

Strip the map down and the same shape appears three times: a person applies judgement, the judgement changes the outcome, and the system stores the outcome without the judgement. Each of the three is cheap to close, and none of them requires a new system.

The identifiers you already have

Most plants have to invent a way to follow a job across systems. Your map shows that you largely do not — which is the single biggest reason the work in this guide is achievable without an integration project.

That last question is the highest-value one in this document. If iTruss retains a dated history of status changes, most of the first ninety days is querying data you already have. If it stores only the current status, the same work requires capture going forward and the timeline moves. Ask it first.

02 — What this review concluded

1. The cheapest opportunity is one you have already identified yourselves. Your process map states that there is no consistent tracking of lost jobs, against a desired state of pipeline, call follow-up and lost-quote reasons. The Lost status already exists in iTruss; what is missing is one required field behind it. Nothing else in this document costs so little or compounds so directly. Your map
2. Price discipline is where the largest money is, and the exposure is real in public data. Between January 2020 and May 2021 the softwood lumber producer price index rose 163%; the truss manufacturing index peaked a month later at 89% and then kept climbing to its own peak of double its 2020 level in March 2022, long after lumber had collapsed and partly recovered. Truss prices are damped going up, slow coming down and late. That asymmetry is an industry fact, not a finding about your plant — but it tells you which of your own questions to ask first. Public
3. Two judgement steps in your own process change the price and leave no trace. The estimator adjusts for what the design did not capture; the sales manager reviews, applies judgement and sets the price. Both are almost certainly adding value — experienced people usually are. Nobody can currently prove it, compare it between estimators, or learn from it, because the number before the adjustment is not kept beside the number after. Your map
4. The data for the first two pilots is business records, not shop-floor telemetry — but two open questions decide how much of it is historical. Quotes, jobs, invoices and statuses are in iTruss and Sage, and the quote-to-job join is a prefix change rather than an integration project. Whether the analysis can look backwards depends on two answers nobody has yet: does iTruss retain status history, and is the calculated price retained after the manual adjustment? Open — ask in the first session
5. The plant-floor data is the hardest to get, not the easiest. Neither Alpine nor MiTek publishes a public API for their US products, and your saw and line timestamps live in eShop and iCommand. Production data comes out through a vendor conversation with a lead time, and should be scoped as a dependency rather than assumed. Meanwhile the audit sheets already carry design-error information on paper, and counting them costs nothing. Public Your map

What it takes from you

03 — The margin question

The margin question

Lumber price moves further and faster than truss price does. Where a plant carries that gap — in the quote, in inventory, or in the customer’s price — decides how much of it reaches the bottom line.

Two things are true about truss pricing that make this the first place to look. Neither is a claim about Southern Components; both come from published data you can check.

First, the input is far more volatile than the output. Across 2020–2022 the softwood lumber producer price index moved 11.1% in a typical month, against 4.1% for the truss manufacturing index — and the spread around those typical months was wider still, a standard deviation of 14.0% against 5.4%. Lumber is roughly two and a half times as jumpy as the product made from it, on either measure.^[1]

Second, pass-through is incomplete and lagged — and the industry says so out loud. Builders FirstSource, the largest component manufacturer in the country, tells its own investors that short-term changes in material cost are “oftentimes, but not always, passed on to our customers” and warns about “delayed ability to pass on material price increases.”^[2]

Method, so you can check it. Series WPU0811 (PPI, softwood lumber) and PCU321214321214 (PPI by industry, truss manufacturing), monthly, not seasonally adjusted, January 2020 through December 2022, retrieved from the BLS series via FRED and re-based by Talon AI to January 2020 = 100. “Typical month” is the mean absolute month-over-month change (11.1% and 4.1%); the standard deviations of the same series are 14.0% and 5.4%. Correlation of month-over-month changes is strongest with no lag (r = 0.78), still present at one month (r = 0.62), and gone by three (r = 0.16) — which is what puts the exposure window at roughly zero to two months.^[1]

What this makes worth asking

The public data establishes that the exposure exists and that the window is short — roughly zero to two months between a lumber move and the output price catching up. It does not establish that quote age is where the exposure bites at your plant; that is the hypothesis to test, and there are two distinct remedies depending on the answer. A validity period caps how long an old price can be accepted. An escalation clause lets the price move with a published index between quote and delivery. The first is a timing control, the second a pass-through control, and the analysis below tells you which one you need. Hypothesis

• How old is a quote when it is accepted? Distribution, not average — the tail is where the damage is.
• Does realised margin decay with quote age? Group accepted jobs by days between quote and acceptance and compare margin against the lumber index move over that same interval.
• Are quoted material costs overwritten by later revisions? If the original quoted cost is not retained, this analysis is impossible — and that finding alone is worth the exercise.
• Do we have a stated validity period, and is it enforced? Many plants have one on paper that estimating does not apply in practice.
• Which customers accept fastest? Fast acceptance is worth real money in a rising market, and it is a legitimate basis for preferential treatment.

04 — The decision map

Nine decisions, and what each one needs

Every row is a decision somebody at Southern Components already makes. The question is only whether it is made on evidence or on memory.

“Readiness” is our judgement of how likely the required records already exist in usable form at a plant of this type — not a statement about your systems. Where your process maps settle the question we have used them and said so; everywhere else it is a starting hypothesis to correct in the first working session.

05 — Where to start

Scores are Talon AI's judgement on a five-point whole-number scale, not measurements. They are shown so you can disagree with a specific number rather than with a conclusion. Value — size of the plausible commercial effect. Readiness — likelihood the data already exists in usable form. Speed — how fast credible evidence appears. Ease — inverse of effort and dependencies.

What you can do yourself, and what needs help

06 — First working session

The eight questions

Ordered by how much the answer changes what you do next. The first four decide whether the recommended pilot is possible at all.

1. Does iTruss keep a dated history of status changes, or only the current status? If it keeps history, your entire pipeline clock — quote to estimate to drawings to production to delivered — already exists and needs only to be read. If it keeps only the current state, the same measurements require capture going forward and every timeline in this document moves. Ask this first
2. When the sales manager sets the final price, is the calculated price still stored? Your map shows a calculation followed by a manual adjustment. If both numbers survive, Pilot A can measure what the adjustments are worth from history. If the adjustment overwrites, it can only measure it going forward.
3. Does the job record keep the original quote number, and is the numeric root unchanged? The map says the number changes from Q to J. Confirm that the digits are stable and that the Q number is not discarded, because that is the join everything else depends on.
4. When a job ships in several billable sections, does Sage produce several invoices — and which Sage product is it? Sage Intacct, Sage 100 and the others have very different extraction paths, and the answer determines whether the accounting side is an export, an ODBC connection or a paid licence.
5. Are we an SBCA member, do we run Digital QC, and can its history be exported? Two of the cheapest opportunities in this document — free inspection data and the industry cost benchmark — depend on the answer, and neither is worth planning around until someone has checked.
6. Is the scheduling spreadsheet still a placeholder? Your own map labels it one. If it has since been replaced, the shopfloor picture in this guide is out of date in the most important place. If it has not, that is the constraint on any delivery-reliability work.
7. Which numbers do teams quietly disagree about? Ask it plainly and let the room answer. Every plant has two definitions of margin and two definitions of on-time, and finding them now is cheaper than finding them in front of a customer.
8. Who owns the first pilot, validates the numbers, and has the authority to change the rule? If the answer is three different people, the pilot will produce a finding and no change.

Leave the room with these six

07 — The data request

08 — Doing the analysis

Everything below is Excel or Google Sheets. No database, no scripting, no analyst. Work on a copy, never on an export you cannot pull again. The two exports are the ones in Section 07: quotes and jobs from iTruss, and invoice lines from Sage.

1. Put each export on its own tab, untouched.

   Name the tabs quotes and invoices, and add two empty tabs called byjob and work. Never type into the first two — every calculation happens on the last two. When someone asks in six weeks where a number came from, you can re-run it.

2. Collapse the invoice lines to one row per job. This is the step that saves you.

   Sage returns one row per invoice line, and your process map shows a job can ship in several billable sections — so a single job number may appear on many lines, and possibly across more than one invoice — Section 07 asks accounting to confirm which, and until they do, assume it does. Look a job number up against that list directly and you will pick up one line and silently drop the rest. The total will be too low and it will look entirely plausible.

   So summarise first, with a PivotTable rather than a formula:

   Select the whole invoices tab → Insert → PivotTable Rows: job_number Values: Sum of line_amount (check it says Sum, not Count) Sum of credit or tax amounts, if held separately

   Paste the result into byjob as values. You now have one row per job number, which is the only shape that is safe to look things up against. Sanity-check it: the number of rows should be smaller than the invoice tab, and the grand total should equal the total of line_amount on the raw tab. If it does not, the pivot is counting rather than summing.

3. Check the quotes tab for repeats before you rely on it.

   On a spare column in quotes, against the quote_number column:

   =COUNTIF( [quote_number column] , [this row's quote_number] )

   Anything greater than 1 is usually a revision. Decide explicitly whether you want the original or the latest, write the decision down in a cell beside the data, and apply it consistently. This is a judgement call, not an error — but an unnoticed one puts the same job in your sample twice.

4. Build one row per accepted job on the work tab.

   Start from the quotes that converted — the ones with a job_number — and pull the money alongside. Request 1 returns the job number next to the quote number on the same row, so there is no prefix arithmetic to do: look up job number against job number.

   =XLOOKUP( [job_number on this row], byjob!$A:$A, byjob!$B:$B, "NOT FOUND" )

   — where byjob!$A is the job number column of your pivot and byjob!$B is the summed amount. If you only have VLOOKUP, give it FALSE as the fourth argument so it demands an exact match.

   Then count your "NOT FOUND" results. A handful is normal — cancelled jobs, jobs not yet invoiced. If more than a few per cent fail to match, stop and find out why before continuing. A systematic mismatch means the two systems are not keyed the way you think, and every number downstream of it is fiction.

5. Add the columns that do the work.
   quote_age_days = date_accepted − date_created realisation = invoiced_total ÷ quoted_amount price_delta_pct = (quoted_amount − calculated_amount) ÷ calculated_amount

   Start with realisation, not margin. It compares what you invoiced against what you quoted, it needs nothing from anybody else, and it answers the shape of the question: does an older quote end up realising less of its own price? Margin proper — invoiced amount less actual job cost — needs a third export and an agreed cost definition, and it is worth waiting for rather than guessing at.

   The price_delta_pct column only works if iTruss retained the calculated price alongside the price that went out. If it did not, leave the column out and note it: that absence is itself one of the findings, and it is what Pilot A captures going forward.

6. Band and compare. Use these bands.
   0–14 days quoted and taken quickly 15–30 days 31–60 days 61+ days the tail, where the damage is if there is any

   Fewer than fifteen jobs in a band means you do not have a band — merge it with its neighbour or widen the window to two years. Report the count next to every average, always. A band of four jobs produces a confident-looking number that means nothing, and that is the most common way an analysis like this misleads the person who ran it.

7. Check the obvious confounders before you believe it.

   Two things move with quote age and will fake a result if you ignore them. Job size — big complex jobs take longer to close and price differently. Customer — one slow-deciding customer with thin margins can produce the entire apparent effect on their own.

   The check is simple: re-run the banding within one customer, and within one size range, and see whether the pattern survives. If it holds inside both, you have something. If it disappears, you have found out that your slow quotes are simply your big or your awkward ones — which is also worth knowing and costs nothing more to learn.

8. Reconcile to the books before you show anyone.

   Total the invoiced amounts on work and ask accounting whether that figure matches what Sage says for the same customers and period. It will not match exactly — credits, freight and tax will differ. It should match closely enough that the difference has a name. If nobody can name the difference, the sample is not what you think it is.

9. Write down what would have to be true for you to be wrong.

   Before the number goes in front of anyone, put one line under it: the sample, the date range, the number of jobs per band, what you used as the denominator, and the biggest thing you could not control for. That line is what makes the result usable in a decision rather than arguable in a meeting.

09 — How a record becomes a decision

One job, end to end

For any job, the team should be able to answer four questions: what did we expect, what happened, why did it differ, and what should change next time.

The chain below is what that requires. The right-hand column is where it usually breaks — check each link before assuming the records will join.

Resolve identifiers before combining any totals

One project may contain multiple quotes, buildings, releases, trusses, deliveries and invoices. State what one row means in every export. Build a checked crosswalk between systems and preserve original IDs. An incorrect join multiplies cost or revenue, and a quietly double-counted margin number will survive three meetings before anyone catches it. Similar customer names are not evidence of a match.

Confirm the system map before requesting anything

Alpine supplies connector plates, equipment, engineering services and software; its IntelliVIEW suite covers design and business management and eShop covers plant and production tracking.^[6] Those are vendor capabilities. They do not tell you which modules Southern Components owns, which are switched on, or what can be exported. Ask the administrator or the vendor about supported reports, exports and authorised read-only access. Do not assume an integration exists — Section 13 sets out what is actually documented.

Retain source files, export dates, record dates, filters, field definitions and corrections. An export date tells you when data was obtained, not when its contents were last true.

10 — Decision infrastructure

The architecture underneath a repeatable answer

Infrastructure here means the smallest set of agreements that makes an answer reproducible and someone accountable for acting on it. It is mostly definitions, not software.

The minimum shared identifiers

You do not need a data model. You need six identifiers that mean the same thing in every system, and a written statement of what one row is in each export.

One more rule that costs nothing and saves weeks: every timestamp in America/Chicago, stated explicitly, including the daylight-saving transitions. Overnight shifts and machine clocks drifting from office clocks are the two most common sources of joins that look right and are not.

Ownership and definitions

For each source, record one named owner, what a row means, the units, the update pattern, known quality issues and the retention period. The owner is a person, not a department — the person who can answer “why does this number look odd” without a meeting.

Definitions are agreed before calculation, not after. The specific ones that will otherwise be disputed the moment a number is uncomfortable: what counts in material cost; whether freight is in or out of margin; whether rework hours are direct labour; how overhead is allocated; what “on-time” means when a load is partial; and whether a credit reduces revenue or increases cost. Write them down. One page.

Quality checks that run every time

• Row-count and control-total reconciliation against a trusted source report, for every export, every time. If the totals do not tie, stop.
• Join-rate check. What fraction of quotes matched an accepted job, jobs matched an invoice, trusses matched an inspection? Report unmatched records rather than dropping them silently.
• One-to-many detection. Explicitly count children per parent before any sum. This is where revenue gets multiplied.
• Range and plausibility rules. Negative quantities, zero costs, dates before the job opened, completion before start.
• Missingness reported, never imputed silently. A blank cost is not zero.

Corrections get a dated note and a reason, and the original is kept. If a number in a management pack changes between meetings and nobody can say why, the pack stops being believed — permanently.

Traceability

Any figure that reaches a manager should be traceable in one step back to the file, filter and formula that produced it. In practice that means each analysis keeps: source file names with export dates, the exact filters applied, the calculation steps, and the record IDs behind any highlighted case. This is the difference between an answer and an assertion — and it is what lets you correct a mistake instead of abandoning the method.

Access and the personnel constraint

Read-only wherever possible. Analysis copies, never the live system. And one hard rule:

How often each decision needs fresh data

Reviewing recommendations, and recording what happened

Every recommendation gets a one-page record: the decision, the evidence, the expected effect, the guardrails, who approved it, the date it took effect, and — crucially — what actually happened, written down after the fact. Most organisations record the decision and never the outcome, which is why the same argument recurs every two years. Keep the ones that failed. They are more instructive than the ones that worked.

The starting architecture

The specification every use case gets

Before any analysis starts, fill this in. If a row cannot be filled, that is the finding.

11 — The pathway

Phased, with a gate at each step

Each phase has to earn the next. The gates are there so that a stalled pilot stops instead of quietly expanding.

Prerequisites versus enhancements

12 — Management scorecard

Eight numbers now, four more later

Small enough that it gets read. Every line has a definition, a source and an owner — a measure without all three does not belong on the page.

This is a blank template. No values are shown because none have been measured. Fill it from your own records; do not populate it from anything in this guide.

Four more that complete the picture — and what each one waits on

These are not on the page above because nothing in the first ninety days produces them honestly. They are listed so that the gap is visible rather than silently absent, and so you know what to ask for when the time comes.

13 — Reference: what can be connected

What can actually be connected

Every entry below was checked against the provider's own documentation in September 2026. Where we could not confirm something, it says so.

A · Your systems — what can be got out of each

Which systems SCI runs comes from your own process maps of April 2025 Your map. What each vendor documents about getting data out comes from the vendor's own material, checked in September 2026 Public. The two are different kinds of claim and the table keeps them apart: the badge describes the vendor's documentation, never confirmation that you use the product.

B · Cost and price context — free, public, and immediately useful

C · Demand signals

Practical route for a Gulf-South plant: monthly CBSA files for pipeline, county or place annual files for territory planning, and FRED's LABPPRIV / TXBPPRIV for a quick state-level trend without any file handling. Remember what a permit is — units authorised, not started and not completed — with imputation for non-responding offices and a benchmark revision each May.

D · Weather and calendar

E · Workforce, maintenance and fleet

Access here varies enormously, and “has an API” is not the same as “you can use it.” This is the section where lead times hide.

14 — Tools and prompts

Four prompts, in order

Use these in a company-approved Claude workspace. Each assumes the previous step is done — running them out of order produces confident answers built on nothing.

Reading this on paper? The prompts have copy buttons in the web version at socomp.runtalon.ai — retyping them is not worth your time.

Appendix A

Weather, calendar and conditions

Test whether conditions explain performance after accounting for the work and the hours actually available.

Weather is the most over-claimed variable in manufacturing analysis, because it correlates with everything — season, product mix, staffing, holidays, overtime. The discipline is to control for those first, and to be honest that an airport is not your plant.

What to examine

• Calendar first, weather second. Hour of shift, weekday, month, season, holidays, shutdowns and — most importantly — scheduled hours from the actual plant calendar. A great many “weather effects” are staffing effects.
• Conditions: temperature, humidity or dew point, precipitation, wind and visibility, during work and during travel. Test lagged effects — yesterday's rain affecting today's yard.
• Outcomes, analysed separately by location: plant, yard, route and destination are four different exposures and combining them hides the signal.

The airport is not the plant

Shreveport Regional sits about seven miles from downtown on open ground. It is a sound instrument for regional conditions — frontal passages, rain days, heat waves, freezes — and the right tool for “did conditions drive that week's variance.” It is not a measurement of your building.

Humidity is the one where this matters most. Lumber responds to the equilibrium moisture content where it is actually stored, which is driven by local conditions, covered-but-open storage and stacking practice — not by airport relative humidity. If moisture turns out to matter to your plate pressing or dimensional variance, two logging hygrometers — one at the lumber rack, one at the press line — will be worth more in six months than twenty years of airport readings. Precipitation is similar: use it as a yes/no signal for disruption, not as a depth measurement, because summer convective rain in north-west Louisiana is highly localised.

Separating weather from what travels with it

Compare similar job complexity, staffing, run length, backlog and scheduled hours. Summer may also mean a different product mix and more overtime. If a condition only ever occurs on one line or in one equipment era, the effects may not be separable at all — and saying so is the correct answer. Begin with monthly and weekday charts, then compare performance after adjustment. Treat exact-date anniversaries with suspicion: even a long archive holds few independent observations of any one calendar date, and searching many patterns will produce apparent ones.

The useful decision, if a pattern survives: better planning for material staging, delivery buffers, job sequencing or staffing. Historical weather does not establish a cause and never replaces existing operating and safety procedures.

Appendix B

Comparing saws and lines fairly

If you rank assets before defining performance, you will rank the work they were given.

Define performance before ranking anything

Make the comparison fair

Control or match for lumber dimension and grade, cut complexity and angles, batch size, setup frequency, truss family, crew coverage, machine configuration and upstream/downstream readiness. Keep model, asset ID, moves, upgrades and replacements distinct over time. Report raw results and adjusted comparisons with sample sizes and the overlap in work types. If one saw only runs short batches and another only long ones, there may be no defensible overall winner — and that is a legitimate finding, not a failure.

Board feet and piece counts do not normalise complexity. Use validated time standards if you have them; if you do not, say the comparison is unadjusted rather than implying it is not.

Name the reason for lost time

Running is processing. Setup is changing jobs or tooling. Starved is waiting for upstream input. Blocked is unable to release downstream. Faulted is equipment interruption. Unscheduled means no production was planned. Preserve unknown when the evidence is absent — a forced guess here corrupts everything built on top of it.

Check queues both before and after the saw and the assembly line. Low utilisation can mean missing lumber; high utilisation can mean unnecessary output. Go and look, to confirm where the constraint actually sits and whether it moves with product mix or shift.

Appendix C

Workforce, pay and performance — asking it defensibly

This is the analysis most likely to be both interesting and wrong. It is worth doing carefully or not at all.

The tempting question is whether higher pay rates go with lower rework, faster completion, better retention or stronger job margins. It is a fair question. The problem is that in any real plant, pay is entangled with almost everything that also drives those outcomes.

What is confounded with pay

• Assignment. More experienced, better-paid crews are usually given the harder jobs — which look worse on raw output and better on defect rates, or the reverse, depending on the plant.
• Tenure. Pay rises with time served, and so does familiarity with the equipment. Separating the two requires variation you may not have.
• Shift and equipment. Shift differentials and line assignment move pay and conditions together.
• Selection. People who perform well get retained and promoted. The causation runs both ways.

How to ask it anyway

1. Start with coverage, not pay. Was the crew fully staffed for the shift? Staffing coverage explains more variance than pay does in most plants, and it is uncontroversial to measure.
2. Then training and certification. SBCA runs formal truss technician training with certification records.^[18] Certification coverage is a cleaner variable than pay — it is discrete, dated, and the plant controls it.
3. Then tenure bands, aggregated. Group into bands, never individuals. Compare on like work only.
4. Pay last, in aggregate, with HR involved. If you get here, use bands, hold job family and shift constant, and state plainly that the result is associative. SBCA's biennial Wage & Benefit Survey gives an external reference point — again, participant-only.^[5]

Appendix D

Finding the days behind the averages

Averages hide the days worth learning from. Build a dated exception report and go look at them.

Study the good days as carefully as the bad

Use adjusted deviations, not highest and lowest volume. On a strong day, was the run unusually repetitive, material pre-staged, the blade recently serviced, the crew fully covered? On a weak day, was output logged late or split into another system? Validate the data before inferring an operating lesson — a surprising number of exceptional days are recording artefacts.

Label each explanation confirmed, plausible, contradicted or unresolved, and attach record IDs. This single habit — writing down what you concluded and why — compounds more than any analysis technique in this guide, because it stops the same issue being rediscovered every year.

Honest time resolution

Use daily or shift records for broad screening. Move to hourly or event-level only where real timestamps support it. Daily totals cannot reveal a five-minute jam. Repeated low output and high heat occurring together is a lead worth investigating, not proof that heat caused a machine problem.

Appendix E

Plain-language glossary

Terms used in this guide, in the sense they are meant here.

Sources and evidence boundary

Where every claim comes from

Public sources consulted September 2026. Each was fetched and checked; annotations say what the source does not establish.

Evidence boundary

No internal Southern Components record was accessed in preparing this guide. One company document was: the SCI process flows of 15 April 2025, which describe the workflow and the systems but contain no job, quote, invoice or personnel data. Everything this guide says about how SCI operates comes from that document and remains subject to your confirmation, because it is seventeen months old. No savings, margin uplift, capacity increase or revenue forecast has been established anywhere in this document, and no figure in it describes your plant. Suggested sample sizes and timings are planning choices, not guarantees of data readiness or pilot success.

What we could not verify, and you should not assume. We have put no number on lumber's share of your cost of goods, and this guide does not depend on one. A truss-specific, peer-company cost structure is only available through SBCA's participant-only survey; broader industry cost detail is published free by the Census Bureau at six-digit NAICS, though under the 2022 classification that code blends trusses with other engineered wood members. There is no published industry benchmark for board feet per man-hour, first-pass quality, on-time delivery, setup time or quote conversion. We found no truss-specific published norm for quote validity periods or escalation-clause practice. Any figure you encounter for these should be treated as an assertion until its source is shown.

Scope of work. Documentation review and public-data analysis only. Nothing was connected, no personnel data was processed, no service was purchased, and no ongoing cost was incurred. Public-source claims were re-checked against provider documentation in September 2026; where an earlier draft of this guide was wrong, the correction is stated in the text rather than quietly applied.