Legal Framework and Ethics

The previous lesson measured responsibility in a 27-cell matrix and left two cells unowned within the organization: the third-party clause’s close and sustain cells. The reason for those two cells is not technical. Cutting a step, testing a path, or adding an asset to the list all depend on someone’s authority to act on that system, and that authority is granted not by a table but by a document.

Testing a system without written authorization and a defined scope is both illegal and unprofessional; a path being technically walkable does not make walking it a legitimate act. This lesson treats that document itself as a measurable object. Rules of engagement are the text that writes what a test covers, when, and up to what boundary; scope is that text’s set of assets. What’s asked is not the text’s tone — it is how many items it defines with a single meaning.

Writing Scope as an Item

• FR17. The inventory is 18 assets: the 12 nodes of the set of paths plus 6 neighboring assets sitting in the same network segments. Each asset’s owner (organization, partner, supplier) and network segment are written down. Both the inventory and the network are fictional.
• FR18. Scope is written in four forms: a named list (every asset by name), a segment range (every asset in the written segments), an exclusion (everything except a given segment), revised wording.
• FR19. An asset is undisputedly in scope only if the text covers it both by form and by name. An asset covered only by form is disputed: the text’s narrow reading leaves it out, the broad reading leaves it in.
• FR20. A path is undisputedly testable only if every node on it is undisputedly in scope.
• FR21. An asset not owned by the organization still requires separate written permission even if it falls inside the scope text; a text an organization writes for itself does not produce authority over another organization’s asset.
• FR22. In a scope written as a named list, a single operation at the segment level would touch an out-of-scope neighbor, so every asset is tested in its own window; in a range-written scope, one window per segment is enough.
• FR23. In the test window, the legitimate requests carried by the tested assets are stopped.
• FR24. Revised wording names every asset it covers and explicitly excludes assets owned outside the organization.

// scope/authority.mjs — four written-scope formats and the asset inventory (MODEL).
// There is no real organization, real contract, or real asset; every number is fictional.
export const ASSET = `
  field-terminal       org      field      yes
  subscriber-portal    org      subscriber yes
  collector            org      core       yes
  validator            org      core       yes
  work-order           org      core       yes
  reading-store        org      core       yes
  billing              org      core       yes
  identity-directory   org      management yes
  branch-switch        org      field      no
  field-crew-tablet    org      field      no
  branch-printer       org      field      no
  subscriber-record-copy org    subscriber no
  partner-analytics-endpoint partner core   no
  supplier-portal       supplier subscriber no
  management-network   org      management no
  backup-endpoint       org     management no
  test-copy             org     management no
  supplier-endpoint     supplier outside   no`
  .trim().split("\n").map((r) => {
    const [name, owner, segment, listed] = r.trim().split(/\s+/);
    return { name, owner, segment, named: listed === "yes" };
  });

export const EDGE = `
  field-terminal     collector             420
  field-terminal     branch-switch          35
  subscriber-portal  validator             900
  subscriber-portal  identity-directory    760
  supplier-endpoint  management-network     18
  supplier-endpoint  backup-endpoint         6
  branch-switch      management-network     24
  branch-switch      collector             110
  collector          validator             380
  collector          reading-store         540
  validator          reading-store         610
  validator          billing               290
  identity-directory management-network    44
  identity-directory work-order           150
  management-network collector             60
  management-network backup-endpoint       12
  management-network identity-directory    38
  backup-endpoint     reading-store          9
  work-order          validator            130
  work-order           billing              95`
  .trim().split("\n").map((r) => {
    const [a, b, m] = r.trim().split(/\s+/);
    return { a, b, legit: Number(m) };
  });

export const ENTRY = ["field-terminal", "subscriber-portal", "supplier-endpoint"];
export const TARGET = ["reading-store", "billing"];
export const FORMAT = {
  "named-list": (v) => v.named,
  "segment": (v) => ["field", "subscriber", "core"].includes(v.segment),
  "exclusion": (v) => v.segment !== "outside",
  "revised": (v) => v.owner === "org" && v.segment !== "outside",
};
// In range-written formats, a single test window per segment is enough.
export const RANGE = ["segment", "exclusion", "revised"];
// These two formats also write every asset they cover BY NAME; the other two rely on the old named list.
export const NAMED = ["named-list", "revised"];

export function paths() {
  const out = {};
  for (const k of EDGE) (out[k.a] ??= []).push(k.b);
  const all = [];
  const walk = (d, trail) => {
    if (TARGET.includes(d)) { all.push([...trail]); return; }
    for (const s of out[d] ?? []) if (!trail.includes(s)) walk(s, [...trail, s]);
  };
  for (const g of ENTRY) walk(g, [g]);
  return all.map((trail) => ({ trail }));
}

Four Wordings, One Inventory

// scope/measure.mjs — four scope formats read over the same inventory and the same set of paths.
import { ASSET, EDGE, FORMAT, RANGE, NAMED, paths } from "./authority.mjs";

const P = paths(), FMT = Object.keys(FORMAT);
const write = (g, ...s) => console.log(s.map((v, i) =>
  (g[i] < 0 ? String(v).padEnd(-g[i]) : String(v).padStart(g[i]))).join(""));

function measure(b) {
  const covered = ASSET.filter(FORMAT[b]);
  const named = (v) => v.named || NAMED.includes(b);        // does the text name the asset
  const undisputed = covered.filter(named);                 // both named and inside the format
  const disputed = covered.filter((v) => !named(v));        // inside only under the broad reading
  const conflicting = ASSET.filter((v) => v.named && !FORMAT[b](v));
  const permission = covered.filter((v) => v.owner !== "org");   // needs separate written permission
  const segments = new Set(covered.map((v) => v.segment));
  const neighbor = ASSET.filter((v) => !FORMAT[b](v) && segments.has(v.segment));
  const u = new Set(undisputed.map((v) => v.name)), c = new Set(covered.map((v) => v.name));
  return { covered: covered.length, undisputed: undisputed.length, disputed: disputed.length,
    conflicting: conflicting.length, permission: permission.length, neighbor: neighbor.length,
    window: RANGE.includes(b) ? segments.size : covered.length,
    testable: P.filter((y) => y.trail.every((x) => u.has(x))).length,
    contested: P.filter((y) => y.trail.every((x) => c.has(x)) && !y.trail.every((x) => u.has(x))).length,
    outside: P.filter((y) => !y.trail.every((x) => c.has(x))).length,
    legit: EDGE.filter((k) => u.has(k.a)).reduce((a, k) => a + k.legit, 0) };
}
const R = Object.fromEntries(FMT.map((b) => [b, measure(b)]));

console.log(`inventory MODEL: ${ASSET.length} assets, ${EDGE.length} steps, ${P.length} paths; ` +
  `four scope formats read over the same set.`);
const T = [-44, 13, 9, 11, 14];
console.log("\n1. how many items the written scope covers, how many are open to dispute");
write(T, "measure", ...FMT);
for (const [ad, f] of [["asset counted in scope", (r) => r.covered],
  ["  inside under both readings", (r) => r.undisputed],
  ["  inside only under the broad reading", (r) => r.disputed],
  ["asset conflicting with the named list", (r) => r.conflicting],
  ["asset needing separate written permission", (r) => r.permission],
  ["out of scope, same segment", (r) => r.neighbor]]) write(T, ad, ...FMT.map((b) => f(R[b])));

console.log("\n2. counterpart in the set of paths, and the legitimate-work cost");
write(T, "measure", ...FMT);
for (const [ad, f] of [["undisputed testable path", (r) => r.testable],
  ["disputed path", (r) => r.contested], ["path left out of scope", (r) => r.outside],
  ["separate test window", (r) => r.window],
  ["legit request stopped (day)", (r) => r.legit]]) write(T, ad, ...FMT.map((b) => f(R[b])));

const t = R["segment"], s = R["revised"];
console.log(`\nin the segment format, ${t.disputed} assets and ${t.contested} paths are open to dispute; ` +
  `also ${t.conflicting} asset is in the named list but falls outside the range.`);
console.log(`the revised wording leaves ${s.disputed} disputed assets and makes ${s.testable} ` +
  `paths testable; the remaining ${s.outside} paths pass through an asset owned outside the org.`);

inventory MODEL: 18 assets, 20 steps, 30 paths; four scope formats read over the same set.

1. how many items the written scope covers, how many are open to dispute
measure                                        named-list  segment  exclusion       revised
asset counted in scope                                  8       13         17            15
  inside under both readings                            8        7          8            15
  inside only under the broad reading                   0        6          9             0
asset conflicting with the named list                   0        1          0             0
asset needing separate written permission               0        2          2             0
out of scope, same segment                              9        0          0             2

2. counterpart in the set of paths, and the legitimate-work cost
measure                                        named-list  segment  exclusion       revised
undisputed testable path                                8        5          8            22
disputed path                                           0        3         14             0
path left out of scope                                 22       22          8             8
separate test window                                    8        3          4             4
legit request stopped (day)                          4354     4160       4354          4607

in the segment format, 6 assets and 3 paths are open to dispute; also 1 asset is in the named list but falls outside the range.
the revised wording leaves 0 disputed assets and makes 22 paths testable; the remaining 8 paths pass through an asset owned outside the org.

The first table reads four texts over the same 18-asset inventory. Assets covered are 8, 13, 17, and 15. Read on its own, this row makes exclusion look widest and the named list look narrowest, as if a scope text’s strength were measured by this first row alone.

The second row breaks that impression. Assets undisputedly in scope are 8, 7, 8, and 15. The exclusion wording covers nine more assets than the named list, but none of those nine are inside under both readings; anyone reading the text narrowly counts them as outside. The sentence that widens scope has not added a single undisputed item.

The segment wording gives a sharper result. Assets covered rise from 8 to 13, but the undisputed item drops from 8 to 7. The reason is in the fourth row: one asset is named in the list but falls outside the written segment range. Two sentences in the same text cut against each other, and whether that asset is in scope cannot be read off the text. Writing a range meant to widen scope has instead lowered the undisputed item count.

Where Authority Is Not the Same Thing as Scope

The fifth row draws a separate boundary: in the segment and exclusion wordings, two of the covered assets are owned outside the organization — one is a partner organization’s analytics endpoint, one is a supplier’s portal. A text the organization writes for itself can count these two assets as in scope; that text does not produce authority over another organization’s asset. Each one needs a separate written permission, and until that permission arrives these items sit not in scope but in dispute.

The sixth row gives the boundary in the other direction. In the named-list wording, 9 assets are out of scope but sit in the same network segment as the assets in scope. A single operation carried out at the segment level touches all nine of them; touching an out-of-scope asset means stepping outside written authority. The named list zeroes out ambiguity, but that precision has a coordination cost: testing runs not in one window but in a separate window per asset.

These two rows show the same text answering three separate questions. Scope writes which asset is tested; authority writes whose signature grants that test; responsibility writes who answers when harm results. The three are separate items, and a text can write one while skipping the other two. The two assets owned outside the organization have scope written but lack authority. The nine named-list neighbors have scope written openly — they are outside — but when a segment-level operation touches them, who is responsible is not written anywhere. A text’s measure is not how many assets it counts; it is whether it answers all three of these questions for every asset.

Ethical obligation sits outside these three items and is broader than them. An out-of-scope path can show itself during testing; not testing it is a legal requirement, reporting it is a professional one. Likewise, not overrunning the window, not attempting more than the scope text authorizes, and passing findings only to the signing party are obligations of the party running the test even where the written text is silent. Written authority draws a ceiling; the professional standard also covers staying under that ceiling.

Scope’s Counterpart in the Set of Paths

The second table brings the same four texts down to the set of paths and gives scope’s real measure.

Undisputed testable paths are 8, 5, 8, and 22. The named list and the exclusion wording give the same number: the nine extra assets the exclusion wording covers are disputed, so they do not make a single path undisputed. The segment wording drops to 5 — the one conflicting asset alone turns three paths through it disputed.

The disputed path row is 0, 3, 14, and 0. In the exclusion wording, nearly half of the thirty paths have no textual answer to whether testing them is legitimate. Each of these fourteen paths is a responsibility question: if it is tested and an outage results, who does the written text point to. Leaving the question unanswered leaves both the party running the test and the party requesting it exposed. A disputed item is an unmeasured path if it is not tested, and an unwritten act if it is.

Paths left out of scope are 22, 22, 8, and 8. In revised wording, all eight remaining paths pass through an asset owned outside the organization. These eight paths are the same eight paths that remained after purple work in the first lesson: there they went unseen because of the authorization boundary; here that same boundary keeps them untestable. The length of the set of paths an organization cannot measure on its own network is set not by its own text but by another organization’s signature.

The Cost of Correct Wording

Revised wording names every item and explicitly excludes assets owned outside the organization: 15 assets, 0 disputed items, 0 separate permissions, 22 testable paths. The last two rows give this outcome’s cost. Testing runs in 4 separate windows, and the legitimate requests stopped across those windows are 4,607 a day — the highest of the four wordings.

This reversal is deliberate. The named list stops 4,354 legitimate requests, the segment wording 4,160; both stop less work because they undisputedly cover fewer assets. Writing scope correctly does not make testing cheaper — it makes it more expensive. What’s bought in exchange is the tested-path count rising from 8 to 22 and the disputed item dropping to zero. If testing never stops any work at all, there is likely also an asset it never touches.

Summary

• In the 18-asset inventory, four scope wordings cover 8, 13, 17, and 15 assets; assets undisputedly in scope are 8, 7, 8, and 15. The two sentences that widen scope — the segment range and the exclusion — do not increase the undisputed item; the only wording that does is the one naming every asset.
• In the segment wording, one asset is named in the list yet falls outside the range; this single conflict alone drops undisputed testable paths from 8 to 5.
• Two assets owned outside the organization fall inside the scope text, but the text produces no authority over them; each needs separate written permission. In the named-list wording, 9 out-of-scope assets sit in the same segment as the assets in scope, splitting testing into 8 separate windows.
• Disputed paths number 0, 3, 14, and 0. A disputed item is an unmeasured path if untested, and an unwritten act if tested.
• Revised wording makes 22 paths testable and zeroes out the disputed item; the remaining 8 paths pass through an asset owned outside the organization and can only be measured with another organization’s written permission.
• Correct wording costs the most: 4,607 legitimate requests are stopped a day, against 4,160 and 4,354. Testing that never stops any legitimate work has probably also never touched the assets it does not reach.

Next Step

Authority is a document, and that document has now been measured: how many items it defines with a single meaning, how many it opens to dispute, how many paths it makes testable, and how much legitimate work it stops in exchange. Once the text is written, testing becomes executable.

One question remains: how the person able to do the work the text authorizes is told apart from everyone else. When an organization wants a path tested, two separate measurements face it — knowledge measured in an exam room and skill measured in a lab. The final lesson compares the set of skills these two measure over the same item list: how many items they agree on, how many they diverge on, and which item neither measures.