Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions AFI_Full_Architecture.md
Original file line number Diff line number Diff line change
Expand Up @@ -92,7 +92,7 @@ The precedence order is governance → config → math → implementation → te
- **`signalId`** is the canonical end-to-end join key. Every artifact about a signal — canonical form, score, evidence record — joins on it.
- **Canonical inbound form** is the Universal Signal Schema **USS v1.1** (`afi.usignal.v1.1`).
- **Strategy identity** is the triple `analystId + strategyId + strategyVersion`.
- **The five analysis categories** are exactly `technical`, `pattern`, `sentiment`, `news`, `aiMl` — a governed namespace (aliases such as `social` or `ai-ml` are disallowed).
- **The five analysis categories** are exactly `technical`, `pattern`, `sentiment`, `news`, `aiMl` — a governed namespace; no other category identifiers are admitted.

These are fixed by the `object-identity-v0.1` and `factory-configurable-pipelines-v1` decisions.

Expand Down Expand Up @@ -298,7 +298,7 @@ flowchart LR
Exactly **two** Districts are formally registered (`authority-districts-v0.1`, Part D, as amended by `district-surface-consolidation-v0.1` (DSC-GOV) and `district-one-signal-evaluation-capability-v0.1` (D1CAP-GOV)). Both are **active capability domains**, and both remain **non-production** (nothing is deployed). No other District is created or implied. Districts represent durable capability and authority boundaries: implementations may be replaced through accepted authority without retiring the district they implement.

- **District 1 — Signal Evaluation** — the **active** Signal Evaluation capability and authority domain (D1CAP-GOV). It owns evaluation from canonical signal input through the scorer/UWR seam: evaluation-time validation, execution of the five enrichment categories, explicit provider-instance resolution for provider-backed categories, category-result validation against the governed `afi.enrichment.*.v1` contracts, deterministic fan-out and join (exactly one validated result per category), analyst invocation under accepted authority, canonical scorer/UWR invocation (invoked, never re-implemented), and creation of the scored evaluation result handed to District 2. Its current implementation is the live flow described in "The current end-to-end flow" below: the two ingress paths → the one manifest-driven `GraphExecutor` (`afi-reactor/src/pipeline/`) → category nodes → enrichment join → analyst/scorer/UWR → the District-2 handoff. The district is not any directory, class, manifest, analyst, or provider — the mapping is descriptive, and a conforming future implementation may replace it through accepted authority. The five-lane provider runtime is **active** for all five categories (FLPR-GOV; see the category table below). Git history preserves the earlier proof-of-concept implementation record; that record's retirement under DSC-GOV was an implementation retirement only — the district is active.
- **District 2 — Canonical Data & Provenance Boundary.** Active. Its M1 schema family is implemented in `afi-config/schemas/provenance/v1` with validation tests, authorized for **M1 only** ("no runtime wiring") by the D-17 instrument homed in afi-docs. Its live provenance law — CanonicalHash v1 (`afi.hash.v1`), the ScoredSignal v1 projection builders, and the D2 schema validators — is implemented in `afi-reactor/src/evidence/provenance/` and runs as a required step of every scoring run; the prospective, bounded, non-production ratification of `district-2-m2-ratification-v0.1` is recorded at that location by DSC-GOV D-DSC-3 (no canonical-object declaration is made). **It receives the scored evaluation result and the five bound provider invocation proofs from District 1 at the scorer/UWR seam** and owns evidence construction, validation, and the canonical handoff to persistence from there: its sole evidence builder validates the five proofs (exactly five, unique by category, deterministically ordered), cross-checks every identity and hash fail-closed, and constructs the one canonical Evidence V3 artifact (`afi.scored-signal-evidence.v3`) that afi-infra persists as sole writer. **District 2 never invokes a provider** — evidence describes the invocation that occurred (EV3-GOV).
- **District 2 — Canonical Data & Provenance Boundary.** Active. Its M1 schema family is implemented in `afi-config/schemas/provenance/v1` with validation tests, authorized for **M1 only** ("no runtime wiring") by R1-GOV D-R1-5 (the District Two M1 authorization re-recorded in afi-governance). Its live provenance law — CanonicalHash v1 (`afi.hash.v1`), the ScoredSignal v1 projection builders, and the D2 schema validators — is implemented in `afi-reactor/src/evidence/provenance/` and runs as a required step of every scoring run; the prospective, bounded, non-production ratification of `district-2-m2-ratification-v0.1` is recorded at that location by DSC-GOV D-DSC-3 (no canonical-object declaration is made). **It receives the scored evaluation result and the five bound provider invocation proofs from District 1 at the scorer/UWR seam** and owns evidence construction, validation, and the canonical handoff to persistence from there: its sole evidence builder validates the five proofs (exactly five, unique by category, deterministically ordered), cross-checks every identity and hash fail-closed, and constructs the one canonical Evidence V3 artifact (`afi.scored-signal-evidence.v3`) that afi-infra persists as sole writer. **District 2 never invokes a provider** — evidence describes the invocation that occurred (EV3-GOV).

**Five-category state (District 1, current truth):**

Expand Down
2 changes: 1 addition & 1 deletion atlas/PROVENANCE.txt
Original file line number Diff line number Diff line change
@@ -1 +1 @@
837f7de9f53714a24569caeb31febd149536339789fadd93a08d73c642bcf25a 63af91e649c7b705b7b96098fcf5657ef8a29a34
24c7b46865ee38e3cf68630babf394f8359b1f51df8b6ca93bfed7b62d6bd042 d6f2504805059ffa09d8c1bfcecb67cd47abcea2
4 changes: 2 additions & 2 deletions atlas/afi-protocol-atlas.v1.json
Original file line number Diff line number Diff line change
Expand Up @@ -68,11 +68,11 @@
{
"districtId": "chain-settlement",
"name": "Settlement, Rewards, Reputation & On-Chain Value",
"purpose": "RESERVED capability-domain candidate (not an active District): the future domain of epoch settlement, reward tracks, reputation, and on-chain value. Recorded exactly as authority-districts-v0.1 Part D.2 and Addendum §13 already record it -- an unnumbered, uncreated candidate that requires its own governance (CHAIN-GOV) before it becomes a District. No current capability is owned here.",
"purpose": "RESERVED capability-domain candidate (not an active District): the future domain of epoch settlement, reward tracks, reputation, and on-chain value. Recorded exactly as authority-districts-v0.1 Part D.2 and R1-GOV D-R1-3 already record it -- an unnumbered, uncreated candidate that requires its own governance (CHAIN-GOV) before it becomes a District. No current capability is owned here.",
"active": false,
"authorityRefs": [
"authority-districts-v0.1 (Part D.2 -- unnumbered uncreated candidate: settlement-readiness/reputation/contracts)",
"AFI_DROID_PIPEHEAD_ADDENDUM.v0.1 (§13 version-expansion roster)",
"R1-GOV D-R1-3 (future-districts version-expansion roster; re-records the former §13 roster authority)",
"CHAIN-GOV (reserved, unfiled)"
],
"maturity": "reserved",
Expand Down
88 changes: 0 additions & 88 deletions reports/district-2-d17-implementation-authorization.md

This file was deleted.

Loading
Loading