Trust direction

The principle

Trust flows in one direction. Cycles (entity A trusts B trusts C trusts A) create governance and security pathologies. The architecture does not build cycles.

The trust hierarchy

              Methodology code (open source, audited)
                              │
                              ▼
              Layer 3 attestations (attestation receipts)
                              │
                ┌─────────────┼─────────────┐
                ▼                           ▼
         Layer 2 (DAO/LLC)              Registry
                                            │
                                            ▼
                                      Earth Credit buyers
                                            │
                                            ▼
                                Exchange (when built)
                                            │
                                            ▼
                              Institutional Fund (when built)

Each entity trusts only what is below it (closer to the methodology). The methodology is the truth source; everything else relies on its outputs.

Why one-way trust matters

Cycles produce subtle but catastrophic pathologies:

Cycle pattern	Pathology
DAO trusts Fund trusts Exchange trusts DAO	Fund’s investors are exposed to DAO governance failures; DAO governance is influenced by Fund’s incentives; mutual trust collapses to mutual dependency
Methodology trusts registry trusts methodology	Methodology updates can be manipulated by registry-side incentives; truth source is corrupted
Earth Pulse Network trusts methodology trusts Earth Pulse Network	Sensor data is filtered through methodology that depends on the same sensors; bias is amplified

The architecture’s response: methodology is the apex; nothing trusts it back. Registry trusts methodology; methodology does not trust registry. DAO trusts attestations; attestations do not depend on DAO state. And so on.

What each entity trusts

Layer 3 — Methodology

• Trusts: peer-reviewed scientific consensus, open-source audited code, validation data
• Does NOT trust: any specific Layer 2 entity, any coalition entity, any individual stakeholder

Layer 3 — Attestations (attestation receipts)

• Trusts: cryptographic primitives, methodology version pinning
• Does NOT trust: registry decisions about credit issuance (those happen later)

Layer 3 — Registry

• Trusts: methodology attestations (attestation receipts)
• Does NOT trust: buyer demands, exchange pressure, DAO requests for special issuance

Layer 2 — DAO/LLC

• Trusts: methodology attestations consumed via attestation hooks; registry’s recorded credit issuance and sale events
• Does NOT trust: other DAOs/LLCs, coalition entities’ demands

Earth Credit buyers (and Exchange when built)

• Trust: registry’s issued credits
• Do NOT trust: DAO governance decisions, coalition entity statements

Institutional Fund (when built)

• Trusts: Earth Credits as commodity
• Does NOT trust: any individual DAO’s governance

Cross-entity transfers — all cryptographically attested

Any cross-entity transfer (money, credits, attestations) is recorded as a cryptographically attested event. End-to-end traceability:

Transfer	attestation anchor
Methodology output → registry	Methodology version + measurement data hashed and signed
Registry → buyer (credit sale)	Issuance event; sale event with buyer identity
Buyer → Exchange (listing)	Listing event
Exchange → buyer (purchase)	Purchase event
Buyer → DAO treasury (revenue routing)	Revenue routing event with reference to specific credit

Anyone can trace a buyer’s payment back to a specific measurement event under a specific methodology version. This is the assay-office structure: independent verifiability of the chain of custody.

What this enables

Capability	Mechanism
Public verifiability of credit issuance	Anyone can verify the registry issued credits against attested condition
Public verifiability of revenue routing	Anyone can verify a property’s revenue flows match the credit sales
Public verifiability of methodology integrity	Anyone can verify methodology version matches what was attested
Audit trail across entity boundaries	Any cross-entity transaction has a cryptographically attested record

This is the assay function: independent, end-to-end verification. The architecture is not asking anyone to trust Landseed; it is providing the cryptographic chain that lets anyone verify.

What this prevents

Risk	Prevention
Landseed inflates credit issuance	Issuance is anchored to attestations; inflation is detectable
Buyer claims credits not issued	Issuance events are public-verifiable
DAO governance manipulates measurements	Attestations are independently sourced; DAO consumes, doesn’t generate
Coalition entity inserts itself into trust chain	New entities must follow trust direction; cycles rejected

Integrity rules

The interface integrity rules are detailed in 03-integrity-rules.md. The core rules:

1. One-way trust: every interface follows the hierarchy
2. cryptographically attested events: cross-entity transfers are recorded
3. Bright lines hold across coalition entities: the perimeter applies universally
4. New entities require interface specification: no entity is added without spec + perimeter analysis

What changes if the methodology layer changes

The methodology is the apex of the trust hierarchy. If the methodology layer changes:

• Registry must be updated to consume new methodology version
• DAOs/LLCs must ratify the new version (or remain on prior version)
• Buyer-side communications must be updated
• Fund’s investment thesis may shift

Methodology changes propagate downward; nothing in the chain pushes back to the methodology layer.

What if a downstream entity provides feedback to the methodology

Important nuance: methodology stewards do listen to downstream entities (DAOs, registry, Earth Pulse Network, buyers). But this is input to methodology governance, not part of the trust chain. The methodology stewards make decisions independently; downstream feedback is one of many inputs.

This is consistent with the assay-office model: the assayer can listen to industry concerns, but the assay results are not subject to industry pressure.

When trust direction is violated

If a proposed feature, coalition entity, or operational practice would create a trust cycle:

• The proposal is rejected, or
• The cycle is broken by restructuring, or
• Escalation to Alex + the co-architect

Trust cycles are an architecture-level failure mode. They are not “operational problems” to be managed; they are structural defects to be avoided.