Status: CANDIDATE · PRE-RATIFICATION
Repository candidate: dagr-analytics
Surface/product name candidate: Observatory
Date: 2026-08-09

1. North star

Measure how knowledge is used, not how to manipulate attention.

DAGR Analytics is a cross-platform measurement substrate for Counterpedia, Amnesiac, Forum, MCP/API surfaces, and later DAGR applications.

It should make activity inspectable with the same discipline Counterpedia applies to knowledge:

CONTENT
  has provenance

ACTIVITY
  has provenance

METRICS
  have definitions

PERSONAL ANALYTICS
  have owners and consent boundaries

The repository is not an ad-tech system, recommendation engine, identity profiler, or claim-governance authority.

2. Core architectural rule

Instrument the lattice before instrumenting the person.

For public/web/agent activity, prefer observations about:

what surface was used
what object was accessed
what edge was traversed
what operation occurred
what transport was used

over:

who the person "really is"
what demographic they probably belong to
what ideology they likely hold
what hidden intention they had

For Amnesiac-derived analytics:

Instrument the person inside the person's boundary first.

Raw private cognitive/preference history should remain local/private by default.

3. What this repo owns

dagr-analytics owns:

analytics doctrine
privacy / consent classes
event contracts
metric definitions
metric registry
deterministic aggregation rules
derived analytics algorithms
platform adapters
public aggregate schemas
private/local analytics interfaces
test fixtures
golden vectors
metric-definition versioning
analytics provenance / receipts

It may provide libraries/SDKs for platform repos to emit or consume analytics observations.

4. What this repo does NOT own

It does NOT own:

Counterpedia claim standing
source identity authority
ADJ1 / SRC1 / COMP1
Amnesiac memory authority
private user memory storage
Forum governance
recommendation ranking
feed optimization
ad targeting
authentication identity
raw infrastructure log authority
agent identity inference

Analytics may observe these systems.

It does not govern them.

5. Five analytics planes

Plane 1 — Traffic / transport

Simple, legible, old-school metrics:

HTTP requests
page renders/views
API reads
MCP reads
crawler reads
status codes
latency
bytes
cache behavior

Important:

web
API
MCP
crawler
unknown

should be based on observable transport/declaration where possible.

Do not fingerprint a browser to decide it "must be an agent."

Plane 2 — Knowledge interaction

Counterpedia-native actions:

source open
citation follow
claim inspect
Why not? open
refusal inspect
reopening-condition inspect
history open
edition compare
verify action
receipt inspect
reverse traversal
trajectory replay

These describe what users/agents do with the knowledge structure.

Plane 3 — Lattice / graph analytics

Analytics of knowledge objects themselves:

source fan-out
claim dependency depth
source criticality
claim volatility
refusal pressure
unknown pressure
reopening demand
graph traversal depth
edge utilization
edition transition counts
trajectory activity

These may require no person-level identity at all.

Plane 4 — Agent analytics

Agent/MCP/API-specific measurement:

resource type reads
tool/method calls
claim→source traversal
source→dependents traversal
history reads
verify calls
average traversal depth
resource fan-out
machine-readable vs prose usage
declared client class/version
retries / cache patterns

Use declared protocol/client metadata where available.

Do not infer:

• model vendor;

• model family;

• agent owner;

• hidden purpose;

unless explicitly supplied.

Plane 5 — Personal derived analytics

Amnesiac/private:

belief revision
preference acquisition curves
context dependence
revisitability
value drift
forecast calibration
hindsight divergence
confidence-vs-evidence divergence
personal replay usage

Default:

PRIVATE / LOCAL

These should not flow into the central analytics store unless the user explicitly chooses a contribution mode.

6. Observation-first architecture

The canonical mental model:

OBSERVATION
    ↓
NORMALIZATION
    ↓
PRIVACY GATE
    ↓
METRIC DERIVATION
    ↓
SNAPSHOT
    ↓
SURFACE / EXPORT

Raw observation is not metric.

Metric is not verdict.

Metric is not authority.

7. Candidate observation envelope

CANDIDATE ONLY:

{
  "schema": "dagr.analytics.observation/v0.1",
  "event_id": "...",
  "observed_at": "...",
  "platform": "counterpedia",
  "surface": "wiki",
  "action": "source_open",
  "object_ref": "...",
  "transport": "web",
  "session_ref": null,
  "actor_ref": null,
  "privacy_class": "anonymous_aggregate",
  "consent_scope": "site_analytics",
  "context": {}
}

Do not ratify this exact public schema until proving lanes establish field needs.

8. Actor identity discipline

Prefer:

transport_class
declared_client
declared_session

over inferred identity.

Possible actor-state values:

anonymous
session_scoped
authenticated_user
declared_agent
declared_crawler
unknown

Never require a persistent person identifier merely to count page views.

9. Privacy classes

Candidate common privacy classification:

PUBLIC_AGGREGATE
ANONYMOUS_AGGREGATE
SESSION_ONLY
PRIVATE_USER
SENSITIVE_PRIVATE

Every event/metric definition should carry a privacy class.

This must be enforceable in code, not merely documentation.

10. Consent / contribution modes

For private or personal analytics:

LOCAL_ONLY
SHARE_AGGREGATE
SHARE_ANONYMOUS_EVENT
SHARE_EXPLICIT_OBJECT

Default Amnesiac posture:

LOCAL_ONLY

No blanket "share my memory graph."

11. Metric definitions are first-class objects

Every metric should be inspectable.

Conceptually:

metric_id
version
title
description
numerator
denominator
eligible_population
exclusions
window
dedupe_rule
privacy_class
input_event_versions
derivation_version
owner

Example:

page_view/v0.1

must say exactly what counts as a page view.

12. Metric versioning

If the counting rule changes:

page_view/v0.1
→
page_view/v0.2

Do not silently splice historical series.

Charts should mark definition transitions.

13. Three distinct "page hit" metrics

Do not start with one ambiguous counter.

Use separate concepts:

http_request_count
  server request occurred

page_render_count
  page render/load event occurred

page_view_count
  user-visible view under defined dedupe semantics

For MCP:

mcp_resource_read_count
mcp_tool_call_count

For API:

api_object_read_count

This keeps the old-school counter honest.

14. Edge traversal is a first-class event

Counterpedia's most valuable analytics unit may be:

from_object_ref
edge_kind
to_object_ref

Examples:

page → claim
claim → source
source → dependents
claim → why_not
refusal → reopening_condition
page → history
edition_A → edition_B

This lets analytics describe epistemic navigation.

15. Activity never governs knowledge

Hard rule:

Activity may prioritize investigation. Activity may never determine standing.

Therefore:

high views
≠
true

high reopen demand
≠
claim should stand

popular source
≠
authoritative source

popular forum agent
≠
higher epistemic weight

16. Analytics outputs

Three primary sinks:

PUBLIC

Safe aggregates for public pages / /stats.

OPERATOR

Operational/editorial analytics that do not require public exposure.

PRIVATE_LOCAL

Amnesiac/user-owned derived analytics.

No one data warehouse should implicitly collapse all three.

17. Public "Observatory" surface

Possible future public surface:

COUNTERPEDIA TODAY

Web reads
MCP reads
API reads

Sources opened
Verify actions
History opens
Reverse traversals

Then:

MOST READ BY HUMANS
MOST READ BY AGENTS
MOST VERIFIED
MOST REVERSE-TRAVERSED
MOST ACTIVE REFUSALS

And knowledge-state activity:

claims admitted
claims superseded
refusals reopened
new source editions
trajectory events

The surface consumes metrics from this repo.

UI stays in the platform repo unless later centralized deliberately.

18. Forum analytics

Do not optimize likes/dwell time.

Candidate useful outputs:

positions
public basis coverage
sources introduced
shared basis extracted
disagreement dimensions
qualifications
withdrawals
explicit revisions
unresolved issues

Possible bundle:

epistemic_yield

but avoid one magic scalar score.

19. Real trajectory analytics

From the Real Epistemic Response Trajectory corpus:

evidence trajectory
posture trajectory
action trajectory
narrative trajectory

Possible descriptive analytics:

narrative lag
adoption depth
limitation rate
posture/action divergence
evidence/response divergence
trajectory replay count

All definitions must be typed/domain-scoped.

20. Small-cohort protection

Any aggregate that could expose a private participant or rare behavior should support:

minimum cohort threshold
suppression
rounding / bucketing

Differential privacy may be investigated later.

Do not introduce it as ceremony before a use case requires it.

21. Sensitive inference rule

Hard candidate doctrine:

Do not silently derive sensitive personal attributes from activity merely because they are statistically predictable.

Examples not to infer without explicit user-authored state:

religion
political identity
sexual orientation
medical status
relationship status

Personal analytics should describe recorded behavior/state, not manufacture shadow identity.

22. Storage posture

Prefer an append-only event history:

event
event
event

Corrections are new events.

Metric snapshots are derived and replaceable.

A metric snapshot should be reproducible from:

• bounded input event set;

• metric definition;

• derivation version.

23. Receipts

Do not cryptographically sign every click.

Possible useful provenance:

daily bounded event partition
        ↓
aggregate derivation
        ↓
metric snapshot
        ↓
snapshot digest

Enough to make published aggregate provenance inspectable without turning telemetry into SRS spam.

24. Repo shape

dagr-analytics/
├── README.md
├── doctrine/
│   ├── ANALYTICS_CONSTITUTION_CANDIDATE_v0_1.md
│   ├── PRIVACY_CLASSES_CANDIDATE_v0_1.md
│   └── METRIC_VERSIONING_DOCTRINE_CANDIDATE_v0_1.md
│
├── contracts/
│   ├── observations/
│   ├── metrics/
│   ├── privacy/
│   └── snapshots/
│
├── registry/
│   ├── events/
│   └── metrics/
│
├── engine/
│   ├── normalize/
│   ├── privacy/
│   ├── aggregate/
│   ├── derive/
│   └── snapshots/
│
├── lenses/
│   ├── traffic/
│   ├── knowledge-use/
│   ├── graph/
│   ├── agent/
│   ├── forum/
│   └── trajectory/
│
├── platforms/
│   ├── counterpedia/
│   │   ├── events/
│   │   ├── metrics/
│   │   └── batches/
│   ├── amnesiac/
│   │   ├── private/
│   │   ├── metrics/
│   │   └── batches/
│   ├── forum/
│   ├── mcp/
│   └── workbench/
│
├── sinks/
│   ├── public/
│   ├── operator/
│   └── private-local/
│
├── fixtures/
│   ├── synthetic/
│   └── golden/
│
├── tests/
│   ├── contracts/
│   ├── privacy/
│   ├── determinism/
│   ├── metrics/
│   └── integration/
│
└── docs/
    ├── architecture/
    └── batches/

25. Why platforms/ and lenses/ are separate

platforms/ answers:

Where did the activity occur?

lenses/ answers:

What analytical interpretation do we compute?

Example:

platform:
counterpedia

event:
source_open

can feed:

traffic lens
knowledge-use lens
agent lens
graph lens

This prevents Counterpedia-specific directories from becoming the only place cross-platform semantics live.

26. Batch discipline

Each platform can ship bounded batches:

platforms/counterpedia/batches/C1-page-transport-counters-v0-1/
platforms/counterpedia/batches/C2-epistemic-actions-v0-1/
platforms/mcp/batches/M1-resource-reads-v0-1/

A batch should declare:

• input events;

• metric definitions;

• privacy posture;

• storage/retention;

• tests;

• output surfaces;

• non-goals.

27. Recommended first proof

Do not begin with Amnesiac.

Begin with Counterpedia's public web/MCP surface:

C1:
simple transport-aware counters

Then:

C2:
knowledge interaction events

Then:

A1:
agent/MCP paths

This establishes value before touching sensitive data.

28. Naming

Recommended:

repository:
dagr-analytics

public/operator reader surface:
Observatory

internal event noun:
observation

derived output noun:
metric

versioned aggregate:
metric snapshot

Avoid calling raw events:

• signals;

• profiles;

• behavioral scores.

29. One sentence

DAGR Analytics is the measurement substrate for how humans, agents, and knowledge objects interact—privacy-classed, versioned, reproducible, and structurally incapable of turning popularity into authority.