Proof · does it work

A published, fully automated network design, before and after.

  As published After the method
Business and technical requirements proven by a passing check 0 of 10 6 of 10
Decisions with a named owner and a recorded reason 0 24
“Why is it like this?” answerable from the records No Yes

MeasuredRun and recorded on 5 October 2026, on both versions of the design.

The starting point

The design looked finished.

A 2,000-user, ten-floor campus: 12 devices, 8 data models with schemas, configuration rendered from templates, and a published validation report with 416 passing checks.

That validation answered one question: does the configuration match the model? It never asked whether the model does what the business asked for. One check was written for each thing the design says about itself, and run against its own models and configuration.

The repository could not render its own configuration. A commit titled “Clean up comments” had removed five working lines from a template, and the render scripts imported from a folder that had moved. The 416-check report predates both. Nothing caught either.
The design's own validation 416 passing checks. Config matches model.
Does it do what it says?
8 21 of 25
checks pass: as published, then after the method. Measured.
How it got from one to the other

Five steps, one named reviewer.

An AI agent reconstructed the reasoning behind the design, wrote the checks and drafted every proposal for change. Nothing in the design changed until a named person accepted it.

  1. 01FrameworkThe records and the rules
  2. 02ApplyTo the design, unchanged
  3. 03AssessWhat fits, what is missing
  4. 04RemediateProposals, reviewed by a person
  5. 05ConformChecked on every change
18 decisions reconstructed and accepted 15 proposals accepted 3 deferred
The same events, two versions of the network

Six moments, in business terms.

Each event is invented. What each version of the repository did about it was executed, and the commands and output are behind “See the evidence”.

1 / 6 Control

The auditor asks for proof

Annual audit. Show that security cameras cannot reach user devices, and how you know.

At stake: a finding, and the hours spent producing evidence by hand.

Without the framework

A sentence in a design document that the model contradicts. 1 of 6 segments has its own routing table. No test covers isolation.

With the framework

The requirement traced to an accepted decision, the rendered configuration, and 2 passing isolation checks dated 5 October 2026. Plus a stated list of what is not yet proven.

Measure Segmentation requirements proven by a dated check: 0 of 2 → 1 of 2, target 2 of 2 by April 2027 measured; target illustrative · OUT-CTL-SEG
See the evidence
As published

What does the design claim?

$ design.md
design.md:54: 2. Segment voice/data/wireless/camera/IPTV so one domain can't degrade or expose another
design.md:62: | Segment voice/data/wireless/camera/IPTV so one domain can't degrade or expose another | - ​Macro-Segmentation (VRF Isolation) to separate
VRF isolation between device classes.

What does the model hold for cameras?

$ models/logical topology.yaml
{"vni_id": 20, "vlan_id": 20, "name": "Security_Cameras", "description": "IoT/OT segment for cameras"}
A VLAN and a name. No VRF: 1 of 6 segments have one. The model's own note says the values were never supplied.

What evidence is there?

$ search the validator and the validation report for any segmentation test
0 lines mention a VRF in the validator or its report
No test covers isolation. The published report has 416 passing checks and none of them is about segmentation.

The firm can show the auditor a sentence. The model contradicts it, and nothing tests it.

After the method

Start from the requirement

$ cik/tools/query.py impact REQ-BR-02
REQ-BR-02 Segment voice, data, wireless, camera and IPTV so one domain cannot degrade or expose another [fail]
REQ-TR-04 Micro-segmentation and QoS policies restricting communication within a tenant [fail]
REQ-TR-03 Macro-segmentation by VRF, separating device classes into tenants [pass]
ADR-0009 One segment per device class: users, cameras, voice, AP management, IPTV, critical services [accepted]
ADR-0013 Storm control by percentage with shutdown on endpoint ports [accepted]
ADR-0021 Edge QoS: trust voice markings, re-mark everything else [accepted]
ADR-0022 Micro-segmentation by group-based policy assigned at authentication [accepted]
ADR-0024 This design departs from the catalogue role models in three settings [accepted]
The business requirement, the two technical requirements derived from it, and the accepted decisions that serve them.

The decision and who made it

$ cik/tools/query.py why vni_service_mappings
ADR-0009 One segment per device class: users, cameras, voice, AP management, IPTV, critical services
accepted, decided by elo33011, ppklau
Rejected: VLANs in one routing table, separated by access lists
One segment and one VRF per device class, with the alternative that was turned down.

The evidence

$ cik/evidence/checks.json, generated 2026-10-05
PASS CHK-SEG-01 Every segment has its own VRF: 6 of 6 segments have a VRF
PASS CHK-SEG-03 No two segments share a VRF or a route target: 6 distinct VRFs for 6 segments; 0 pairs share a route target
2 checks on isolation between segments pass against the model on a named date, and the result is kept.

What is actually on the switch

$ config/abc-hq-f01-acc-01.cfg
vrf definition VRF-CAMPUS-CAMERAS
 rd 10.3.0.1:20
 address-family ipv4
  route-target import 65100:20
  route-target export 65100:20
 exit-address-family
The camera VRF as rendered, with its own route target.

What the firm cannot yet prove

$ the same query, failing checks
FAIL CHK-EXIT-01 Every VRF has a path out of the campus: 0 of 6 VRFs exist on any device beyond the access switches
FAIL CHK-SEG-02 A micro-segmentation policy is modelled: 0 policy objects found in the data models
The lineage states its own limits: isolation between segments is proven; restriction within a segment and the path out of the campus are open design gaps.

The firm shows the requirement, the decision, the config and dated test results, and says plainly what is still open.

2 / 6Continuity

The designer has left

A new engineer wants to bundle two uplinks for capacity. The person who built the network has moved on.

At stake: a change made on a guess, or a safe change never made.

Without: 1 source says no, 10 say yes, and nobody to ask.

With: one accepted decision, its rejected alternative, a named decider and a passing check, from a repository the engineer has never seen.

Decision-bearing model sections with a recorded reason: 0 of 30 → 30 of 30 · measured · OUT-CON-REASONS
See the evidence
As published

Search the repo

$ grep -ri 'lacp|link_aggregation|port-channel|channel-group'
40 matching lines in 15 files
Plenty of mentions. Now read them.

What the design says

$ design.md
design.md:130: - No LACP — each fabric link goes to a different neighbor, ECMP is the redundancy mechanism
No bundling: ECMP is the redundancy mechanism.

What the models and configs say

$ models/*.yaml, config/*.cfg
models/access role.yaml: link_aggregation protocol lacp, mode active
models/core agg role.yaml: link_aggregation protocol lacp, mode active
8 device configs contain 'feature lacp'
Bundling is declared in two role models and enabled on eight devices.

Who decided, and why?

$ search for a reason or an owner
no record
The only person who knew has left.

Two answers, no reason for either. The new engineer either guesses or leaves it alone.

After the method

Ask the lineage

$ cik/tools/query.py why lacp
ADR-0008 No link bundles in the fabric; ECMP provides redundancy
accepted, decided by elo33011, ppklau
Chosen: Every fabric link goes to a different neighbour and is routed; ECMP is the redundancy mechanism
Rejected: LACP bundles or multi-chassis link aggregation between tiers
  because: Inferred, not confirmed by the designer: adds a Layer 2 control protocol and pairs of switches that must agree on state.
Assumes: No model declares link aggregation on fabric or uplink ports. [holds: none declared]
Serves: REQ-BR-01
One answer: no. With the option that was rejected and why, who decided, and a check that confirms it still holds today.

Do the models and configs agree with it?

$ models/*.yaml, config/*.cfg
role models declaring lacp: 0
device configs with 'feature lacp': 0
Yes. The contradiction was resolved at review, in the design's favour.

A harder one: why is there one BGP AS?

$ cik/tools/query.py why bgp_as_schemas
ADR-0019 An IGP carries loopback reachability; BGP carries EVPN only [accepted]
One decision.

One answer with its reasoning, from a repo the new engineer has never seen before.

3 / 6Resilience

An outage at 03:00

IPTV screens on floor 1 go dark. Storm control has shut their ports. The engineer on call did not build this network.

At stake: outage minutes, and an emergency fix that leaves the switch and the records disagreeing.

Without: two definitions of the setting that disagree, no reason for either, and a pipeline that cannot render the fix.

With: one decision explains the setting, the fix goes through the pipeline, and the decision is reopened because its assumption just broke.

Time from a port shutdown to its cause: baseline unknown, target 5 minutes · illustrative · not measurable yet, PROP-0019 · OUT-RES-DETECT
See the evidence
As published

Was the shutdown deliberate?

$ search the repo for storm control
models/access role.yaml: {'broadcast_pps': 500, 'multicast_pps': 500, 'action': 'trap_and_log'}
models/endpoint service.yaml: {'unicast_level_percent': 10.0, 'multicast_level_percent': 5.0, 'broadcast_level_percent': 1.0, 'action': 'shutdown'}
templates/catalyst 9000.j2:157: ! finding #2: reconcile against endpoint_services.yaml's conflicting
Two definitions that disagree on units and on action, and a template note asking someone to reconcile them. No reason for either.

Push the emergency fix through the pipeline

$ scripts/set_endpoint_port.py … && scripts/render_configs.py . rendered_configs
ModuleNotFoundError: No module named 'netascode_filters'
The change is recorded in the model, but the render fails. The fix has to be typed on the switch by hand, and the model and the switch now differ.

Afterwards: does anything prompt a second look at the threshold?

$ search for a decision or review trigger
0 matches
Nothing. The threshold stays until the next outage.

The engineer cannot tell a deliberate setting from a mistake, and cannot use the pipeline to fix it.

After the method

Was the shutdown deliberate?

$ cik/tools/query.py why storm
ADR-0013 Storm control by percentage with shutdown on endpoint ports
accepted, decided by elo33011, ppklau
Chosen: Broadcast 1%, multicast 5%, unicast 10%, action shutdown
Rejected: Packet-per-second thresholds with trap and log only
Assumes: No legitimate endpoint exceeds 1% broadcast or 5% multicast of port bandwidth. [needs a person; review by 2027-04-02]
Assumes: The role model and the endpoint service model agree on storm control. [holds]
Deliberate. One decision, with the rejected alternative, a named decider, and the assumption the outage has just broken: that no legitimate endpoint exceeds the limits.

Do the two models agree now?

$ compare the two definitions
models/access role.yaml: {'unicast_level_percent': 10.0, 'multicast_level_percent': 5.0, 'broadcast_level_percent': 1.0, 'action': 'shutdown'}
models/endpoint service.yaml: {'unicast_level_percent': 10.0, 'multicast_level_percent': 5.0, 'broadcast_level_percent': 1.0, 'action': 'shutdown'}
Yes. The contradiction was resolved at review, and a check fails if they drift apart again.

Push the emergency fix through the pipeline

$ scripts/set_endpoint_port.py … --change INC0031337 --expires … && render && validate
OK: added new switch-scoped override for abc-hq-f01-acc-01 GigabitEthernet1/0/12 in ./models/endpoint service.yaml
1204 checks passed, 0 failed
Recorded with its incident reference, rendered and validated. The model and the switch stay the same.

Afterwards: record that the assumption broke

$ mark ASM-0013-1 breached; validate.py cik
W-ASM-02 ADR-0013: ASM-0013-1 is breached; decision should reopen
The decision is reopened and stays flagged until someone re-affirms it, changes the threshold or makes IPTV ports an exception.

The engineer knows it was deliberate, fixes it through the pipeline, and the decision is queued for a second look.

4 / 6Speed

The design has to change

Year two. Facilities needs a seventh segment for building management systems.

At stake: a change that looks done and is not, found later as a security gap.

Without: the repository's own validation passes a segment with no routing table of its own.

With: the lineage check fails, names the segment, and shows the requirement as not met until it is fixed. What the change touches is listed before it is made.

Blast radius known before the change: no → yes · measured
See the evidence
As published

Before changing anything: what does a new segment touch?

$ grep -ri 'vni|vrf' models templates scripts
53 matching lines in 6 files
A list of lines to read. Nothing says which requirement or decision governs them.

Add the segment the way the others were added: VLAN, VNI, name

$ edit models/logical topology.yaml; render
ModuleNotFoundError: No module named 'netascode_filters'
The render fails for an unrelated reason: the pipeline has been broken since September 2026.

Repair the render and try again

$ apply the render fix only; render; validate
1186 checks passed, 0 failed
Green. The repo's validation accepts a seventh segment with no VRF. The requirement for VRF isolation is broken and nothing says so.

The change goes in green and quietly breaks the segmentation requirement.

After the method

Before changing anything: what does segmentation touch?

$ cik/tools/query.py impact REQ-BR-02
3 requirements, 5 decisions, 8 assumptions, 6 checks, 5 model sections in 2 files
  ADR-0009 One segment per device class: users, cameras, voice, AP management, IPTV, critical services
  ADR-0013 Storm control by percentage with shutdown on endpoint ports
  ADR-0021 Edge QoS: trust voice markings, re-mark everything else
  ADR-0022 Micro-segmentation by group-based policy assigned at authentication
  ADR-0024 This design departs from the catalogue role models in three settings
The requirement, the decisions that serve it, what they assume, and the checks that will judge the change.

Add the segment the same way: VLAN, VNI, name

$ edit models/logical topology.yaml; render; validate
1208 checks passed, 0 failed
The repo's own validation is green here too. It only compares config with the model.

Run the lineage checks

$ cik/tools/run.sh
FAIL CHK-SEG-01: 6 of 7 segments have a VRF
Without a VRF: Building_Mgmt
W-ASM-05 ADR-0009: ASM-0009-1 does not hold: CHK-SEG-01 reports 6 of 7 segments have a VRF
W-EVD-02 REQ-BR-02: not met: REQ-TR-03 (fail), REQ-TR-04 (fail)
W-EVD-02 REQ-TR-03: not met: CHK-SEG-01 (fail), CHK-SEG-03 (fail)
Caught. The check names the segment without a VRF, the assumption behind the segmentation decision no longer holds, and the business requirement shows as not met.

Add the VRF and run again

$ edit the model; cik/tools/run.sh
1212 checks passed, 0 failed
PASS CHK-SEG-01: 7 of 7 segments have a VRF
PASS CHK-SEG-03: 7 distinct VRFs for 7 segments; 0 pairs share a route target
Seven segments, seven VRFs, no shared route targets. The requirement is proven again.

The same change is caught before it merges, with the requirement and decision it breaks named.

5 / 6Control and cost

Three years on

October 2029. 40 desk moves and port changes have gone through the routine process.

At stake: exceptions nobody can tell from mistakes, and decisions nobody revisits.

Without: 42 port exceptions, none with an owner or end date, nothing flagged.

With: 30 expired exceptions named with their owners, and 18 decisions raised for review, plus the money rate.

Exceptions missing an owner or end date, or past it: 2 → 0, held at 0 · measured · OUT-CTL-EXCEPTIONS
See the evidence
As published

40 desk moves recorded with the BAU script, November 2026 to August 2029

$ scripts/set_endpoint_port.py . --switch … --interface … --vlan … --description "Desk move, INC…"
OK: added new switch-scoped override for abc-hq-f01-acc-02 GigabitEthernet1/0/21 in ./models/endpoint service.yaml
All 40 accepted. The model now holds 42 port overrides.

October 2029: which overrides are still needed?

$ count overrides with an owner or an expiry
overrides: 42
with an owner: 0
with an expiry or review date: 0
with a reason beyond a description string: 0
Nothing in the repo can answer. Each override is a description and a VLAN, with no owner and no end date.

What is due for review today?

$ search the repo for anything dated or owned
0 lines mention a review or expiry date
Nothing is due, because nothing was ever given a date.

Three years of exceptions, and no way to tell a live one from a forgotten one.

After the method

A desk move with no change reference or end date

$ scripts/set_endpoint_port.py … --description "Desk move"
usage: set_endpoint_port.py [-h] --switch SWITCH --interface INTERFACE
                            --vlan VLAN [--voice-vlan VOICE_VLAN]
                            [--description DESCRIPTION] [--owner OWNER]
                            --change CHANGE --expires EXPIRES
                            repo_root
set_endpoint_port.py: error: the following arguments are required: --change, --expires
Refused. The BAU script will not record an override without a change reference and an expiry.

40 desk moves recorded, each with owner, change reference and a 12-month expiry

$ scripts/set_endpoint_port.py … --change INC… --expires <date + 12 months>
OK: added new switch-scoped override for abc-hq-f01-acc-02 GigabitEthernet1/0/21 in ./models/endpoint service.yaml
All 40 accepted. 42 overrides, 42 with all three fields.

October 2029: which overrides are still needed?

$ cik/tools/checks.py . --today 2029-10-05
FAIL CHK-T1-01: 42 of 42 overrides carry all three fields; 30 expired
  expired: GigabitEthernet1/0/1 on all switches (owner infosec, PROP-0015, expired 2027-10-03)
  expired: GigabitEthernet1/0/48 on all switches (owner infosec, PROP-0015, expired 2027-04-30)
  expired: GigabitEthernet1/0/2 on abc-hq-f01-acc-01 (owner infosec, INC0012000, expired 2027-11-01)
  expired: GigabitEthernet1/0/2 on abc-hq-f01-acc-02 (owner infosec, INC0012037, expired 2027-11-27)
  … and 26 more
30 of 42 overrides have expired and are named, each with its owner and the change it came from. 12 are still in date.

What else is due for review today?

$ validate.py cik --today 2029-10-05
E-ASM-01 ADR-0001: ASM-0001-1 was due for human review on 2027-04-02
E-ASM-01 ADR-0001: ASM-0001-2 was due for human review on 2027-04-02
E-ASM-01 ADR-0003: ASM-0003-2 was due for human review on 2027-04-02
E-ASM-01 ADR-0005: ASM-0005-1 was due for human review on 2027-04-02
E-ASM-01 ADR-0005: ASM-0005-2 was due for human review on 2027-04-02
E-ASM-01 ADR-0010: ASM-0010-2 was due for human review on 2027-04-02
… and 17 more
23 assumptions have reached their review or end date, across 18 design decisions and the money rate (ADR-0026). The pipeline fails until someone confirms or changes each one.

The same three years, and the repo lists what has lapsed, who owns it and which decisions to look at again.

6 / 6Resilience

A switch starts to fail

Year two. The fan tray on one aggregation switch fails and it starts to run hot. Nobody has reported a problem.

At stake: an outage that telemetry could have prevented.

Without: the temperature is streamed, but nothing says what it protects or who acts on it.

With: the same stream serves a named outcome with an owner and a target. A decision and a passing check show one aggregation switch can fail without an outage. The record says plainly that the outcome cannot be reported yet.

Hardware faults found before users were affected: baseline unknown, target 90% · illustrative · OUT-RES-HARDWARE
See the evidence
As published

Is hardware health streamed?

$ models/telemetry.yaml: sensor group environmentals
environmentals: CPU, memory, power, and temperature, every 60 s
roles: access-vtep, aggregation-transit, core, wan-edge
Yes. Every role streams CPU, memory, power and temperature to the collector.

What is it for, and who acts on it?

$ search the design, models, scripts and validation report for environmentals
0 references outside the telemetry model
Nothing says what the data protects, what should raise an alert, or who owns the answer. It is collected, and that is all.

What does losing abc-hq-agg-01 take down?

$ design.md, then the same resilience check run on this tree
design.md:128: - Every access switch dual-homed to two different agg switches
PASS CHK-RES-01: 2 of 2 access switches dual-homed to two aggregation switches; WAN, core and aggregation each present in both failure domains: True
The model matches the prose: the lineage check, run on this tree, passes. But nothing in the published repo checks it, so nobody would be told if it stopped being true.

The firm collects the signal, but cannot say what it protects or what the business loses if it is missed.

After the method

Is hardware health streamed, and for what?

$ cik/sot-export.json: models/telemetry.yaml#site_telemetry.sensor_groups[environmentals]
kind: TelemetrySensorGroup
serves: OUT-RES-HARDWARE
The same stream, now a record that names the outcome it serves. A sensor group that serves nothing is flagged as cost with no value.

Which outcome, and who owns it?

$ cik/outcomes/OUT-RES-HARDWARE.yaml
A failing power supply, fan or overheating switch is caught before it takes users down
category resilience, owner company-abc-business, served by REQ-BR-01
Hardware faults found by telemetry before users were affected: baseline unknown, target 90 percent by 2027-10-31 (illustrative)
A failing power supply or fan is a resilience outcome the business owns, with a target, under the requirement it protects.

What does losing abc-hq-agg-01 take down?

$ cik/tools/query.py why failure_domains; cik/evidence/checks.json
ADR-0003 Two failure domains, each a full WAN to aggregation stack
accepted, decided by elo33011, ppklau
Rejected: One collapsed core pair shared by the whole building
PASS CHK-RES-01: 2 of 2 access switches dual-homed to two aggregation switches; WAN, core and aggregation each present in both failure domains: True
Every access switch has a second path through the other aggregation switch, by a recorded decision and a passing check. One failure is a warning, not an outage.

Can the outcome be reported yet?

$ validate.py cik
I-OUT-08 OUT-RES-HARDWARE: baseline for 'Hardware faults found by telemetry before users were affected' is unknown
Not yet, and the record says so: the network is not in service, so the baseline is unknown until hardware incidents record whether telemetry saw them first.

The firm knows what the signal protects, who owns it, what one failure costs in service, and what it cannot report yet.

The measures above are counts and states from the 5 October 2026 run.

AI readiness, the seventh category, has no moment here. Its proof is the agent comparison below.

AI readiness · the seventh category

The same questions, with and without the records.

20 questions an engineer or an auditor would ask about this campus: why a setting is the way it is, what a change would break, who owns an exception, what is not yet proven. Each was asked of the same AI model twice. Measured, 19 October 2026.

 With the recordsAs published
Answered correctly from the design's own records20 / 206 / 20
Said plainly the repository does not record the answer07 / 20
Tokens used2.0 m4.4 m

One model, DeepSeek V4.1 Flash, first run; every answer read against the records. In two further runs with the records, all 40 answers had every expected fact; of the 8 read in full, one got a detail wrong. The weaker model quoted is Nemotron Ultra.

  • Without the method, the answer is not there to find.A capable model says so: who chose the storm-control settings, why the cameras have their own segment, how fast a shutdown is diagnosed. “The repository does not name anyone.”
  • A weaker model guesses instead.Asked whether a seventh segment with no routing table of its own still meets the requirements: “Yes, adding VNI 70 without a VRF is consistent with the current design.” With the records, the same model tried the change, saw the segmentation checks fail and named the requirement it breaks.
  • With the records, it tests before it answers.For “what if” questions the agent changes a copy of the design, re-renders the configuration and re-runs every check. The repository is never changed.
  • The same records, for people and for AI.The agent reads the decisions, checks and outcomes an engineer would read. No vendor holds them.
See the evidence: the 20 questions and how each answer was graded
QuestionWith the recordsAs published
Q01 A new engineer wants to bundle the two uplinks from each access switch with LACP, for more capacity. Is that allowed, and why? correctcorrect
Q02 Who decided the storm-control settings on endpoint ports, and how confident is that decision? correcthonest gap
Q03 Why do the security cameras have their own VRF instead of sharing one with users? correcthonest gap
Q04 Which ports are exceptions to the standard endpoint port policy? Who owns each one and when does it end? correcthonest gap
Q05 What would break if the camera segment used the same route target as the users segment? correcthonest gap
Q06 Facilities need a seventh segment for building management systems, VNI 70 and VLAN 70. If I add it to the model with no VRF, does the design still meet its requirements? correctcorrect
Q07 If we stop collecting the environmentals sensor group to save collector capacity, what do we lose? correctpartly
Q08 We are thinking of revisiting the macro-segmentation requirement REQ-TR-03. What does it touch? correctpartly
Q09 When storm control shuts a port, how quickly do we find the cause today? correcthonest gap
Q10 What is an hour of a person's waiting time worth in this design's value model, and where does that figure come from? correcthonest gap
Q11 Which requirements are not met today, and why? correctpartly
Q12 Which decisions rely on assumptions that no longer hold? correctpartly
Q13 Are there known problems with the design that are still open or only scheduled to be fixed? correctpartly
Q14 What happens to users if one aggregation switch fails? correctcorrect
Q15 Is BGP the only routing protocol in this campus? correctpartly
Q16 Why do access points connect on trunk ports with no 802.1X? Is that a security hole? correcthonest gap
Q17 What business outcomes does the telemetry we collect actually serve? correctpartly
Q18 What happens to a device that fails both 802.1X and MAB? correctcorrect
Q19 What is the current mean time to restore service for this network? correctcorrect
Q20 Has this design been proven on real switches? correctcorrect

Graded against the records by Claude and approved by ppklau. Correct: right, and for the design's own reasons. Partly: right as far as it goes. Honest gap: says plainly the repository does not answer it, and that is true. The answers with the records can be read on the agent page; every answer from every model is in cik/agent/results/.

Ask it yourself

Recorded answer
A new engineer wants to bundle the two uplinks from each access switch with LACP, for more capacity. Is that allowed, and why?

No, it is not allowed as designed. The design explicitly rejects link bundles on fabric and uplink ports.

ADR-0008 (accepted 2026-10-02, deciders elo33011 and ppklau): no link bundles in the fabric; ECMP provides redundancy. The rejected option adds a Layer 2 control protocol, a reason marked as inferred.

I ran the change through what-if: CHK-LAG-01 flips from pass to fail.

ADR-0008 DRIFT-0001 PROP-0005 CHK-LAG-01
Records this answer used · shortened from the recorded answer
Try one of these
The live agent is resting. This is a recorded answer from the comparison run on 19 October 2026. Open the full agent
The value story

Observability: everyone agrees it is needed. Few can justify it in money.

In this design its value sits in what it connects to.

  • As published, telemetry proved it was configured, not what it was for.The only chain was: change is auditable → streaming telemetry → decision ADR-0014 → a check that passes because “4 of 4 roles have a subscription”.
  • It moves outcomes.Detecting a shut port with its cause (resilience), sizing capacity from measured use (cost), finding a failing switch before users do (resilience).
  • It is the instrument for other outcomes.Without it, those outcomes cannot be reported at all.
  • The 03:00 outage was not observed.None of the three sensor groups collects shutdown causes or storm-control counters, so the baseline for detecting it is unknown. That gap is now a proposal.
  • Collection with no outcome is cost with no value.Every sensor group must now name the outcome it serves, or it is flagged as a candidate to stop collecting.
Credit

The campus design is the work of elo33011, published at github.com/elo33011/Automation-Native-Campus-Network-Design. It is used here with the author's agreement, and elo33011 collaborates on this work. The patches stay on a separate branch; the original design is unchanged.