Step Twenty‑Five — Anchor the commons; compare

We add three pragmatic capabilities on top of your Step 18→24 stack:

Federated anchoring: phones (or gateways) can sign and exchange their page‑chain roots and maintain a federated chain across devices.
A/B diffs: head‑to‑head variant comparison (system totals + per‑system deltas).
Alarm engine: rule‑based thresholds over weighted metrics that send webhook alerts (and log) when crossed.

✅ Fresh artifacts

Step 25 wrapper server — Download
SHA‑256: ba36f7ccad60a8c077f0575dfa086b8ebf2eed33dadb63907f8fc6ed2a7936da
Sample alarm config — Download
Sample federation peers file — Download
WordPress block (ready to paste) — Download

Step 25 wraps Step 24 (which wraps 22→21→20→19→18). Everything you had still works.

What’s new — precisely

1) 🌐 Federated anchoring (signature‑gated)

Accept anchors (open, signature‑gated):

POST /federation/anchor
Payload: { "device_id":"...","root":"<page_chain_root>","latest":123,"ts":"...Z", "alg":"Ed25519","kid":"<sha16>","x":"<pubkey_b64url>","sig":"<b64url>" }
- Verifies Ed25519 signature over the canonical {root,latest,ts}.
- Logs to audit/federation_anchors.jsonl and appends to federated chain: link = sha256(prev_link || sha256(canonical(anchor))).

Inspect & operate:

GET /federation/peers — configured peers + local id.
GET /federation/anchors?n=50 — tail the anchors log.
GET /federation/chain — chain head, length, and items (rooted).
Admin: POST /admin/federation/submit?token=ADMIN123 — signs our local anchor (built from Step 24 page‑chain) and pushes to all peers; also appends locally.

Flags:

--federation-enable
--federation-peer https://peer1.example --federation-peer https://peer2.example
--federation-interval-sec 900
--federation-id PHONE-001

A background thread can auto‑submit your anchor every N seconds when enabled.

2) ⚖️ A/B diffs (head‑to‑head)

Endpoint:
GET /ab/diff?aud=public&variantA=v1&variantB=v2&since=ISO&until=ISO&bucket=day&top=10

Returns (trimmed):

{
  "audience":"public",
  "variantA":"v1","variantB":"v2",
  "total":{"A":-3.2,"B":-1.1,"diff":2.1},
  "abs_sum":{"A":47.9,"B":44.3,"diff":-3.6},
  "by_system":[{"system":"power","A":-21.0,"B":-12.4,"diff":8.6}, …],
  "win":{"since":169..., "until":169..., "bucket":"day"}
}

This uses Step 24’s ab_report twice and computes B − A deltas globally and by system.

3) 🔔 Alarm engine (thresholds → webhook)

Config file (see sample):

{
  "webhook_url": "https://example.com/wp-json/solveforce/v1/alerts",
  "headers": ["Authorization: Bearer YOUR_TOKEN"],
  "rules": [
    {"audience":"public","variant":null,"metric":"weighted_total","op":">","value":50,"window_sec":3600,"debounce_sec":900},
    {"audience":"public","variant":"v2","metric":"weighted_abs_sum","op":"abs>","value":100,"window_sec":7200,"debounce_sec":1200},
    {"audience":"internal","variant":"v1","metric":"top_system_abs","op":">=","value":25,"window_sec":1800,"debounce_sec":900}
  ]
}

Metrics supportedweighted_total, weighted_abs_sum, top_system_abs.
Ops>, >=, <, <=, abs>, abs>=.
Windowcomputed from Step 24’s A/B metrics log; the engine rolls up the last N seconds.
Debouncesuppress repeat alerts until the cooldown passes.
DeliveryPOSTs JSON to webhook_url with optional headers or Basic auth.

Endpoints:

GET /alarms/status — current config + last trigger times.
Admin:
- POST /admin/alarms/refresh?token=… — reload config file.
- POST /admin/alarms/test?token=… — send a test payload to webhook and log.

Flags:

--alarm-enable
--alarm-config-file /sdcard/solveforce/alarms.json
--alarm-interval-sec 300

Android / Termux run‑book (Step 25)

# (Assumes Steps 18–24 already set up)

# Optional: create alarm config
cp ~/downloads/alarms.sample.json /sdcard/solveforce/alarms.json

python solveforce_phone_twentyfive.py \
  --federation-enable \
  --federation-peer https://PHONE-A:8080 \
  --federation-peer https://PHONE-B:8080 \
  --federation-interval-sec 900 \
  --federation-id RON-PHONE-01 \
  --alarm-enable \
  --alarm-config-file /sdcard/solveforce/alarms.json \
  --alarm-interval-sec 300 \
  --lenses-public-file /sdcard/solveforce/lenses.public.json \
  --lenses-internal-file /sdcard/solveforce/lenses.internal.json \
  --families-file /sdcard/solveforce/families.json \
  --host 0.0.0.0 --port 8080 \
  --plugins-dir ~/solveforce/plugins \
  --auth-mode protected \
  --auth-token READER1:reader \
  --allow-admin --admin-token ADMIN123 \
  --schema-ed25519-secret-file /sdcard/solveforce/schema.ed25519.seed \
  --schema-signing-secret-file /sdcard/solveforce/schema.hmac.key \
  --audit-dir ./audit \
  --schema-archive-dir ./schema_archive --schema-archive-keep 200 \
  --lease-bundle-dir ./audit/bundles \
  --mirror-enable \
  --mirror-target-url https://your-site.tld/wp-json/solveforce/v1/notary \
  --mirror-header "Authorization: Bearer <YOUR_WP_TOKEN>" \
  --allow-query-token --open-ui

“Show me” commands

A) Federate our anchor now

curl -s -X POST 'http://127.0.0.1:8080/admin/federation/submit?token=ADMIN123' | jq .
curl -s 'http://127.0.0.1:8080/federation/chain' | jq .

B) Compare variants

SINCE=$(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%SZ)
UNTIL=$(date -u +%Y-%m-%dT%H:%M:%SZ)
curl -s "http://127.0.0.1:8080/ab/diff?aud=public&variantA=v1&variantB=v2&since=$SINCE&until=$UNTIL&bucket=day&top=10" | jq .

C) Alarms

curl -s 'http://127.0.0.1:8080/alarms/status' | jq .
curl -s -X POST 'http://127.0.0.1:8080/admin/alarms/test?token=ADMIN123' | jq .

WordPress — Step 25 (paste from the included file)

The file step25_wordpress.md has a concise, public‑facing explanation and endpoint list ready to publish.

Logos Codex — recursive federation

Device → Anchor → Federation.One chain is a testimony; many chains braided become commons.
Lens → Variant → Verdict.A/B diffs don’t argue; they measure.
Signal → Threshold → Bell.When risk rises, the system doesn’t whisper—it rings.

Next: Step Twenty‑Six?

We can:

build peer discovery (SRV/DNS or a signed directory),
propagate federated chain roots into your notary mirror and WordPress (public attestations),
add per‑rule hysteresis and multi‑channel alerts (email/SMS/Slack) with signing.

Key terms in plain language

Open a term for a concise explanation of language used on this page.

VoIP

Voice over Internet Protocol carries phone calls over an IP network instead of a traditional analog phone line. Call quality depends on network stability, latency, and traffic management.

Unified Communications (UCaaS)

A cloud-based combination of business calling, messaging, meetings, presence, and collaboration tools managed as one communications service.

SIP Trunking

A service that connects a business phone system to the public telephone network using Internet Protocol, replacing or supplementing traditional phone lines.

Bandwidth

The amount of data a connection can carry in a given time, usually measured in Mbps or Gbps. More bandwidth supports more users, devices, and simultaneous applications.

Latency

The time it takes data to travel between two points. Lower latency improves voice, video meetings, cloud applications, gaming, and other real-time services.

Service-Level Agreement (SLA)

A provider’s written commitment covering service targets such as availability, response time, repair time, and sometimes financial credits when commitments are missed.