Personal note for Jan

Osebna opomba za Jana

Jan, I do not understand internet routing at an operator level, because I do not work in this field professionally. So I am not sending you this page as an attempt to teach you BGP, explain routing causes, or claim that I found an attack, hijack, outage, misconfiguration, or route leak. I am sending it as a technical test of my MDL×DCC method: can the same compression/governance approach that has given me useful, testable results in several other prototype domains — TSP/route planning, NAS/search control, DNA/FASTA analysis, chess, Sudoku, compression experiments, trading arenas, and similar structured-search problems — transfer meaningfully to public routing/BGP data?

Jan, jaz internet routing problematike ne razumem na operaterskem nivoju, ker se s tem profesionalno ne ukvarjam. Zato ti te strani ne pošiljam kot poskus, da bi te učil BGP, razlagal vzroke routing dogodkov ali trdil, da sem našel napad, hijack, outage, misconfiguration ali route leak. Pošiljam ti jo kot tehnični test moje MDL×DCC metode: ali se lahko isti kompresijsko/upravljavski pristop, ki mi je v več drugih prototipnih domenah že dal uporabne in preverljive rezultate — TSP/route planning, NAS/search control, DNA/FASTA analiza, šah, Sudoku, compression eksperimenti, trading arene in podobni structured-search problemi — smiselno prenese tudi na javne routing/BGP podatke?

The question is deliberately narrow: is RouteSignal only a nicer wrapper around update-count / volume ranking, or do peer/cohort residuals and MDL×DCC scoring actually promote cases that an operator would inspect earlier? If it is wrong, please tell me directly. If the direction is interesting, I mainly need to know which baseline, data source, and next test would make it serious.

Vprašanje je namenoma ozko: ali je RouteSignal samo lepše zapakiran update-count / volume ranking, ali pa peer/cohort residuali in MDL×DCC scoring res dvignejo case-e, ki bi jih operater pogledal prej? Če je zgrešeno, mi prosim povej direktno. Če je smer zanimiva, me zanima predvsem, kateri baseline, podatkovni vir in naslednji test bi moral narediti, da stvar postane resna.

MDL×DCC · Internet-ops · Jan technical fast path

RouteSignal Scout

A read-only routing-review prototype. It does not detect attacks or configure routers. It ranks ASN/prefix/time windows so an expert can judge what is worth looking at first.

Read-only routing-review prototip. Ne zaznava napadov in ne konfigurira routerjev. Rangira ASN/prefix/časovna okna, da strokovnjak presodi, kaj je vredno pogledati najprej.

5-minute Jan ask ↓ Jan technical fast path ↓ v0.6 Jan / IPv6 baseline pack ↓ Concrete v0.5 data ↓

v0.4 comparison ↓ Jan feedback ↓ MDL×DCC domain map →

5-minute ask for Jan5-minutno vprašanje za Jana

read this first · judge method, not marketing

What I need from Jan first

Kaj najprej potrebujem od Jana

Please do not read this as a product pitch. Read it as a kill-test request: does the current RouteSignal ranking show anything operator-useful beyond naive update-count / volume sorting?

Prosim, ne beri tega kot produktni pitch. Beri kot kill-test prošnjo: ali trenutni RouteSignal ranking pokaže karkoli operatersko uporabnega nad navadnim update-count / volume sortiranjem?

1 · this 5-min ask2 · 20h30 full run 3 · v0.6 CSV/JSON pack 4 · reply checklistskip marketing sections

Kill it if…the top queue is just volume/update-count shadow, the peer cohort is meaningless, or 2620:fe::/48 looks like an obvious artefact.

Continue if…the demotion of 193.2.0.0/16 and promotion of IPv6/prefix-health cases look technically plausible enough for a stricter holdout test.

Best next answerName the mandatory next baseline and raw source: RIS/RouteViews MRT, RIPEstat, RPKI/ROA, PeeringDB, BGP.Tools, DNS/reachability, looking glass, or something else.

For Jan — technical fast pathZa Jana — tehnični fast path

operator critique first · no sales pitch

The single question this page asks

Eno vprašanje, ki ga ta stran postavlja

Does RouteSignal add operator-useful structure beyond naive BGP activity volume? If v0.5 is merely a prettier way to sort by update count, it is not yet useful. If peer/cohort residuals promote cases that a real operator would rather inspect first, the MDL×DCC transfer is worth a next prototype.

Ali RouteSignal doda operatersko uporabno strukturo nad naiven BGP activity volume? Če je v0.5 samo lepši način sortiranja po update-countu, še ni uporabna. Če peer/cohort residuali dvignejo case-e, ki bi jih realen operater res prej pogledal, je MDL×DCC prenos vreden naslednjega prototipa.

Scout ≠ incident detectorScout = review queueAdvisor not builtbaseline kill-test first

1 · Judge the v0.5 queueIs 2620:fe::/48 as top case interesting, or an artefact of the reduced dataset?

2 · Judge the rank shiftsIs demoting 193.2.0.0/16 from v0.4 rank #1 to v0.5 rank #6 technically sensible?

3 · Judge the wedgeIs IPv6/prefix-health a better first use-case than generic “BGP anomaly detection”?

4 · Judge missing evidenceWhich data source is mandatory next: RIS/RouteViews MRT, RIPEstat, RPKI/ROA, PeeringDB, BGP.Tools, DNS/reachability, looking glass?

Baseline kill-test to run before any Advisor layer

Baseline kill-test pred katerimkoli Advisor slojem

A · update-count baselineSort only by parsed update/support count.

B · own-history residualCompare resource against its own normal/quiet history.

C · peer-cohort residualSubtract expected movement of comparable peers/cohorts first.

D · RouteSignal full scoreUse full MDL×DCC score, then report lift and ablations.

Minimum report: - top-9 overlap with update-count baseline - Spearman/Kendall rank correlation vs update-count - cases v0.5 promotes but update-count does not - cases update-count promotes but v0.5 demotes - ablation: remove peer/cohort residual - operator verdict: useful queue or volume shadow?

Scout v0.6 — Jan / IPv6 prefix-health baseline packScout v0.6 — Jan / IPv6 prefix-health baseline paket

current · CSV/JSON evidence · still Scout-only

What v0.6 adds

Kaj doda v0.6

v0.6 turns the Jan agreement into files, not only text. It generates a dedicated IPv6 prefix-health baseline-test package: CSV, JSON, Markdown, and HTML. The pack gives Jan the things the simulated review asked for: top cases, controls, rank deltas, peer-cohort definition, concrete time windows, source-quality notes, and mandatory missing-evidence checks.

v0.6 dogovor z Janom pretvori v datoteke, ne samo v tekst. Zgradi poseben IPv6 prefix-health baseline-test paket: CSV, JSON, Markdown in HTML. Paket Janu da to, kar je simulirani review zahteval: top case-e, kontrole, rank delte, peer-cohort definicijo, konkretna časovna okna, source-quality opombe in obvezne missing-evidence checke.

evidence rows

9 IPv6 cases · 20 controls · 16 quiet controls

3/5

top-5 overlap

full score vs update-count baseline

0.977

all-case Spearman

still high — volume caveat remains

0.662

peer-vs-full Spearman

peer residual becomes visible but not final proof

Open v0.6 IPv6 baseline HTML CSV evidence pack JSON evidence pack Markdown summary Top review queue CSV

Peer cohort definition — honest current level

Peer cohort definicija — pošten trenutni nivo

current_level: heuristic family cohort from v0.4/v0.5 reduced evidence cohorts: ipv6_prefix, local_regional, major_asn_background, public_dns_v4 meaning: resource rank after peer/structure support is emphasized and parsed/update volume is treated as a control, not a verdict known_limit: not yet true BGP collector peer modeling; Jan should say whether raw RIS/RouteViews MRT is mandatory next

Not enough yet: this is still heuristic family-cohort scoring, not true raw collector-level BGP peer modeling. v0.6 exists to make that limitation explicit and ask Jan which raw source must come next.

Še ni dovolj: to je še vedno heuristični family-cohort scoring, ne pravo surovo collector-level BGP peer modeliranje. v0.6 obstaja zato, da to omejitev eksplicitno pokaže in vpraša Jana, kateri surovi vir mora slediti.

Embedded sample from the v0.6 evidence pack

Vgrajen vzorec iz v0.6 evidence paketa

The full CSV contains all rows. This embedded view shows all IPv6 case rows plus representative controls. Δ means update-count rank minus full-score rank; positive values are cases promoted above naive volume/order.

Polni CSV vsebuje vse vrstice. Ta vgrajen pogled pokaže vse IPv6 case vrstice plus reprezentativne kontrole. Δ pomeni update-count rank minus full-score rank; pozitivne vrednosti so case-i, ki jih full score dvigne nad naiven volume/order.

Role	Resource	Window	Update rank	Peer rank	Full rank	Δ	Parsed	Visibility	Operator comment
case	`2620:fe::/48` ipv6_prefix	2026-04-06T06:00:00Z -> 2026-04-06T08:00:00Z	4	2	1	3	99.72%	updates_parsed:1	Primary Jan check: is this IPv6-prefix ranking useful after update-count is treated as baseline, or is it collector/anycast artefact?
case	`2620:fe::/48` ipv6_prefix	2026-04-06T06:00:00Z -> 2026-04-06T07:00:00Z	4	2	1	3	99.72%	updates_parsed:1	Primary Jan check: is this IPv6-prefix ranking useful after update-count is treated as baseline, or is it collector/anycast artefact?
case	`2620:fe::/48` ipv6_prefix	2026-05-05T09:00:00Z -> 2026-05-05T09:30:00Z	4	2	1	3	99.72%	updates_parsed:1	Primary Jan check: is this IPv6-prefix ranking useful after update-count is treated as baseline, or is it collector/anycast artefact?
case	`2001:4860::/32` ipv6_prefix	2026-04-29T12:00:00Z -> 2026-04-29T13:00:00Z	5	6	3	2	99.55%	updates_parsed:11	Primary Jan check: is this IPv6-prefix ranking useful after update-count is treated as baseline, or is it collector/anycast artefact?
case	`2001:4860::/32` ipv6_prefix	2026-04-29T12:00:00Z -> 2026-04-29T13:00:00Z	5	6	3	2	99.55%	updates_parsed:7	Primary Jan check: is this IPv6-prefix ranking useful after update-count is treated as baseline, or is it collector/anycast artefact?
case	`2001:4860::/32` ipv6_prefix	2026-04-29T04:15:00Z -> 2026-04-29T04:30:00Z	5	6	3	2	99.55%	updates_parsed:4	Primary Jan check: is this IPv6-prefix ranking useful after update-count is treated as baseline, or is it collector/anycast artefact?
case	`2a00:1450::/32` ipv6_prefix	2026-04-29T12:00:00Z -> 2026-04-29T12:30:00Z	6	7	5	1	99.51%	updates_parsed:12	Primary Jan check: is this IPv6-prefix ranking useful after update-count is treated as baseline, or is it collector/anycast artefact?
case	`2a00:1450::/32` ipv6_prefix	2026-04-29T12:00:00Z -> 2026-04-29T12:30:00Z	6	7	5	1	99.51%	updates_parsed:6	Primary Jan check: is this IPv6-prefix ranking useful after update-count is treated as baseline, or is it collector/anycast artefact?
case	`2a00:1450::/32` ipv6_prefix	2026-04-29T04:15:00Z -> 2026-04-29T04:30:00Z	6	7	5	1	99.51%	updates_parsed:6	Primary Jan check: is this IPv6-prefix ranking useful after update-count is treated as baseline, or is it collector/anycast artefact?
control	`208.67.222.0/24` public_dns_v4	2026-05-29T19:30:00Z -> 2026-05-29T20:00:00Z	7	1	2	5	96.47%	updates_parsed:1	Control/reference: public DNS/anycast is highly monitored elsewhere; useful mostly to test volume-shadow behaviour.
control	`208.67.222.0/24` public_dns_v4	2026-05-28T18:30:00Z -> 2026-05-28T19:00:00Z	7	1	2	5	96.47%	updates_parsed:1	Control/reference: public DNS/anycast is highly monitored elsewhere; useful mostly to test volume-shadow behaviour.
control	`208.67.222.0/24` public_dns_v4	2026-05-12T12:00:00Z -> 2026-05-12T12:30:00Z	7	1	2	5	96.47%	updates_parsed:1	Control/reference: public DNS/anycast is highly monitored elsewhere; useful mostly to test volume-shadow behaviour.
control	`8.8.8.0/24` public_dns_v4	2026-05-21T12:00:00Z -> 2026-05-21T12:30:00Z	2	3	4	-2	99.29%	updates_parsed:9	Control/reference: public DNS/anycast is highly monitored elsewhere; useful mostly to test volume-shadow behaviour.
control	`8.8.8.0/24` public_dns_v4	2026-05-21T04:00:00Z -> 2026-05-21T04:30:00Z	2	3	4	-2	99.29%	updates_parsed:1	Control/reference: public DNS/anycast is highly monitored elsewhere; useful mostly to test volume-shadow behaviour.
control	`8.8.8.0/24` public_dns_v4	2026-05-20T05:30:00Z -> 2026-05-20T06:00:00Z	2	3	4	-2	99.29%	updates_parsed:1	Control/reference: public DNS/anycast is highly monitored elsewhere; useful mostly to test volume-shadow behaviour.
control	`193.2.0.0/16` local_regional	2026-03-31T11:00:00Z -> 2026-03-31T11:30:00Z	1	12	6	-5	98.69%	updates_parsed:5	Control row: compare against candidates to decide whether the queue is useful or merely volume sorting.
control	`193.2.0.0/16` local_regional	2026-04-27T01:30:00Z -> 2026-04-27T02:00:00Z	1	12	6	-5	98.69%	updates_parsed:1	Control row: compare against candidates to decide whether the queue is useful or merely volume sorting.
quiet_control	`AS32934` major_asn_background	2026-05-27T00:00:00Z -> 2026-05-27T02:00:00Z	29	16	29	0	0.00%	activity_only:1	Quiet/background control: should remain low unless better parsed/prefix evidence appears.
quiet_control	`AS20940` major_asn_background	2026-04-14T06:00:00Z -> 2026-04-14T08:00:00Z	28	11	28	0	0.00%	activity_only:1	Quiet/background control: should remain low unless better parsed/prefix evidence appears.
quiet_control	`AS20940` major_asn_background	2026-05-12T12:00:00Z -> 2026-05-12T14:00:00Z	28	11	28	0	0.00%	activity_only:1	Quiet/background control: should remain low unless better parsed/prefix evidence appears.
quiet_control	`AS20940` major_asn_background	2026-05-29T03:00:00Z -> 2026-05-29T03:30:00Z	28	11	28	0	0.00%	activity_only:1	Quiet/background control: should remain low unless better parsed/prefix evidence appears.
quiet_control	`AS13335` major_asn_background	2026-04-14T06:00:00Z -> 2026-04-14T08:00:00Z	27	8	27	0	0.00%	activity_only:1	Quiet/background control: should remain low unless better parsed/prefix evidence appears.
quiet_control	`AS13335` major_asn_background	2026-04-14T06:00:00Z -> 2026-04-14T07:00:00Z	27	8	27	0	0.00%	activity_only:1	Quiet/background control: should remain low unless better parsed/prefix evidence appears.

Mandatory next checks before any Advisor claimObvezni naslednji checki pred katerokoli Advisor trditvijo

RIS/RouteViews visibility and AS-path before/during/after representative windows
RPKI/ROA/origin state for each prefix/resource
BGP.Tools / PeeringDB / RIPEstat cross-check links
Looking-glass / traceroute / MTR / DNS reachability companion where relevant
Operator comment: useful queue or volume shadow?

Questions v0.6 now asks Jan directlyVprašanja, ki jih v0.6 zdaj direktno zastavi Janu

core: What is technically wrong here?
baseline: Is v0.6 ranking still a volume/update-count shadow?
top_case: Is 2620:fe::/48 as top case meaningful or an artefact of the reduced dataset?
rank_shift: Is demoting 193.2.0.0/16 from v0.4 #1 to v0.6 #6 technically sensible?
data_source: Which source is mandatory next: RIS/RouteViews MRT, RIPEstat, RPKI/ROA, PeeringDB, BGP.Tools, DNS/reachability, or looking glass?
wedge: Is IPv6/prefix-health the correct first niche before generic BGP anomaly detection?
advisor: Should Advisor remain missing-evidence/runbook-only until raw evidence is stronger?

Operator quick links for the top resourcesHitre operaterske povezave za top resurse

practical triage · no claims

Why this helps

Zakaj je to koristno

This is not evidence by itself. It simply saves Jan from copying prefixes manually. The goal is faster triage: open the public operator views, then judge whether the RouteSignal queue is meaningful or just a ranking artefact.

To samo po sebi ni dokaz. Janu samo prihrani ročno kopiranje prefixov. Cilj je hitrejša triaža: odpri javne operaterske poglede in presodi, ali je RouteSignal queue smiseln ali samo artefakt rangiranja.

Resource	Why it matters on this page	RIPEstat	BGP.Tools	Jan question
`2620:fe::/48`	v0.6d dominant top case; top1 in 85.55% of all pass rows.	RIPEstat	BGP.Tools	Real IPv6/prefix-health signal or anycast/collector artefact?
`193.2.0.0/16`	Old v0.4 volume-heavy leader; demoted around rank 6 in v0.5/v0.6 shape.	RIPEstat	BGP.Tools	Correctly demoted as volume-heavy, or did the peer model miss something?
`AS21283`	Local/regional ASN reference and possible Jan-facing sanity case.	RIPEstat	BGP.Tools	Useful local test resource or too context-specific?
`2001:4860::/32`	Google IPv6 prefix; stable top-3/4 item in the queue.	RIPEstat	BGP.Tools	Meaningful comparator, or too heavily monitored/anycasted?
`2a00:1450::/32`	Google IPv6 prefix; recurring top-5 item.	RIPEstat	BGP.Tools	Good IPv6 control/case, or too similar to other Google prefixes?
`208.67.222.0/24`	Public DNS v4 comparator; ranks high but may be less useful than IPv6 wedge.	RIPEstat	BGP.Tools	Useful comparator, or a distraction from IPv6-first focus?
`8.8.8.0/24`	Public DNS v4 comparator; heavily monitored baseline/control.	RIPEstat	BGP.Tools	Should this be control-only rather than a promoted review case?

v0.6d full overnight — 5 workers / 20h30v0.6d polni overnight — 5 workerjev / 20h30

large engineering evidence · still not operator proof

Why this 85 KB slim ZIP is enough for the page

Zakaj je ta 85 KB slim ZIP dovolj za stran

The raw run_index.csv was about 9.5 GB, so it should not be uploaded or embedded. The slim collector streamed it once and kept the useful analysis layer: overview JSON, rank-stability tables, mutation summaries, top signature frequencies, guardrail summaries, and head/tail/interesting samples. The ZIP is small because the extracted CSV summaries compress extremely well, not because the evidence is empty.

Surovi run_index.csv je bil približno 9.5 GB, zato ga ni smiselno nalagati ali vgrajevati. Slim collector ga je prebral enkrat in obdržal uporabno analitično plast: overview JSON, rank-stability tabele, mutation povzetke, top signature frequency, guardrail povzetke ter head/tail/interesting vzorce. ZIP je majhen zato, ker se povzete CSV datoteke zelo dobro stisnejo, ne zato, ker je evidence prazen.

19,908,625

PASS rows

5 workers · 20h30 timed run

FAIL rows

all streamed rows passed

6,756,387

interesting rows

33.94% of pass rows

39.65%

canonical signature

7,893,564 exact top-9 rows

Most common top-9 signature in the 20h30 run: 2620:fe::/48 > 208.67.222.0/24 > 2001:4860::/32 > 8.8.8.0/24 > 2a00:1450::/32 > 193.2.0.0/16 > 9.9.9.0/24 > AS21283 > 1.1.1.0/24

Main interpretation

Glavna interpretacija

This is useful to add to the page because it scales the earlier 10k local check to almost 20 million pass rows. It confirms the same shape: 2620:fe::/48 remains the dominant top case, the old v0.4 volume leader 193.2.0.0/16 almost never retakes #1, and the dedicated volume_shadow_probe is fully resisted.

To je vredno dodati na stran, ker prejšnji 10k lokalni check razširi na skoraj 20 milijonov PASS vrstic. Potrdi isto obliko: 2620:fe::/48 ostane dominanten top case, stari v0.4 volume leader 193.2.0.0/16 skoraj nikoli ne pride nazaj na #1, namenski volume_shadow_probe pa je v celoti prestan.

Caveat: this is still engineering repeatability/stress evidence, not operator validation. Jan still needs the narrow IPv6 prefix-health baseline/holdout test with raw source checks.

Caveat: to je še vedno inženirska repeatability/stress evidenca, ne operaterska validacija. Jan še vedno potrebuje ozek IPv6 prefix-health baseline/holdout test s preverjanjem surovih virov.

Resource	Seen	Top1	Top1 / all pass	Top1 / seen	Top3 / seen	Top5 / seen	Mean rank	Median	Jan-facing interpretation
`2620:fe::/48`	18,300,372	17,032,562	85.55%	93.07%	98.78%	98.96%	1.1373	1	Dominant top case again; very strong repeatability signal.
`208.67.222.0/24`	18,298,735	2,074,568	10.42%	11.34%	99.18%	99.18%	1.9433	2	Stable #2-style control; often follows 2620.
`2001:4860::/32`	18,300,751	8,586	0.04%	0.05%	89.07%	96.45%	3.1922	3	Stable IPv6 case; usually top-3/top-5.
`8.8.8.0/24`	18,298,302	26,919	0.14%	0.15%	14.53%	87.61%	4.1863	4	Public-DNS control stays visible but not primary.
`2a00:1450::/32`	18,299,993	1,524	0.01%	0.01%	6.50%	91.93%	4.7993	5	Good IPv6 wedge support; mostly #4/#5.
`193.2.0.0/16`	18,295,960	11	0.00%	0.00%	5.20%	20.41%	5.7811	6	Important: old v0.4 volume leader almost never retakes #1.
`9.9.9.0/24`	18,298,365	104	0.00%	0.00%	2.46%	16.19%	6.5317	7	Stable lower public-DNS control.
`AS21283`	18,196,950	382,541	1.92%	2.10%	2.28%	7.86%	7.6108	8	Local/regional case remains visible but not a top driver.
`1.1.1.0/24`	16,767,434	1	0.00%	0.00%	0.04%	2.64%	8.5592	9	Weakest top-9 stability; mostly lower control row.

Guardrail result

Guardrail rezultat

The strongest Jan-facing engineering check is the volume_shadow_probe: it deliberately stresses volume-heavy alternatives, but 2620:fe::/48 still stays #1 in 1,531,575 / 1,531,575 probe rows.

Najmočnejši Jan-facing inženirski check je volume_shadow_probe: namenoma obremeni volume-heavy alternative, vendar 2620:fe::/48 ostane #1 v 1,531,575 / 1,531,575 probe vrsticah.

Mutation	Pass	Interesting	Interesting / pass	Guardrail resisted	v0.5 top IPv6 fell	Background entered top9
`volume_shadow_probe`	1,531,575	1,531,575	100.00%	1,531,575	0	0
`background_promotion_probe`	1,531,034	1,531,034	100.00%	101	0	1,530,933
`ipv6_wedge_probe`	1,531,948	339,060	22.13%	0	41,904	0

Slim 20h30 upload ZIP 20h30 analysis summary Rank stability CSV Top signatures CSV

v0.6c local parallel check — 5 workers / 10k rowsv0.6c lokalni vzporedni check — 5 workerjev / 10k vrstic

engineering evidence · not operator proof

Why this is worth including

Zakaj je to vredno vključiti

This is useful as a reproducibility and guardrail note. I ran the same v0.6b package locally with 5 workers and 10,000 rows while the long overnight run was running elsewhere. The result repeated the same rank shape seen in the longer v0.5/v0.6 evidence: 2620:fe::/48 remained the dominant top case, 193.2.0.0/16 did not retake the old v0.4 volume-leader position, and the volume-shadow probe did not break the ranking.

To je uporabno kot reproducibility in guardrail opomba. Isti v0.6b paket sem lokalno pognal s 5 workerji in 10.000 vrsticami, medtem ko drugje teče daljši overnight run. Rezultat ponovi isto obliko rankinga kot daljši v0.5/v0.6 evidence: 2620:fe::/48 ostane dominanten top case, 193.2.0.0/16 ne prevzame nazaj stare v0.4 volume-leader pozicije, volume-shadow probe pa rankinga ne zlomi.

10,000

rows / runs

5 workers · local micro-stress burst

fail rows

SELF_TEST PASS + run PASS

3,404

interesting rows

mostly deliberate guardrail/stress probes

485

top-9 signatures

rank-order variants under perturbation

39.79%

canonical signature

3,979 / 10,000 exact top-9 order

Most common top-9 signature: 2620:fe::/48 > 208.67.222.0/24 > 2001:4860::/32 > 8.8.8.0/24 > 2a00:1450::/32 > 193.2.0.0/16 > 9.9.9.0/24 > AS21283 > 1.1.1.0/24

Resource	Seen	Top1	Top3	Top5	Top9	Mean rank	Median	Jan-facing interpretation
`2620:fe::/48`	9,156	8,549	9,044	9,061	9,156	1.1336	1	Dominant top case again; useful repeatability signal.
`208.67.222.0/24`	9,158	1,011	9,080	9,080	9,158	1.9481	2	Stable #2-style control; often follows 2620.
`2001:4860::/32`	9,166	2	8,201	8,857	9,166	3.1843	3	Stable IPv6 case, usually top-3/top-5.
`8.8.8.0/24`	9,154	15	1,276	7,983	9,154	4.2026	4	Public-DNS control stays visible but not primary.
`2a00:1450::/32`	9,161	2	599	8,438	9,161	4.7930	5	Good IPv6 wedge support, mostly #4/#5.
`193.2.0.0/16`	9,221	0	505	1,900	9,221	5.7668	6	Important: old v0.4 volume leader did not retake #1.
`9.9.9.0/24`	9,167	0	240	1,486	9,167	6.5343	7	Stable lower public-DNS control.
`AS21283`	9,170	224	238	781	9,170	7.5812	8	Local/regional case remains visible but not a top driver.
`1.1.1.0/24`	8,397	0	2	225	8,397	8.5627	9	Weakest top-9 stability; mostly lower control row.

Keep the caveat visible

Caveat naj ostane viden

This local run is not a new operator validation. It is a small engineering confirmation that the package runs cleanly, produces the expected shape, and resists the specific volume-shadow guardrail. The real Jan-facing test remains the wider IPv6/prefix-health holdout with update-count, own-history, peer-cohort, and full-score baselines.

Ta lokalni run ni nova operaterska validacija. Je majhna inženirska potrditev, da paket teče čisto, da proizvede pričakovano obliko in da prestane specifični volume-shadow guardrail. Pravi Jan-facing test ostaja širši IPv6/prefix-health holdout z update-count, own-history, peer-cohort in full-score baseline-i.

Guardrail detail: under volume_shadow_probe, deliberately boosted volume-heavy targets still did not retake #1; 2620:fe::/48 stayed #1 in 781 / 781 such probes.

Local 5W/10K notes Local 5W/10K upload ZIP

Scout v0.5 — peer-residual / baseline-kill editionScout v0.5 — peer-residual / baseline-kill izdaja

current · RHP improvement · Scout-only

What changed in v0.5

Kaj se je spremenilo v v0.5

v0.5 keeps the v0.4 workbench, but changes the ranking discipline. v0.4 was stable, but baseline testing showed a real risk that the queue was too close to naive parsed/update-count ordering. v0.5 makes peer/cohort residual the primary promotion signal, keeps volume as a control, preserves the v0.4 rank for comparison, and ships a baseline kill-test report before any Advisor layer exists.

v0.5 ohrani v0.4 workbench, spremeni pa ranking disciplino. v0.4 je bil stabilen, baseline testiranje pa je pokazalo realno tveganje, da je queue preblizu naivnemu parsed/update-count sortiranju. v0.5 zato postavi peer/cohort residual kot primarni promotion signal, volumen pusti kot kontrolo, ohrani v0.4 rank za primerjavo in naredi baseline kill-test report še pred kakršnimkoli Advisor slojem.

cases

same reduced-bundle case universe

default review

same non-background review set

0.183

top-9 Spearman

parsed-support order vs v0.5 order

0.977

all-case Spearman

still high across all 30 — caveat

v0.5 rank	Resource	Family	Band	v0.5 score	Peer residual	Non-volume	Volume baseline	v0.4 rank	Volume shadow	Parsed
1	`2620:fe::/48`	ipv6_prefix	strong_review	93.63	100.00	79.13	89.66	7	low / none	99.7%
2	`208.67.222.0/24`	public_dns_v4	strong_review	91.83	100.00	82.03	77.76	8	low / none	96.5%
3	`2001:4860::/32`	ipv6_prefix	strong_review	77.39	74.66	70.23	86.21	3	volume-shadow checked	99.6%
4	`8.8.8.0/24`	public_dns_v4	strong_review	75.15	71.21	53.03	96.55	4	volume-shadow checked	99.3%
5	`2a00:1450::/32`	ipv6_prefix	review_worthy	73.29	66.49	63.89	81.21	2	volume-shadow checked	99.5%
6	`193.2.0.0/16`	local_regional	review_worthy	71.32	74.97	78.27	100.00	1	volume-shadow checked	98.7%
7	`9.9.9.0/24`	public_dns_v4	review_worthy	68.26	55.11	50.76	67.76	5	volume-shadow checked	98.9%
8	`AS21283`	local_regional	review_worthy	63.50	66.55	72.62	93.10	6	volume-shadow checked	97.0%
9	`1.1.1.0/24`	public_dns_v4	review_worthy	59.09	45.26	45.99	74.31	9	volume-shadow checked	96.0%

v0.5 baseline kill-test summaryv0.5 baseline kill-test povzetek

Result: PROMISING / v0.5 review-set order is no longer a parsed-volume sort. The top-9 set still overlaps with parsed-support baseline (9/9), because this reduced bundle has only nine non-background review candidates. The important change is the order: inside the review set, parsed-support order vs v0.5 order has Spearman 0.183, and top-5 overlap is 3/5.

Rezultat: PROMISING / v0.5 review-set order is no longer a parsed-volume sort. Top-9 set se še vedno prekriva s parsed-support baseline-om (9/9), ker ima reduced bundle samo devet non-background review kandidatov. Pomembna sprememba je vrstni red: znotraj review seta je Spearman med parsed-support vrstnim redom in v0.5 vrstnim redom 0.183, top-5 overlap pa 3/5.

Honest caveat: across all 30 cases, parsed-support Spearman is still 0.977. That means v0.5 improves the review order, but it does not yet prove broad baseline superiority. The next proof needs a wider holdout/control input with many more candidate prefixes/ASNs and Jan/operator judgment.

Pošten caveat: čez vseh 30 case-ov je parsed-support Spearman še vedno 0.977. To pomeni, da v0.5 izboljša vrstni red za review, vendar še ne dokaže široke baseline superiority. Naslednji dokaz rabi širši holdout/control input z več kandidati prefixov/ASN-ov in Jan/operator oceno.

Resource	v0.4 rank	v0.5 rank	Shift	Peer residual	Volume baseline
`2620:fe::/48`	7	1	↑ 6	100.00	89.66
`208.67.222.0/24`	8	2	↑ 6	100.00	77.76
`2001:4860::/32`	3	3	same	74.66	86.21
`8.8.8.0/24`	4	4	same	71.21	96.55
`2a00:1450::/32`	2	5	↓ 3	66.49	81.21
`193.2.0.0/16`	1	6	↓ 5	74.97	100.00
`9.9.9.0/24`	5	7	↓ 2	55.11	67.76
`AS21283`	6	8	↓ 2	66.55	93.10
`1.1.1.0/24`	9	9	same	45.26	74.31

Open generated v0.5 casebook Open generated Jan v0.5 pack Read generated baseline report

Note: this package embeds the key v0.5 data in the page. Generated support pages are lightweight mirrors; no fake READY/thin ZIP is linked here.

v0.5 7-hour stress-test analysisv0.5 7-urni stress-test — analiza

2026-06-03 · 10 workers · corrected IPv6 rank reading

Main verdict

Glavni sklep

This is a strong engineering pass, not an operational routing proof. The 7-hour runner recorded 10,163,332 pass rows and 0 fail rows. That says the v0.5 peer-residual workbench is robust under many perturbations. It does not say that any route event is real, harmful, or caused by anything.

To je močan inženirski pass, ne dokaz operaterske routing resničnosti. 7-urni runner je zapisal 10.163.332 pass vrstic in 0 fail vrstic. To pomeni, da je v0.5 peer-residual workbench robusten pod mnogimi perturbacijami. Ne pomeni pa, da je katerikoli routing dogodek realen, škodljiv ali vzročno pojasnjen.

10.16M

pass rows

0 fail rows / 10 workers / 7h

3.45M

interesting rows

mostly deliberate stress/guardrail shifts

7,580

top-9 signatures

rank-order variants under perturbation

39.66%

canonical signature

most common exact top-9 order

85.57%

2620 top1

share of all pass rows

Important correction

Pomemben popravek

The generated rank_stability_by_resource.csv has a watchlist-key bug for IPv6 resources. The CSV fields use names such as rank_2620_fe_48, while the runner writes normalized keys such as rank_2620_fe___48. Therefore the official rank-stability table falsely shows seen=0 for 2620:fe::/48, 2001:4860::/32, and 2a00:1450::/32. The corrected table below was reconstructed from signature_top9, which did contain the IPv6 resources.

Generirani rank_stability_by_resource.csv ima watchlist-key napako za IPv6 resurse. CSV polja uporabljajo imena kot rank_2620_fe_48, runner pa zapisuje normalizirane ključe kot rank_2620_fe___48. Zato uradna rank-stability tabela napačno pokaže seen=0 za 2620:fe::/48, 2001:4860::/32 in 2a00:1450::/32. Spodnja popravljena tabela je rekonstruirana iz signature_top9, kjer so IPv6 resursi bili pravilno prisotni.

Resource	Top9 / all pass	Top1 / all pass	Top3 / all pass	Top5 / all pass	Mean rank	Median	Interpretation
`2620:fe::/48`	91.94%	85.57%	90.81%	90.98%	1.14	1	Dominant v0.5 stress-test winner; strong IPv6 wedge signal.
`208.67.222.0/24`	91.93%	10.41%	91.18%	91.18%	1.94	2	Very stable #2-style control; often follows 2620.
`2001:4860::/32`	91.94%	0.04%	81.91%	88.68%	3.19	3	Stable high IPv6 case; usually top-3/top-5.
`8.8.8.0/24`	91.93%	0.14%	13.34%	80.52%	4.19	4	Stable public-DNS control, but less primary than IPv6.
`2a00:1450::/32`	91.93%	0.01%	5.97%	84.52%	4.80	5	Good IPv6 wedge support, mostly #4/#5.
`193.2.0.0/16`	91.90%	0.00%	4.76%	18.75%	5.78	6	Still in review queue, but no longer volume-dominant #1 — useful sign.
`9.9.9.0/24`	91.93%	0.00%	2.26%	14.89%	6.53	7	Stable lower public-DNS control.
`AS21283`	91.41%	1.91%	2.08%	7.18%	7.61	8	Local/regional case remains visible, but not a top peer-residual driver.
`1.1.1.0/24`	84.25%	0.00%	0.04%	2.22%	8.56	9	Often retained as lower review/control row; weakest top-9 stability.

What this stress test saysKaj ta stress-test pove

Positive

Pozitivno

Ordinary perturbations did not collapse the queue. volume_scale, v04_score_jitter, and topk_shape produced 0 interesting rows; peer_scale, structure_scale, mixed_soft_jitter, and parsed_erosion stayed below ~1.2% interesting rows.

Navadne perturbacije niso sesule queue. volume_scale, v04_score_jitter in topk_shape so imele 0 interesting vrstic; peer_scale, structure_scale, mixed_soft_jitter in parsed_erosion so ostale pod približno 1,2% interesting vrstic.

Useful stress

Koristen stres

family_drop, family_keep, background_promotion_probe, and volume_shadow_probe intentionally create hard conditions. Their high interesting rate is not a crash; it is the guardrail/test machinery doing work.

family_drop, family_keep, background_promotion_probe in volume_shadow_probe namenoma ustvarijo težke pogoje. Visok interesting rate ni crash; to je guardrail/test mehanika pri delu.

Main caution

Glavna previdnost

This still runs over the reduced v0.5 case universe, not over a broad independent holdout. Across all 30 cases the old parsed-support Spearman remains high (0.977), so the next proof must use a wider candidate set.

To še vedno teče nad reduced v0.5 case universe, ne nad širokim neodvisnim holdoutom. Čez vseh 30 case-ov je stari parsed-support Spearman še vedno visok (0,977), zato naslednji dokaz potrebuje širši candidate set.

Canonical top-9 signature, 4,030,976 rows / 39.66%: 2620:fe::/48 > 208.67.222.0/24 > 2001:4860::/32 > 8.8.8.0/24 > 2a00:1450::/32 > 193.2.0.0/16 > 9.9.9.0/24 > AS21283 > 1.1.1.0/24

Code implications for v0.5.1 / v0.6Posledice za kodo v v0.5.1 / v0.6

v0.5.1 patch: fix resource-key normalization in the overnight runner and add an invariant: every resource in signature_top9 must have a matching rank column or be explicitly excluded.
v0.5.1 patch: popravi resource-key normalizacijo v overnight runnerju in dodaj invariant: vsak resurs v signature_top9 mora imeti ujemajoč rank stolpec ali biti eksplicitno izključen.
v0.5.1 report patch: write corrected rank stability directly from the top-k signature, not only from per-resource rank columns.
v0.5.1 report patch: corrected rank stability piši direktno iz top-k signature, ne samo iz per-resource rank stolpcev.
v0.6 proof patch: widen the resource universe so top-9 overlap is no longer forced by having only nine non-background review candidates.
v0.6 proof patch: razširi resource universe, da top-9 overlap ni več prisiljen, ker imamo samo devet non-background review kandidatov.
Advisor gate: do not build causal Advisor until the baseline kill-test beats update-count / parsed-support / own-history / peer-cohort baselines on a wider holdout.
Advisor gate: ne graditi vzročnega Advisorja, dokler baseline kill-test ne premaga update-count / parsed-support / own-history / peer-cohort baseline-ov na širšem holdoutu.

Bottom line for Jan: v0.5 is now more defensible than v0.4 because the old volume leader 193.2.0.0/16 is demoted while IPv6/prefix cases dominate under stress. But the next test must be broader and operator-judged, otherwise this remains an internal ranking-stability result.

Bottom line za Jana: v0.5 je zdaj bolj branljiv kot v0.4, ker je stari volume leader 193.2.0.0/16 znižan, IPv6/prefix case-i pa dominirajo pod stresom. Ampak naslednji test mora biti širši in operatersko ocenjen, sicer to ostane interni ranking-stability rezultat.

Concrete v0.4 data — previous queue for comparisonKonkretni v0.4 podatki — prejšnja queue za primerjavo

embedded v0.4 data · compare against v0.5 peer-residual reranking

For Jan: this block preserves the concrete v0.4 casebook data. It is not the current preferred ranking; it is the comparison baseline that made the v0.5 peer-residual workbench necessary.

Za Jana: ta blok ohrani konkretne v0.4 casebook podatke. To ni več trenutni prednostni ranking; to je primerjalni baseline, zaradi katerega je nastal v0.5 peer-residual workbench.

cases built

zgrajenih case-ov

Full reduced 8h GPT bundle.

default queue

First rows for human operator review.

Prve vrstice za človeški operaterski pregled.

98,547

top-9 support rows

top-9 podporne vrstice

Aggregated rows behind the visible queue.

Agregirane vrstice za vidno queue tabelo.

verdict claims

verdict trditev

No attack / hijack / outage / leak classification.

Brez attack / hijack / outage / leak klasifikacije.

1 · Current top review queue, embedded

1 · Trenutna top review queue, vgrajena v stran

This is the concrete queue Jan can criticize. Scores are queue priority only, not incident probability. The table also exposes support rows, top-event support, context count, and signal-family mix so the page is not just linking to external markdown.

To je konkretna queue tabela, ki jo lahko Jan kritizira. Score pomeni samo prioriteto pregleda, ne verjetnost incidenta. Tabela pokaže tudi podporne vrstice, top-event podporo, število kontekstov in signal-family mix, zato stran ni samo link na zunanje markdown fajle.

Rank	Resource	Family	Band	Score	Parsed	Rows	Top-event rows	Contexts	Signal families
1	`193.2.0.0/16`	local_regional	strong_review	94.43	98.7%	16,550	1,374	73	complexity, diversity, peer_control, unknown, volume, withdrawal
2	`2a00:1450::/32`	ipv6_prefix	strong_review	91.20	99.5%	9,424	521	52	complexity, diversity, ip_version, peer_control, unknown, volume
3	`2001:4860::/32`	ipv6_prefix	strong_review	90.46	99.6%	10,561	1,027	54	complexity, diversity, ip_version, peer_control, unknown, volume
4	`8.8.8.0/24`	public_dns_v4	strong_review	88.07	99.3%	15,551	272	70	complexity, diversity, peer_control, unknown, volume
5	`9.9.9.0/24`	public_dns_v4	strong_review	87.81	98.9%	5,054	190	69	complexity, diversity, peer_control, unknown, volume, withdrawal
6	`AS21283`	local_regional	strong_review	87.01	97.0%	14,381	624	68	complexity, diversity, ip_version, peer_control, unknown, volume
7	`2620:fe::/48`	ipv6_prefix	strong_review	86.06	99.7%	13,074	726	50	complexity, diversity, ip_version, peer_control, unknown, volume
8	`208.67.222.0/24`	public_dns_v4	strong_review	84.11	96.5%	7,470	992	69	complexity, diversity, peer_control, unknown, volume
9	`1.1.1.0/24`	public_dns_v4	review_worthy	76.19	96.0%	6,482	524	54	complexity, diversity, peer_control, unknown, volume

2 · Baseline kill-test — the test that matters first

2 · Baseline kill-test — prvi test, ki zares šteje

The current top queue includes large, public, naturally noisy resources. That creates a hard risk: the score may simply rediscover “large prefix has many updates”. Before deeper Advisor explanations, RouteSignal must show lift against simple baselines.

Trenutni top queue vključuje velike, javne, naravno šumne resurse. To ustvari resno tveganje: score morda samo ponovno odkrije “velik prefix ima veliko update-ov”. Pred globljimi Advisor razlagami mora RouteSignal pokazati lift proti enostavnim baseline-om.

Baseline A · update-countSort only by parsed BGP update count.Sortiraj samo po številu parsed BGP update-ov.

Baseline B · own-history residualCompare each resource against its own quiet/history baseline.Primerjaj vsak resurs z njegovim lastnim quiet/history baseline-om.

Baseline C · peer-cohort residualSubtract the expected movement of comparable peers/cohorts.Odštej pričakovano gibanje primerljivih peer/cohort resursov.

RouteSignal · full scoreRun full current score and compare rank lift after ablations.Poženi polni trenutni score in primerjaj rank lift po ablation testih.

Report to produce next: - top-9 overlap with update-count baseline - Spearman/Kendall rank correlation vs update-count - cases RouteSignal promotes but update-count does not - cases update-count promotes but RouteSignal demotes - ablation: score without peer-contrast - verdict: does RouteSignal add structure beyond volume?

Pass condition: RouteSignal must promote at least some cases that are not merely high-volume resources, and those promoted cases must have a clear residual explanation.

Pogoj za uspeh: RouteSignal mora dvigniti vsaj nekaj case-ov, ki niso samo high-volume resursi, in ti dvignjeni case-i morajo imeti jasno residual razlago.

3 · Deep first case: 193.2.0.0/16

3 · Prvi globlji case: 193.2.0.0/16

Case #1 · 193.2.0.0/16 · local/regional

193.2.0.0/16 · local_regional · 94.43 · parsed 98.7% · rows 16,550 · top-event rows 1,374 · contexts 73

Why promoted: parsed evidence dominates (98.7%); 16,550 supporting v0.2.x resource rows; 1,374 supporting top-event rows; support appears across 22 stage/window tokens; seen in 73 selected analysis runs/files; signal families: complexity, diversity, peer_control, unknown, volume, withdrawal; case family is local_regional, matching the v0.2.5 prefix/IPv6/public-DNS/local-regional wedge

Evidence supports

Parsed-share support is 98.7%.
The registry aggregates 16,550 supporting rows.
Support appears across 73 selected run/file contexts.
Batches/families seen: local_regional;standard_live;thin_zip_extracted.
Activity-only share is 1.3%; this is kept visible as false-positive pressure.

Weak / missing

public routing observation only
no internal router telemetry included
human operator review is still required

Safe review questions

Could this correspond to a known planned maintenance window?
Is this resource normally expected to show this pattern in public routing data?
Does internal monitoring agree or disagree with the public-data signal?
Do route-collector views show the same pattern, or is this collector/source limited?
Do prefix-level reachability probes agree with the BGP-visible pattern?
Is there local ARNES/Slovenian maintenance or telemetry context for the representative windows?

RIPEstat 193.2.0.0/16 BGP.Tools prefix bgp.he.net prefix PeeringDB ARNES search RIPEstat AS2107

Representative windows for case #1

Reprezentativna okna za case #1

Event	Start UTC	End UTC	Operator score	Source quality	Why flagged
`GE00013`	2026-03-31T11:00:00Z	2026-03-31T11:30:00Z	94.1218	updates_parsed	parsed support 5/5; repeated across 5 stages; families complexity,diversity,peer_control,volume
`GE00022`	2026-05-21T12:30:00Z	2026-05-21T13:00:00Z	92.3121	updates_parsed	parsed support 10/10; repeated across 10 stages; families diversity,peer_control,volume
`GE00015`	2026-04-08T11:30:00Z	2026-04-08T12:00:00Z	92.245	updates_parsed	parsed support 12/12; repeated across 12 stages; families diversity,peer_control,volume
`GE00019`	2026-04-08T11:30:00Z	2026-04-08T12:00:00Z	92.245	updates_parsed	parsed support 12/12; repeated across 12 stages; families diversity,peer_control,volume
`GE00026`	2026-05-21T09:00:00Z	2026-05-21T10:00:00Z	91.1976	updates_parsed	parsed support 7/7; repeated across 7 stages; families diversity,peer_control,volume

IPv6-first wedge: concrete queue dataIPv6-first wedge: konkretni queue podatki

The most credible first product claim is not generic “BGP anomaly detection”. It is narrower: IPv6 prefix-health review queue, especially around IPv6-only/dual-stack transition, NAT64/DNS64/464XLAT, renumbering, customer-edge drift, and public-service reachability.

Najbolj kredibilna prva produktna trditev ni generični “BGP anomaly detection”. Ožja in močnejša je: IPv6 prefix-health review queue, posebej za IPv6-only/dual-stack tranzicijo, NAT64/DNS64/464XLAT, renumbering, customer-edge drift in public-service reachability.

Rank	Resource	Score	Parsed	Rows	Top-event rows	Stage/window tokens	Sample window
2	`2a00:1450::/32`	91.20	99.5%	9,424	521	15	2026-04-29T12:00:00Z → 2026-04-29T12:30:00Z
3	`2001:4860::/32`	90.46	99.6%	10,561	1,027	12	2026-04-29T12:00:00Z → 2026-04-29T13:00:00Z
7	`2620:fe::/48`	86.06	99.7%	13,074	726	4	2026-05-05T09:00:00Z → 2026-05-05T09:30:00Z

Public-DNS / anycast controls: concrete queue dataPublic-DNS / anycast kontrole: konkretni queue podatki

These are useful but dangerous as headline examples: public DNS / anycast / CDN resources are globally visible and naturally noisy. They should be treated as controls/reference cases unless peer-cohort normalization proves extra value.

Ti primeri so uporabni, ampak nevarni kot glavna zgodba: public DNS / anycast / CDN resursi so globalno vidni in naravno šumni. Obravnavaj jih kot kontrole/referenčne case-e, dokler peer-cohort normalizacija ne pokaže dodatne vrednosti.

Rank	Resource	Score	Parsed	Rows	Top-event rows	Stage/window tokens	Sample window
4	`8.8.8.0/24`	88.07	99.3%	15,551	272	14	2026-05-21T12:00:00Z → 2026-05-21T12:30:00Z
5	`9.9.9.0/24`	87.81	98.9%	5,054	190	17	2026-05-05T08:00:00Z → 2026-05-05T08:30:00Z
8	`208.67.222.0/24`	84.11	96.5%	7,470	992	5	2026-05-21T12:15:00Z → 2026-05-21T12:30:00Z
9	`1.1.1.0/24`	76.19	96.0%	6,482	524	4	2026-05-25T00:00:00Z → 2026-05-25T02:00:00Z

Advisor preview — not active yetAdvisor preview — še ni aktiven

Advisor should start as missing-evidence/runbook guidance, not cause claims. For each selected case it should ask: RIS/RouteViews visibility? ROA/origin state? cohort-wide or prefix-specific movement? DNS/service reachability? maintenance context? what evidence would downgrade the case?

Advisor naj se začne kot missing-evidence/runbook pomoč, ne kot trditve o vzroku. Za vsak izbran case naj vpraša: RIS/RouteViews visibility? ROA/origin state? cohort-wide ali prefix-specific gibanje? DNS/service reachability? maintenance kontekst? kateri dokazi bi case znižali?

4 · Primary theoretical wedge: peer-cohort residual

4 · Primarni teoretični wedge: peer-cohort residual

RouteSignal should not ask only: “Which prefix has many updates?” It should ask: “Which prefix is less compressible / more residual-heavy than expected, given its own history and comparable peer cohort?” This is the routing analogue of correlation-first trading: subtract the market/global/cohort move first, then score the residual.

RouteSignal ne sme vprašati samo: “Kateri prefix ima veliko update-ov?” Vprašati mora: “Kateri prefix je manj kompresibilen / bolj residual-heavy, kot bi pričakovali glede na njegovo zgodovino in primerljiv peer cohort?” To je routing analogija correlation-first tradinga: najprej odštej market/global/cohort premik, nato oceni residual.

v0.5 MDL target: DL_observed(prefix, window) - DL_expected(prefix | own_history + peer_cohort) Current signal families stay as explainability panels; the baseline-relative MDL residual becomes the cleaner central score if tests support it.

What would kill or narrow RouteSignal?

Kaj bi ubilo ali zožalo RouteSignal?

Top queue ≈ update-count queue with no meaningful residual lift.
Top queue ≈ update-count queue brez pomembnega residual lifta.
Public DNS / anycast / CDN resources dominate because controls are invalid.
Public DNS / anycast / CDN resursi dominirajo, ker so kontrole napačne.
Peer-cohort residual does not improve ranking, or operators do not find promoted cases actionable.
Peer-cohort residual ne izboljša rankinga ali operaterji ne vidijo operativne vrednosti v dvignjenih case-ih.
RIPEstat aggregate evidence is too coarse; raw RIS/RouteViews MRT becomes mandatory before further claims.
RIPEstat agregat evidence je pregrob; raw RIS/RouteViews MRT postane obvezen pred nadaljnjimi trditvami.

What we are actually trying to buildKaj pravzaprav poskušamo zgraditi

one clear purpose, no hype

The problem

Problem

Routing data is noisy. When something looks odd, the hard question is often not “is there an alert?” but “where should an expert look first?”

Routing podatki so šumni. Ko nekaj izgleda čudno, težko vprašanje pogosto ni “ali obstaja alert?”, ampak “kam naj strokovnjak pogleda najprej?”

The Scout layer

Scout sloj

RouteSignal Scout turns public BGP/routing observations into an explainable review queue: ASN/prefix/time windows that are structurally unusual, repeated, and supported by parsed evidence.

RouteSignal Scout pretvori javne BGP/routing podatke v razložljivo review queue: ASN/prefix/časovna okna, ki so strukturno nenavadna, ponovljiva in podprta s parsed evidence.

The next layer

Naslednji sloj

RouteSignal Advisor would take top Scout findings and produce safe diagnostic hypotheses, missing-evidence checks, and operator runbook suggestions — still read-only.

RouteSignal Advisor bi vzel top Scout najdbe in pripravil varne diagnostične hipoteze, preverjanje manjkajočih dokazov in predloge operaterskih runbook korakov — še vedno read-only.

Boundary: RouteSignal does not configure routers, does not issue production routing advice, and does not classify an event as attack, hijack, leak, outage, or misconfiguration. It produces a review queue, not a verdict.

Meja: RouteSignal ne konfigurira routerjev, ne daje produkcijskih routing navodil in ne razglasi dogodka kot attack, hijack, leak, outage ali misconfiguration. Njegov rezultat je review queue, ne razsodba.

Where RouteSignal fits todayKam RouteSignal sodi danes

smart routers ≠ solved triage

Today’s networks are already smart — but triage is still hard. Operators already use smart routers, BGP monitoring, RPKI, telemetry, observability platforms, automation, and more AI/AIOps tooling. RouteSignal is not trying to replace those systems. It targets a narrower gap: when routing data is noisy, repeated, partial, and hard to interpret, it helps decide which ASN/prefix/time windows deserve human review first.

Današnja omrežja so že pametna — toda triaža je še vedno težka. Operaterji že uporabljajo pametne routerje, BGP monitoring, RPKI, telemetrijo, observability platforme, avtomatizacijo in vedno več AI/AIOps orodij. RouteSignal teh sistemov ne poskuša zamenjati. Cilja ožjo vrzel: ko so routing podatki šumni, ponavljajoči, delni in težki za interpretacijo, pomaga odločiti, katera ASN/prefix/časovna okna si zaslužijo človeški pregled najprej.

Not a smarter router

Ni pametnejši router

Routers choose paths according to configured protocol rules and policy. RouteSignal sits outside that loop. It observes public routing evidence and produces a review queue, not routing decisions.

Routerji izbirajo poti po pravilih protokola in nastavljeni politiki. RouteSignal stoji zunaj te zanke. Opazuje javne routing dokaze in ustvari review queue, ne routing odločitev.

Not “AI fixes the internet”

Ni “AI popravi internet”

AI/AIOps can correlate alarms and logs, but routing mistakes are risky to automate blindly. RouteSignal’s safer niche is explainable prioritization: “look here first, and here is the evidence.”

AI/AIOps lahko korelira alarme in loge, routing napake pa je nevarno slepo avtomatsko popravljati. Varnejša niša RouteSignala je razložljivo prioritetiziranje: “najprej poglej tukaj, in to je evidence.”

Operator attention filter

Filter pozornosti

The practical question is often not “do we have alerts?” but “where should a human look first?” RouteSignal reduces duplicated rows into candidate cases, separates parsed-prefix evidence from weaker activity-only noise, and keeps an audit trail.

Praktično vprašanje pogosto ni “ali imamo alerte?”, ampak “kam naj človek pogleda najprej?” RouteSignal podvojene vrstice združi v kandidatne case-e, loči parsed-prefix evidence od šibkejšega activity-only šuma in ohrani audit trail.

v0.3.1 case-builder cleanupv0.3.1 case-builder cleanup

Jan-proof registry · Advisor-ready JSON · still read-only

Full reduced-bundle cases

Case-i iz full reduced bundle-a

The full reduced 8h GPT bundle builds 30 registry cases.

Full reduced 8h GPT bundle zgradi 30 registry case-ov.

Default Jan review cases

Default Jan review case-i

Strong/review-worthy cases shown first; weak/background major-ASN controls are moved to appendix.

Strong/review-worthy case-i so prikazani prvi; weak/background major-ASN kontrole so premaknjene v appendix.

Compact fallback cases

Compact fallback case-i

Bundled input_summaries remain useful for smoke/determinism testing when the reduced ZIP is absent.

Priloženi input_summaries ostanejo uporabni za smoke/determinism test, če reduced ZIP ni zraven.

PASS

v0.3.1 cleanup tests

v0.3.1 cleanup testi

Deduped Advisor windows, review_priority_score, score disclaimer, and deterministic registry compare.

Deduped Advisor windows, review_priority_score, score disclaimer in deterministični registry compare.

What v0.3.1 adds

Kaj doda v0.3.1

v0.3.1 keeps the v0.3 case-builder architecture, but cleans the Jan-facing output: representative windows in Advisor JSON are deduplicated, the score is renamed/clarified as review_priority_score, compact-vs-full input behavior is explicit, and background/weak major-ASN rows no longer dominate the default table.

v0.3.1 ohrani v0.3 case-builder arhitekturo, ampak počisti Jan-facing output: representative windows v Advisor JSON so deduplicirani, score je poimenovan/razložen kot review_priority_score, compact-vs-full input obnašanje je jasno, background/weak major-ASN vrstice pa ne dominirajo več default tabele.

Still not a verdict engine

Še vedno ni verdict engine

A review_priority_score near 90 does not mean 90% probability of a routing problem. It only means this public-data case should appear higher in the human review queue. Advisor v0.1 should remain a read-only hypothesis/checklist assistant.

review_priority_score okoli 90 ne pomeni 90% verjetnosti routing problema. Pomeni samo, da mora ta public-data case priti višje v human review queue. Advisor v0.1 mora ostati read-only hypothesis/checklist assistant.

v0.2.5 reduced-bundle findingsv0.2.5 ugotovitve iz reduced bundle-a

8h live/deep · cleaner evidence · still read-only

651/0

Master test steps

Master test koraki

Master report: 651 PASS, 0 FAIL, 651 total recorded steps.

Master report: 651 PASS, 0 FAIL, 651 zabeleženih testnih korakov.

8h 00m

Deep-live duration

Deep-live trajanje

Target reached at 8h 00m 21.88s, then final report/bundle collection started.

Cilj dosežen pri 8h 00m 21.88s, nato sta sledila final report in bundle collection.

Fail checks

Fail-checki

Reduced log summary reports no fail-checks and no recorded FAIL endings.

Reduced log summary poroča brez fail-checkov in brez zabeleženih FAIL zaključkov.

6,310

Deep top-event rows

Deep top-event vrstice

Compact evidence rows for event review; not unique incidents.

Kompaktne evidence vrstice za pregled; niso unikatni incidenti.

80.7%

Parsed/state evidence

4,924 updates_parsed + 170 state_parsed vs 1,216 activity_only in deep top-event rows.

4.924 updates_parsed + 170 state_parsed proti 1.216 activity_only v deep top-event vrsticah.

644

Analysis runs seen

Analizni runi

The reduced bundle preserved compact summaries from many per-run analyses.

Reduced bundle je ohranil kompaktne povzetke iz veliko per-run analiz.

What looks promising

Kaj izgleda obetavno

The earlier v0.2.2 weakness was activity-only and packaging bloat. In v0.2.5, the 8h run is clean at the test-harness level, and the strongest prefix-focused batches are dominated by parsed evidence. That is exactly the direction RouteSignal needs.

Prejšnja v0.2.2 slabost sta bila activity-only in packaging bloat. V v0.2.5 je 8h run čist na test-harness nivoju, najmočnejši prefix-focused batchi pa so dominirani s parsed evidence. To je točno smer, ki jo RouteSignal potrebuje.

What is not proven yet

Kaj še ni dokazano

This is still not proof that RouteSignal solves routing triage. The reduced bundle aggregates many per-run rows, known-event validation remains mixed, and a human operator still needs to judge whether the top review candidates are operationally meaningful.

To še ni dokaz, da RouteSignal reši routing triage. Reduced bundle agregira veliko per-run vrstic, known-event validacija ostaja mešana, človek operater pa mora še presoditi, ali so top review kandidati operativno smiselni.

What the 8h evidence saysKaj pravi 8h evidence

promising signal, not an incident verdict

Resource / batch	8h reduced-bundle finding	How Jan could read it	Ugotovitev iz 8h reduced bundle-a	Kako naj Jan to bere
193.2.0.0/16	One of the most stable local/regional candidates: 316 top-resource rows and 964 top-event rows in deep evidence, mostly parsed/state rather than activity-only.	Good candidate for a concrete Jan-facing case report: exact windows, AS-path/visibility checks, RPKI/ROA, looking-glass/MTR and maintenance context.	Eden najbolj stabilnih lokalno/regionalnih kandidatov: 316 top-resource vrstic in 964 top-event vrstic v deep evidence, večinoma parsed/state in ne activity-only.	Dober kandidat za konkreten Jan-facing case report: točna okna, AS-path/visibility preverjanje, RPKI/ROA, looking-glass/MTR in maintenance kontekst.
Public DNS prefixes `8.8.8.0/24` · `9.9.9.0/24` · `1.1.1.0/24` · `208.67.222.0/24`	The public-DNS batch is clean: 30,980 parsed rows vs 620 activity-only rows in the false-positive summary, about 98.0% parsed.	Useful as known, externally meaningful control/signal space. If these rank, the tool is seeing visible routing structure, not only random local noise.	Public-DNS batch je čist: 30.980 parsed vrstic proti 620 activity-only vrsticam v false-positive povzetku, približno 98,0% parsed.	Uporabno kot znan, zunanje smiseln control/signal prostor. Če se ti resursi rangirajo, orodje vidi vidno routing strukturo, ne samo naključen lokalni šum.
IPv6 prefixes `2a00:1450::/32` · `2001:4860::/32` · `2620:fe::/48`	This looks like the cleanest first wedge: 31,470 parsed rows vs 130 activity-only rows, about 99.6% parsed. Highest-priority unique event rows are IPv6/prefix rows.	Ask Jan whether IPv6/prefix health is the best first serious use-case before generic BGP anomaly detection.	To izgleda kot najčistejši prvi wedge: 31.470 parsed vrstic proti 130 activity-only vrsticam, približno 99,6% parsed. Najvišje prioritetne unikatne event vrstice so IPv6/prefix vrstice.	Vprašaj Jana, ali je IPv6/prefix health najboljši prvi resen use-case pred generičnim BGP anomaly detection.
AS21283	Best local/regional ASN-style parsed candidate in this evidence: recurrent and much cleaner than the large generic ASN background set.	Worth asking Jan whether this ASN is operationally meaningful or just an artifact of the chosen local/regional watchlist.	Najboljši lokalno/regionalni ASN-style parsed kandidat v tej evidence: ponavljajoč in precej čistejši od velikega generičnega ASN background seta.	Vredno vprašati Jana, ali je ta ASN operativno smiseln ali le artefakt izbrane lokalno/regionalne watchliste.
Major ASNs batch	Still weak as a primary signal: 2,422 parsed rows vs 28,978 activity-only rows, about 92.3% activity-only.	Treat as background/control until RouteSignal gets better ASN-level parsed evidence. Do not pitch major-ASN detection as the main product yet.	Še vedno šibek kot primarni signal: 2.422 parsed vrstic proti 28.978 activity-only vrsticam, približno 92,3% activity-only.	Obravnavaj kot background/control, dokler RouteSignal ne dobi boljšega ASN-level parsed evidence. Major-ASN detection še ni glavna produktna zgodba.

Short interpretation

Kratka interpretacija

The best product story is not “RouteSignal detects incidents.” It is: RouteSignal can produce a cleaner routing review queue, especially for prefix and IPv6/prefix evidence, and RouteSignal Advisor can become the next read-only diagnostic layer.

Najboljša produktna zgodba ni “RouteSignal zaznava incidente”. Je: RouteSignal lahko naredi čistejšo routing review queue, posebej za prefix in IPv6/prefix evidence, RouteSignal Advisor pa je lahko naslednji read-only diagnostični sloj.

For Jan: what to judgeZa Jana: kaj naj presodi

operator critique, not sales pitch

Is the review queue useful?

Je review queue uporabna?

The key question is not whether RouteSignal is “right” automatically. It is whether its top ASN/prefix/time windows are worth an expert’s attention more often than a naive alert list.

Ključno vprašanje ni, ali ima RouteSignal avtomatsko “prav”. Ključno je, ali so njegova top ASN/prefix/časovna okna pogosteje vredna strokovne pozornosti kot naiven alert seznam.

What should be the first real use-case?

Kaj naj bo prvi realen use-case?

The reduced 8h evidence points toward a prefix-first route: local/regional watchlist, IPv6/prefix health, public-DNS reference prefixes, and then Advisor reports for selected cases.

Reduced 8h evidence kaže v prefix-first smer: lokalni/regionalni watchlist, IPv6/prefix health, public-DNS referenčni prefixi in nato Advisor poročila za izbrane primere.

Plain-language explanation for non-specialistsPoljudna razlaga za ne-specialiste

RouteSignal is not a speed booster. It does not change traffic. Its possible value is indirect: if it helps operators find routing oddities faster, then real problems may be corrected sooner.

RouteSignal ni “speed booster”. Ne spreminja prometa. Njegova možna vrednost je posredna: če operaterjem pomaga hitreje najti routing čudnosti, se lahko realne težave prej popravijo.

For ordinary users that could eventually mean fewer long slowdowns, fewer strange reachability issues, and faster recovery from routing problems — but only after operator validation and better data coverage.

Za navadne uporabnike bi to lahko sčasoma pomenilo manj dolgih upočasnitev, manj čudnih težav z dosegljivostjo in hitrejše okrevanje po routing problemih — ampak šele po operaterski validaciji in boljši pokritosti podatkov.

Concrete example: 193.2.0.0/16Konkreten primer: 193.2.0.0/16

What it is: 193.2.0.0/16 is a public IPv4 block, not a home/local network. Public RIPE records identify it as an ARNES provider block / Academic and Research Network of Slovenia, origin AS2107.

Kaj je: 193.2.0.0/16 je javni IPv4 blok, ne domače/lokalno omrežje. Javni RIPE zapisi ga identificirajo kot ARNES provider block / Academic and Research Network of Slovenia, origin AS2107.

What RouteSignal saw: In the v0.2.5 reduced 8h bundle it appears as one of the most stable local/regional candidates: 316 top-resource rows, 964 top-event rows, max priority around 74.5, and a strong parsed/state mix rather than mostly activity-only noise.

Kaj je RouteSignal videl: V v0.2.5 reduced 8h bundle-u se pojavi kot eden najbolj stabilnih lokalno/regionalnih kandidatov: 316 top-resource vrstic, 964 top-event vrstic, max priority okoli 74,5 in močna parsed/state mešanica namesto pretežno activity-only šuma.

What this means: It does not mean ARNES has an incident. It means the Scout layer repeatedly says: “if you have limited review time, this prefix is worth a closer look.”

Kaj to pomeni: To ne pomeni, da ima ARNES incident. Pomeni, da Scout sloj ponavljajoče pravi: “če imaš omejen čas za pregled, je ta prefix vreden podrobnejšega pogleda.”

What an internet expert would do: inspect exact windows, compare AS paths before/during/after, check RIS/RouteViews visibility, RPKI/ROA status, looking-glass/traceroute/MTR evidence, known maintenance context, and any internal telemetry if available.

Kaj bi internet strokovnjak naredil: pogledal bi točna okna, primerjal AS paths pred/med/po dogodku, preveril RIS/RouteViews visibility, RPKI/ROA status, looking-glass/traceroute/MTR dokaze, maintenance kontekst in interno telemetrijo, če je na voljo.

Who could care — and whyKoga lahko to zanima — in zakaj

single consolidated section

ISP / NOC teams

ISP / NOC ekipe

They may want a shorter, explainable list of routing windows worth review.

Lahko jih zanima krajši, razložljiv seznam routing oken, vrednih pregleda.

CDN / DNS / cloud

They care about prefix reachability, visibility, churn, and paths from outside viewpoints.

Zanimajo jih prefix reachability, visibility, churn in poti iz zunanjih opazovalnih točk.

Researchers / CERT / universities

Raziskovalci / CERT / univerze

They may value transparent public-data reproducibility and event/control comparisons.

Lahko cenijo transparentno ponovljivost iz javnih podatkov in event/control primerjave.

Scout v0.4 — built workbench, before AdvisorScout v0.4 — zgrajen workbench, pred Advisorjem

current · built · Scout-only

Current status

Trenutni status

Scout v0.4 is now built. It turns the v0.3.1 case registry into a Jan/operator-facing top-case workbench: casebook, short Jan review pack, explicit case_rank, stronger manifest metadata, evidence trail JSON, Advisor-ready JSON, registry stability report, deterministic tests, and thin packaging.

Scout v0.4 je zdaj zgrajen. v0.3.1 case registry pretvori v Jan/operator-facing top-case workbench: casebook, kratek Jan review pack, eksplicitni case_rank, močnejše manifest metapodatke, evidence-trail JSON, Advisor-ready JSON, registry-stability report, deterministične teste in thin packaging.

Boundary remains unchanged: Scout is a review-priority filter only. It does not diagnose incidents, does not claim attacks/hijacks/leaks/outages/misconfigurations, and does not recommend routing changes.

Meja ostaja ista: Scout je samo review-priority filter. Ne diagnosticira incidentov, ne trdi attack/hijack/leak/outage/misconfiguration in ne predlaga routing sprememb.

Built outputs

Zgrajeni outputi

v0.4 produces the case registry, top review queue, casebook HTML, Jan pack, evidence trail JSON, Advisor-ready JSON, manifest, stability report, case summary, case cards, READY ZIP, and thin GPT package.

v0.4 izdela case registry, top review queue, casebook HTML, Jan pack, evidence-trail JSON, Advisor-ready JSON, manifest, stability report, case summary, case cards, READY ZIP in thin GPT paket.

Top queue remains

Top queue ostaja

The default full-reduced casebook still gives 30 cases and 9 default review cases, led by 193.2.0.0/16, Google IPv6 prefixes, public DNS prefixes, and AS21283.

Default full-reduced casebook še vedno da 30 case-ov in 9 default review case-ov, z 193.2.0.0/16, Google IPv6 prefixi, public DNS prefixi in AS21283 pri vrhu.

Advisor readiness

Pripravljenost za Advisor

The JSON handoff is ready for a later read-only Advisor, but Advisor should wait until Jan/operator feedback and the next baseline kill-test.

JSON handoff je pripravljen za kasnejši read-only Advisor, ampak Advisor naj počaka na Jan/operator feedback in naslednji baseline kill-test.

Rank	Resource	Family	Band	Score	Parsed
1	`193.2.0.0/16`	local_regional	strong_review	94.43	98.7%
2	`2a00:1450::/32`	ipv6_prefix	strong_review	91.20	99.5%
3	`2001:4860::/32`	ipv6_prefix	strong_review	90.46	99.6%
4	`8.8.8.0/24`	public_dns_v4	strong_review	88.07	99.3%
5	`9.9.9.0/24`	public_dns_v4	strong_review	87.81	98.9%
6	`AS21283`	local_regional	strong_review	87.01	97.0%
7	`2620:fe::/48`	ipv6_prefix	strong_review	86.06	99.7%
8	`208.67.222.0/24`	public_dns_v4	strong_review	84.11	96.5%
9	`1.1.1.0/24`	public_dns_v4	review_worthy	76.19	96.0%

Preserved earlier v0.4 proposal textOhranjen prejšnji v0.4 proposal tekst

This is the older pre-build section kept for history, because it explains why v0.4 was built before Advisor.

To je starejša pred-build sekcija, ohranjena za zgodovino, ker pojasni, zakaj je bil v0.4 zgrajen pred Advisorjem.

Scout v0.4 — before AdvisorScout v0.4 — pred Advisorjem

proposal · not built yet

Top-case workbench

Turn each top case into a compact casebook card: exact windows, why promoted, evidence quality, safe next checks, and “must not conclude.”

Vsak top case naj postane kompaktna casebook kartica: točna okna, zakaj je promoviran, quality evidence, safe next checks in “must not conclude”.

Canonical metadata

Kanončni metapodatki

Add explicit case_rank, input profile, registry hash, generated_at, source bundle, and case_count into JSON/HTML/report outputs.

Dodaj eksplicitni case_rank, input profile, registry hash, generated_at, source bundle in case_count v JSON/HTML/report outpute.

Freshness comparison

Freshness primerjava

After Scout v0.4, run a shorter fresh v0.2.5/v0.3.1-style live chain and compare whether the same case families stay near the top.

Po Scout v0.4 poženi krajšo svežo v0.2.5/v0.3.1-style live verigo in primerjaj, ali iste case družine ostanejo pri vrhu.

Why before Advisor? Advisor will only be as good as the cases it receives. Scout v0.4 should make the top cases exact, stable, and easy for Jan to judge before any deeper hypothesis layer writes explanations.

Zakaj pred Advisorjem? Advisor bo dober samo toliko, kot so dobri case-i, ki jih dobi. Scout v0.4 naj top case-e naredi točne, stabilne in Janu hitro presodljive, preden globlji hypothesis layer piše razlage.

AppendicesDodatki

collapsed by design

Known-event/control checks remain mixedKnown-event/control preverjanje ostaja mešano

Earlier v0.2 known-event checks were intentionally conservative: Cloudflare/1.1.1.0/24 showed only weak activity-only lift, Facebook/AS32934 was unsuitable/missing in the current public-data path, and AS13335 did not beat its control in that evidence. This is why the public story should lean on repeated parsed-prefix review cases, not on claims of incident detection.

Prejšnji v0.2 known-event testi so bili namenoma strogi: Cloudflare/1.1.1.0/24 je pokazal samo šibek activity-only lift, Facebook/AS32934 je bil v trenutni public-data poti unsuitable/missing, AS13335 pa v tisti evidence ni premagal kontrole. Zato se javna zgodba ne sme naslanjati na “incident detection”, ampak na ponavljajoče parsed-prefix review case-e.

Technical method in one paragraphTehnična metoda v enem odstavku

RouteSignal uses MDL-style residual/complexity scoring, DCC-style multi-signal gating, parsed-first ranking, source-quality checks, repeated-resource support, known-event/control comparisons, false-positive pressure, and a global event ledger over read-only BGP/routing observations.

RouteSignal uporablja MDL-style residual/complexity scoring, DCC-style multi-signal gating, parsed-first ranking, source-quality preverjanje, repeated-resource podporo, known-event/control primerjave, false-positive pritisk in global event ledger nad read-only BGP/routing opazovanji.

Appendix: prompt-method story behind RouteSignalDodatek: zgodba o promptanju za RouteSignal

This is deliberately collapsed and placed at the end. The main RouteSignal page is now for Jan and for internet-ops substance: what Scout found, whether the case queue is useful, and what to build next. The prompt-method story is still part of the project history, but it should not dominate the page.

To je namenoma kolapsirano in postavljeno na konec. Glavna RouteSignal stran je zdaj za Jana in za internet-ops vsebino: kaj je Scout našel, ali je case queue uporaben in kaj zgraditi naprej. Zgodba o promptanju je še vedno del zgodovine projekta, ampak ne sme dominirati strani.

What was compared?

Kaj smo primerjali?

The same RouteSignal builder seed was tested through several prompt paths: a direct prompt, Microsoft Prompt Coach, Copilot + RHPr/RHP, fresh BD × GPT RHPr/RHP, and the older hybrid reference lineage.

Isti RouteSignal builder seed smo preizkusili skozi več prompt poti: direct prompt, Microsoft Prompt Coach, Copilot + RHPr/RHP, svež BD × GPT RHPr/RHP in starejšo hybrid reference linijo.

Why it matters

Zakaj je pomembno

It showed that the prompting method affected not only the text of the prompt, but also the quality of the produced Python package: scope control, tests, resume behavior, evidence packaging, and no-production-claims discipline.

Pokazalo se je, da metoda promptanja ni vplivala samo na besedilo prompta, ampak tudi na kakovost nastalega Python paketa: scope control, teste, resume vedenje, evidence packaging in disciplino brez production trditev.

Path	Prompt score	Code-output score	Interpretation
E · older hybrid reference lineage	96/100	96–98/100	Strong reference/champion lineage, but not a same-condition fresh one-shot peer.
D · fresh BD × GPT RHPr/RHP	94/100	94/100	Best fresh A/B/C/D path; strong balance of structure, constraints, and builder realism.
C · Copilot + RHPr/RHP	91/100	92/100	Good artifact discipline and implementation focus.
A · direct prompt	89/100	91/100	Clean baseline; surprisingly competent but less controlled.
B · Microsoft Prompt Coach	82/100	81/100	Weakest in this specific coding-builder test; too generic for the required architecture.

The full companion page remains the right place for details, scoring, caveats, and the A/B/C/D/E narrative.

Polna spremljevalna stran ostaja pravo mesto za podrobnosti, ocene, omejitve in A/B/C/D/E zgodbo.

Open full RouteSignal Prompt Method Study →

BD × AI Lab · RouteSignal Scout · v0.6g Jan fast path · Jan-first technical fast path · MDL×DCC transfer test · v0.6d full 5W/20h30 run · v0.6 Jan / IPv6 prefix-health baseline pack · local 5W/10K check · v0.5 7h stress analysis · Scout-only, read-only, no incident verdicts · updated 2026-06-04

Personal note for Jan

Osebna opomba za Jana

RouteSignal Scout

5-minute ask for Jan5-minutno vprašanje za Jana

What I need from Jan first

Kaj najprej potrebujem od Jana

For Jan — technical fast pathZa Jana — tehnični fast path

The single question this page asks

Eno vprašanje, ki ga ta stran postavlja

Baseline kill-test to run before any Advisor layer

Baseline kill-test pred katerimkoli Advisor slojem

Scout v0.6 — Jan / IPv6 prefix-health baseline packScout v0.6 — Jan / IPv6 prefix-health baseline paket

What v0.6 adds

Kaj doda v0.6

Peer cohort definition — honest current level

Peer cohort definicija — pošten trenutni nivo

Embedded sample from the v0.6 evidence pack

Vgrajen vzorec iz v0.6 evidence paketa

Operator quick links for the top resourcesHitre operaterske povezave za top resurse

Why this helps

Zakaj je to koristno

v0.6d full overnight — 5 workers / 20h30v0.6d polni overnight — 5 workerjev / 20h30

Why this 85 KB slim ZIP is enough for the page

Zakaj je ta 85 KB slim ZIP dovolj za stran

Main interpretation

Glavna interpretacija

Guardrail result

Guardrail rezultat

v0.6c local parallel check — 5 workers / 10k rowsv0.6c lokalni vzporedni check — 5 workerjev / 10k vrstic

Why this is worth including

Zakaj je to vredno vključiti

Keep the caveat visible

Caveat naj ostane viden

Scout v0.5 — peer-residual / baseline-kill editionScout v0.5 — peer-residual / baseline-kill izdaja

What changed in v0.5

Kaj se je spremenilo v v0.5

v0.5 7-hour stress-test analysisv0.5 7-urni stress-test — analiza

Main verdict

Glavni sklep

Important correction

Pomemben popravek

Positive

Pozitivno

Useful stress

Koristen stres

Main caution

Glavna previdnost

Concrete v0.4 data — previous queue for comparisonKonkretni v0.4 podatki — prejšnja queue za primerjavo

1 · Current top review queue, embedded

1 · Trenutna top review queue, vgrajena v stran

2 · Baseline kill-test — the test that matters first

2 · Baseline kill-test — prvi test, ki zares šteje

3 · Deep first case: 193.2.0.0/16

3 · Prvi globlji case: 193.2.0.0/16

Evidence supports

Weak / missing

Safe review questions

Representative windows for case #1

Reprezentativna okna za case #1

4 · Primary theoretical wedge: peer-cohort residual

4 · Primarni teoretični wedge: peer-cohort residual

What would kill or narrow RouteSignal?

Kaj bi ubilo ali zožalo RouteSignal?

Jan feedback — after the key dataJan feedback — po ključnih podatkih

What we are actually trying to buildKaj pravzaprav poskušamo zgraditi

The problem

Problem

The Scout layer

Scout sloj

The next layer

Naslednji sloj

Where RouteSignal fits todayKam RouteSignal sodi danes

Not a smarter router

Ni pametnejši router

Not “AI fixes the internet”

Ni “AI popravi internet”

Operator attention filter

Filter pozornosti

v0.3.1 case-builder cleanupv0.3.1 case-builder cleanup

What v0.3.1 adds