Skip to content

DIA Procedural Reputation Specification

Document Status

Field Value
policy-id DIA-PROC-REP-001
type Implementing act (Level 3 of the normative hierarchy)
version 0.1.0-draft
basis Art. VII.4-5, VII.6, VII.8, XI of the DIA Constitution; REPUTATION-VALIDATION-PROTOCOL.md; ROOT-IDENTITY-AND-NYMS.md; doc/normative/30-core-values/CORE-VALUES.md section "Reputation as Leverage, Not Power"
mechanism status [mechanism - hypothesis] for scoring functions; data model is normative

1. Purpose of the Document

The Constitution requires procedural reputation as a safeguard for trust routing (Art. VII.4), panel eligibility (ENTRENCHMENT-CLAUSE 3.2), and asymmetric accountability (Art. VII.8). However, no specification exists for how procedural reputation is calculated from its sources.

This document defines:

  • reputation domains and signal sources,
  • the scoring model (marked [hypothesis] where unvalidated),
  • the definition of an active node for reputation purposes,
  • the cold-start procedure for new nodes,
  • the relation between procedural reputation and identity-assurance levels,
  • asymmetric accountability for public-trust roles,
  • the portable evidence package for cross-federation mobility,
  • cartel detection hooks,
  • connection to the health metrics M1-M5 of REPUTATION-VALIDATION-PROTOCOL.md.

2. Reputation Domains

Reputation is not a single global number. It is decomposed into four domains, each measuring a different dimension of trustworthiness.

Domain What it measures Constitutional basis
contract Honoring contracts, delivery quality, SLA compliance Art. V.2, XII.2
procedural Panel service, governance participation, COI declarations, protocol compliance Art. VII.4, VII.6
incident Response to incidents, corrections, vulnerability disclosure Art. XVI.4, X.9
community Contributions, mentoring, documentation, onboarding help Art. XII.4, VI.4

Each domain produces a score in [0.0, 1.0], normalized within the federation.

Only the procedural domain qualifies a node for ad-hoc panel selection (ENTRENCHMENT-CLAUSE 3.2: "high procedural reputation, not technical"). Other domains inform trust routing but do not grant governance leverage.

At the same time, procedural reputation does not replace identity assurance. For higher-stakes roles, eligibility requires both the reputation threshold and the appropriate IAL level in accordance with ROOT-IDENTITY-AND-NYMS.md. Here, IAL acts as an eligibility gate, not as a score multiplier.

3. Signal Sources and Types

A reputation signal is a timestamped, evidenced event -- a fact, not an opinion. This follows the Constitution's preference for facts over narrative (Art. XI) and the core values' emphasis on data over state.

3.1. Signal Data Model

reputation_signal:
  signal_id: "[unique identifier]"
  node_id: "[node identifier]"
  federation_id: "[federation]"
  domain: "contract"         # contract | procedural | incident | community
  signal_type: "[specific type]"
  polarity: "positive"       # positive | negative
  weight: 1.0                # base weight before curve application
  evidence_ref: "[reference to auditable evidence]"
  timestamp: "[ISO 8601]"
  source_node_id: "[who generated the signal, if applicable]"
  source_type: "oracle"      # oracle | protocol | peer | self_report
  ttl: "[ISO 8601 expiry]"

3.2. Signal Types per Domain

Domain Positive signals Negative signals
contract contract_fulfilled, quality_verified, sla_met contract_violated, quality_below_threshold, sla_missed
procedural panel_completed, governance_vote_cast, coi_declared, protocol_compliant panel_no_show, coi_undeclared, protocol_violation, governance_inaction
incident incident_reported, correction_applied, vulnerability_disclosed incident_concealed, correction_refused, retaliation
community contribution_accepted, mentoring_verified, documentation_added (absence is not negative -- only active harm generates negative signals)

3.3. Signal Source Credibility

Signals generated by different sources carry different baseline weights:

Source type Description Weight multiplier
oracle Verified by an oracle (outcome measurement) 1.0 (reference)
protocol Generated automatically by protocol compliance checks 0.9
peer Reported by another node 0.7
self_report Reported by the node itself (e.g. COI declaration) 0.5

These multipliers are federation parameters (signal_source_weights). The rule "more cautious yes, more permissive no" applies: a federation may lower but not raise weight multipliers above the defaults.

4. Scoring Model

4.1. Domain Score Calculation [hypothesis]

For each domain, the score is computed from the node's signals within the rolling window:

domain_score = f(sum_positive, sum_negative, signal_count, diversity)

Where:

  • sum_positive = sum of g(weight * source_multiplier * decay_factor) for all positive signals
  • sum_negative = sum of g(weight * source_multiplier * decay_factor * asymmetry_factor) for all negative signals
  • g(x) = sublinear growth function (see 4.2)
  • domain_score = clamp(0.0, 1.0, normalize(sum_positive - sum_negative))

Normalization is relative to the federation's signal distribution, recalculated every measurement_cycle_days.

4.2. Sublinear Growth Curve [hypothesis]

The growth function g(x) MUST be concave to prevent concentration:

g(x) = ln(1 + x) / ln(1 + cap)

The exact function (ln, sqrt, tanh, or other) is a federation parameter (growth_function). The constraint is concavity: g''(x) < 0 for all x > 0.

This ensures diminishing returns: the 100th fulfilled contract contributes less than the 10th.

4.3. Temporal Decay [hypothesis]

Signals decay exponentially within the rolling window:

decay_factor = exp(-lambda * age_days)

Where lambda = ln(2) / half_life_days. Default half-life per domain:

Domain half_life_days Rationale
contract 90 Recent reliability matters most
procedural 120 Governance track record needs longer memory
incident 60 Rapid correction matters
community 180 Long-term contributions decay slowly

Exception: signals tagged continuing_benefit (e.g. maintained infrastructure still in use) retain a minimum decay floor of 0.3 until the benefit ceases.

4.4. Concentration Limits

  1. No single signal type may contribute more than 40% of a domain's positive score.
  2. No single source node may contribute more than 20% of another node's signals in any domain.
  3. Violation of these limits triggers a concentration_warning and caps the excess.

5. Active Node Definition

A node is active for reputation purposes if it meets all of the following:

  1. It has produced at least min_signals_per_period (default: 3) auditable signals within activity_window (default: 90 days).
  2. It responds to federation heartbeats (consistent with FEDERATION-MEMBERSHIP-AND-QUORUM activity criteria).
  3. It is not currently suspended or retired.

Inactive nodes retain their historical scores but cannot use them for governance leverage (voting weight, panel eligibility) until reactivation. Reactivation requires meeting the activity threshold for one full activity_window.

6. Asymmetric Accountability

Nodes holding public-trust roles (Art. VII.8) are subject to stricter standards:

  1. The weight of negative signals is multiplied by asymmetry_factor (default: 1.5).
  2. The weight of positive signals is not reduced -- asymmetry applies only to the downside.
  3. The set of public-trust roles is defined in the future ROLE-REGISTRY document. Until then, the following roles qualify: panel member, federation operator, governance voter with weighted vote, oracle operator.
  4. Asymmetry takes effect immediately upon assuming the role and persists for asymmetry_tail_days (default: 90) after leaving the role.

7. Cold Start and Bootstrap

A new node entering a federation faces the cold-start problem: no signals, no score, no governance access.

7.1. Bootstrap Score

A new node starts with bootstrap_score in each domain, equal to the median of the lowest quartile of active nodes in that domain. This prevents both:

  • zero-score entry barriers (which violate M2 health metric),
  • inflated entry scores (which enable bootstrap exploitation).

7.2. Bootstrap Decay

The bootstrap score decays linearly toward the node's actual earned score over bootstrap_decay_period (default: 90 days):

effective_score = actual_score + max(0, bootstrap_remaining) * (bootstrap_score - actual_score)
bootstrap_remaining = 1 - (days_since_join / bootstrap_decay_period)

7.3. Bootstrap Governance Restrictions

A node in the bootstrap period (bootstrap_remaining > 0) cannot:

  • be selected for ad-hoc panels,
  • cast weighted votes (equal vote only),
  • hold public-trust roles.

These restrictions ensure that governance leverage requires actual earned procedural reputation.

7.4. Identity-Assurance Gate

  1. High procedural reputation does not, by itself, grant access to high-trust roles.

  2. A federation MUST evaluate eligibility as the conjunction of two conditions:

  3. reputation threshold,

  4. minimum IAL level for the given role or procedure.

  5. For ad-hoc panels, federation operators, oracles, and similar roles, the system SHOULD store a snapshot of the current assurance_level in the reputation record.

7.5. Slight Fixed Leverage for Higher IAL Levels

  1. A federation MUST NOT multiply a reputation score by the IAL level.

  2. A federation MAY grant a node with a higher IAL a small fixed procedural bonus (fixed_power_bonus), but only when:

  3. the bonus is explicitly described in federation policy,

  4. it does not exceed 0.01 (1%) of the total power of the given mechanism,

  5. it does not replace the reputation threshold or domain thresholds,

  6. it is auditable and revoked together with the loss of IAL eligibility.

8. Portable Evidence Package

Reputation is federation-local, but nodes may move between federations. Portability is achieved through a portable evidence package, not a naked score.

8.1. Package Contents

reputation_export_package:
  node_id: "[node identifier]"
  source_federation_id: "[federation that generated the package]"
  exported_at: "[ISO 8601]"
  package_signature: "[cryptographic signature of the source federation]"
  signal_history:
    - signal_id: "[...]"
      domain: "[...]"
      signal_type: "[...]"
      polarity: "[...]"
      weight: "[...]"
      evidence_ref: "[...]"
      timestamp: "[...]"
      source_type: "[...]"
  attestations:
    - type: "panel_service"
      description: "[...]"
      issued_by: "[federation or panel identifier]"
      date: "[...]"
    - type: "sanction_served"
      description: "[...]"
      issued_by: "[...]"
      date: "[...]"
  appeals_history: []
  sanctions_history: []
  repairs_history: []
  roles_held: []

8.2. Receiving Federation Behavior

The receiving federation:

  1. Imports the signal history as evidence.
  2. Re-scores the node using its own parameters (growth function, decay, thresholds).
  3. Does not accept the source federation's score as its own.
  4. May apply a foreign_signal_discount (default: 0.8) to imported signals, reflecting reduced verifiability.
  5. Treats the imported package as a faster cold start, not a reputation transfer.

9. Cartel Detection Hooks

9.1. Mutual Boosting Detection

The system MUST flag pairs or groups of nodes where:

  • mutual positive signals exceed mutual_boost_threshold (default: 30% of each node's positive signals come from the other),
  • signals are temporally clustered (within cluster_window, default: 48 hours).

Flagged patterns generate a cartel_flag on the affected nodes and trigger review.

9.2. Closed-Group Flow Detection

The system MUST detect closed groups where reputation signals circulate predominantly within the group:

  • intra-group signal share > closed_group_threshold (default: 60%),
  • group size < max_cartel_group_size (default: 10 nodes).

9.3. Source Diversity Requirement

For a signal to contribute its full weight, the node must have signals from at least min_source_diversity (default: 5) distinct source nodes in the same domain within the rolling window. Below this threshold, signal weight is reduced proportionally.

10. Reputation Record Data Model

reputation_record:
  node_id: "[node identifier]"
  federation_id: "[federation]"
  snapshot_at: "[ISO 8601]"
  status: "active"             # active | inactive | bootstrapping | suspended
  identity_assurance_level: "IAL0"
  identity_anchor_ref: null
  fixed_power_bonus: 0.0
  domains:
    contract:
      score: 0.0               # [0.0, 1.0]
      signal_count: 0
      positive_sum: 0.0
      negative_sum: 0.0
      last_signal_at: "[ISO 8601]"
    procedural:
      score: 0.0
      signal_count: 0
      positive_sum: 0.0
      negative_sum: 0.0
      last_signal_at: "[ISO 8601]"
    incident:
      score: 0.0
      signal_count: 0
      positive_sum: 0.0
      negative_sum: 0.0
      last_signal_at: "[ISO 8601]"
    community:
      score: 0.0
      signal_count: 0
      positive_sum: 0.0
      negative_sum: 0.0
      last_signal_at: "[ISO 8601]"
  roles: []                    # current roles for asymmetry calculation
  bootstrap_remaining_days: 0
  cartel_flags: []
  concentration_warnings: []

11. Connection to Health Metrics (M1-M5)

This specification provides the data that REPUTATION-VALIDATION-PROTOCOL metrics consume:

Metric Data source from this spec
M1 (Gini) Distribution of domain_score across all active nodes
M2 (Time to influence) Time from first signal to reaching panel_procedural_threshold
M3 (Cartel detection) cartel_flag count relative to total signals
M4 (Reputation-quality correlation) Correlation between contract.score and oracle-verified outcomes
M5 (Top-layer rotation) Entry/exit of nodes in the top decile of procedural.score

12. Failure Modes and Mitigations

Failure mode Mitigation
Gaming via volume of trivial signals Minimum significance threshold per signal type; diminishing returns via sublinear curve; concentration limits (section 4.4)
Sybil attack via mutual signals Cartel detection hooks (section 9); source diversity requirement
Cheap reputation without strong identity anchoring Shared gate: reputation + IAL; high-stakes roles require both conditions
Bootstrap exploitation bootstrap_min_age restriction; procedural domain requires actual panel service
Decay punishes long-term contributors continuing_benefit exception; community domain has slowest decay
Asymmetry weaponized against public-trust holders Asymmetry applies only to negative signals; appeals process unchanged
Score opacity erodes trust Every score is decomposable: node can request full signal history and weight breakdown
Reputation shopping across federations Portable evidence package, not portable score; receiving federation re-scores locally

13. Federation Parameters

Parameter Default Allowed range Rule
growth_function ln ln, sqrt, tanh Must be concave
decay_half_life_contract 90 days >= 60 days More cautious yes, more permissive no
decay_half_life_procedural 120 days >= 90 days "
decay_half_life_incident 60 days >= 45 days "
decay_half_life_community 180 days >= 120 days "
activity_window 90 days >= 60 days "
min_signals_per_period 3 >= 2 "
bootstrap_decay_period 90 days >= 60 days "
asymmetry_factor 1.5 >= 1.2 "
asymmetry_tail_days 90 days >= 60 days "
panel_procedural_threshold 0.6 >= 0.5 "
mutual_boost_threshold 30% <= 30% "
closed_group_threshold 60% <= 60% "
min_source_diversity 5 >= 3 "
foreign_signal_discount 0.8 [0.5, 1.0] "
concentration_cap_per_type 40% <= 40% "
concentration_cap_per_source 20% <= 20% "

14. Open Questions

  1. Exact sublinear function: ln, sqrt, or tanh? Needs simulation (Phase 0 of REPUTATION-VALIDATION-PROTOCOL). Currently a federation parameter.

  2. Negative scores: Should the incident domain allow scores below 0.0 (i.e. [-1.0, 1.0]) to capture "net harmful"? Current design: scores are [0.0, 1.0].

  3. Oracle signal weighting: Should oracle-generated signals receive a higher weight multiplier than 1.0? Argument for: they are outcome-verified. Argument against: oracle trust is itself a variable.

  4. Role registry: Asymmetric accountability depends on a list of public-trust roles. Until ROLE-REGISTRY is written, the interim list in section 6.3 applies.

  5. Cross-domain interaction: Should severe negative signals in incident affect the procedural domain? Current design: domains are independent. Argument for cross-contamination: a node concealing incidents should not serve on panels.

15. Relation to Other Documents

  • Constitution Art. VII.4-5: This document operationalizes reputation as domain-specific, decaying, concentration-limited, and cartel-resistant.
  • REPUTATION-VALIDATION-PROTOCOL.md: Provides the health metrics (M1-M5) that measure whether this specification works as intended. Scoring functions marked [hypothesis] remain subject to the validation flow defined there.
  • ENTRENCHMENT-CLAUSE.md: The procedural domain score is the eligibility criterion for ad-hoc panel selection.
  • ROOT-IDENTITY-AND-NYMS.md: Procedural reputation is calculated separately, but for high-stakes roles it works together with the IAL level; many nyms from one anchor source may not multiply influence without an additional procedure.
  • PANEL-SELECTION-PROTOCOL.md: Uses panel_procedural_threshold from this specification.
  • EXCEPTION-POLICY.md: Exception-related signals (both creating and handling exceptions properly) feed into the procedural and incident domains.
  • FEDERATION-MEMBERSHIP-AND-QUORUM.md: The active status definition here is consistent with federation activity criteria.
  • AUTONOMY-LEVELS.md: A3 post-crisis review results feed into the procedural and incident domains.
  • ABUSE-DISCLOSURE-PROTOCOL.md: Disclosure outcomes feed into the incident domain.
  • NORMATIVE-HIERARCHY.md: This document is a Level 3 implementing act.