PDAS-Core
Core requirements
The minimum disclosure surface for a release-bound public system.
Release identity and canonical scope
The review begins by fixing exactly what is being assessed. Conformance attaches to a defined release object. Securities disclosure theory (Brandeis 1914; Stigler 1964) establishes the foundational principle: mandatory disclosure regimes require that the object of disclosure be precisely defined before disclosure can be evaluated. Without a fixed assessment object, disclosure requirements float free of any specific system state, reproducing the temporal unbinding failure the standard is designed to prevent.
The system MUST designate a canonical documentation root and a canonical manifest root for each assessed release.
The system MUST publish a unique release identifier, effective date, supported networks, and release status for each assessed release.
The system MUST state whether the release is production, limited, experimental, deprecated, or retired.
The system MUST maintain a canonical change log for material release, control, governance, interface, and economic changes.
The system MUST publish canonical identifiers for all material deployed artifacts, including contracts, proxies, implementations, signer-controlled wallets, executors, and offchain services with material authority.
Each material artifact MUST be classified by role, network, status, and lifecycle state.
Control, intervention, and dependency disclosure
The review centers on who can still change the system, stop it, route around it, or quietly depend on something external. Jensen and Meckling's (1976) principal-agent framework identifies why this category requires mandatory rather than voluntary disclosure: agents (protocol operators) have structural incentives to understate the extent of their control, because disclosing control powers undermines the decentralization narrative that supports the system's market position. Mechanism design theory (Hurwicz 1960) confirms that voluntary disclosure regimes are insufficient when agents benefit from non-disclosure.
The system MUST disclose every privileged power that can materially alter behavior, funds, access, parameters, ordering, or governance outcomes.
For each privileged power, the system MUST disclose the holder, execution path, delay or timelock, revocation path if any, and effective scope.
The system MUST explicitly disclose whether upgradeability exists. If no upgradeability exists, that absence MUST be disclosed explicitly.
The system MUST explicitly disclose whether pause, freeze, blacklist, allowlist, seize, mint, burn, redirect, parameter override, or emergency intervention capabilities exist. Absence MUST be explicit.
The system MUST disclose the settlement and finality model in assessable terms, including where finality anchors and what exceptions or reversibility assumptions apply.
The system MUST maintain a dependency and trust register for all material dependencies, including operator identity where known, necessity, failure mode, fallback if any, and trust assumption.
The system MUST disclose any offchain, hosted, proprietary, or committee-based service that is required in practice for normal operation, safe integration, user access, or acceptable performance.
Interfaces, operations, and friction disclosure
APIs, RPC, gRPC, hosted endpoints, maintainer knowledge, and operational asymmetry belong inside the standard. Hutchins's (1995) distributed cognition framework explains why: cognitive work distributes across human actors, software agents, and material artifacts in configurations that evolve over time. Interface and operational disclosure must capture the full distribution of cognitive labor, including the tacit operational knowledge that experienced operators accumulate and that newcomers lack. When that knowledge remains private, it functions as what Williamson (1985) calls asset specificity: the operators who hold it become irreplaceable, and the transaction costs of switching operators exceed the costs of tolerating their governance failures.
The system MUST publish versioned interface references for all material external interfaces, including ABI, JSON-RPC, REST, gRPC/protobuf, GraphQL, event schemas, and supported SDK mappings where applicable.
Each material interface surface MUST disclose versioning policy, compatibility expectations, auth model, deprecation policy, and rate-limit or access policy.
If materially useful functionality depends on paid endpoints, private relays, managed infrastructure, certification tracks, partner programs, or gated support, that dependence MUST be disclosed explicitly.
The system MUST publish operations and maintainer material for every material infrastructure role it introduces, including minimum self-hosting requirements where self-hosting is represented as feasible.
The system MUST identify release authorities, maintainers, code owners, signer roles, and operational accountability boundaries.
The system MUST publish governance disclosure covering proposal rights, approval rights, veto rights, execution rights, emergency bypasses, and any offchain or social coordination dependency that can materially affect outcomes.
The system MUST publish economic disclosure covering user cost surfaces, fee logic, value capture, treasury powers, emissions if any, vesting if any, endpoint pricing if any, and the governance path by which these may change.
The system MUST disclose business-model-critical friction where such friction materially affects access, safe operation, integration quality, or cost.
Assurance, incidents, and freshness
Serious disclosure includes limitations, incident memory, and update discipline. The historical precedent is direct: financial accounting standards (GAAP, IFRS) evolved incident memory requirements because the absence of historical failure records allowed institutions to present each crisis as unprecedented. Environmental reporting under the Toxic Release Inventory (EPA 1986) demonstrated that mandatory incident disclosure changes organizational behavior before regulators act on the disclosed information, because the act of public recording creates reputational incentives that voluntary regimes cannot replicate. Clinical trial registration (ICMJE 2004) extended the principle to medical research: mandatory prospective registration of study designs prevents the selective reporting of favorable outcomes. The same structural logic applies to protocol assurance: without mandatory incident memory and freshness discipline, systems can present selectively favorable assurance postures that obscure their operational history.
The system MUST publish an assurance and evidence index mapping material trust, safety, or performance claims to supporting artifacts.
The system MUST publish known limitations, unresolved risks, scope exclusions, and any area where claims are provisional, partial, or not yet externally validated.
The system MUST maintain a canonical incident and change ledger covering material incidents, emergency actions, migrations, governance interventions, deprecations, and known user-impacting defects.
A material incident MUST receive a preliminary canonical notice within 72 hours of public confirmation or internally confirmed user-impacting discovery. If that deadline is missed, the reason MUST be disclosed.
A material incident MUST receive a fuller canonical ledger entry or postmortem within 30 days, or the system MUST disclose why a fuller account is not yet possible.
A material deployment, control, governance, or interface change MUST be reflected in canonical disclosure no later than its effective date. If immediate synchronization is impossible, the maximum lag MUST be disclosed and justified.
Machine parity and anti-gatekeeping
Public infrastructure requires one material truth across human-readable disclosure, machine-readable disclosure, and public access paths. Merton's (1942) norms of communalism and organized skepticism provide the foundational framework: knowledge produced through shared infrastructure belongs to the community that depends on it, and that community requires the informational basis for independent scrutiny. Dewey's (1927) theory of the public extends the point: effective publics form only when citizens have access to the material facts about conditions that affect them, and restricting access to disclosure about public systems prevents the formation of the informed publics that governance requires.
The system MUST publish a machine-readable manifest family sufficient to express all material facts required by PDAS-Core.
Human-readable and machine-readable canonical disclosures MUST NOT diverge on material facts. Where divergence exists, the system is non-conformant until resolved.
Marketing or summary terms such as decentralized, trustless, secure, scalable, or similar MUST NOT appear as standalone canonical claims. If used, they MUST be decomposed into assessable primitive-backed claims.
Canonical artifacts MUST include a last-reviewed timestamp and a public correction or disclosure-escalation contact path.
Material facts MUST NOT be solely discoverable through conference talks, podcasts, social media, private support, private community channels, sales conversations, or paid training. Such sources are supplemental only.
PDAS-Assurance
Assurance requirements
The draft layer that turns disclosure into scoped claims, evidence, limitations, and outcomes.
Claim structure and decomposition
The assurance layer turns trust claims into scoped, attributable, evidentiary records. Merton's (1942) norms of universalism (claims evaluated by pre-established impersonal criteria) and organized skepticism (claims subjected to systematic scrutiny before acceptance) provide the epistemic framework: every claim enters the assurance layer as provisional and achieves credibility only through evidence, decomposition, and scoping. Timmermans and Epstein (2010) observe that standards achieve authority through the precision of their requirements; vague standards invite gaming while precise standards enable genuine compliance.
The system MUST maintain a canonical assurance claim register for every assessed release.
Every material trust, control, governance, economic, operational, compatibility, or performance claim in canonical artifacts MUST appear in the claim register.
Every material claim MUST be decomposed into assessable statements bound to a subject and scope.
Canonical umbrella terms such as decentralized, trustless, secure, scalable, battle-tested, production-ready, and similar MUST NOT appear as standalone assurance claims. If used, they MUST resolve into claim-register entries.
Every claim MUST identify the release, network, environment, and component scope to which it applies.
Every claim MUST identify its conditions, assumptions, or operational boundaries where such conditions materially affect correctness.
Every claim MUST link to at least one evidence artifact or be marked disclosed_not_verified.
Every claim MUST link to applicable limitations, known unknowns, unresolved issues, or countervailing facts where they exist.
Evidence scope and inheritance
Older evidence does not automatically travel forward. Financial accounting standards (GAAP, IFRS) confronted this problem through the concepts of subsequent events and change-of-estimate accounting: evidence produced at one point in time carries diminishing weight as the system it describes evolves. Formal verification (Lamport 2002) formalizes the same intuition: a proof applies to a specification, and a material change to the specification invalidates the proof unless the change can be shown to preserve the verified properties. The standard needs a rule for when confidence decays and under what conditions prior evidence can be carried forward.
Every evidence artifact MUST be mapped to release scope. Evidence that does not identify what it covers is non-conformant for assurance use.
Evidence inherited from a prior release MUST NOT be treated as current without a public carry-forward analysis describing what changed, what remained unchanged, and why prior evidence still applies.
Claims about privilege absence or presence MUST be backed by direct state evidence, release-mapped source evidence, or both.
Claims about upgradeability, governance execution, pause powers, signer control, treasury control, or emergency intervention MUST disclose the exact execution path and evidence for the current effective state.
Claims about dependencies or trust minimization MUST disclose all material external dependencies and MUST NOT rely on omission as proof of absence.
Claims about API, RPC, gRPC, ABI, schema, or SDK stability MUST identify supported versions, compatibility assumptions, deprecation policy, and evidence for compatibility where compatibility is asserted.
Claims about performance, throughput, latency, low fees, affordability, or scalability MUST disclose methodology, environment, date, workload assumptions, and variance bounds. Unqualified performance claims are non-conformant.
Critical components, audits, and limitations
Critical components are the components whose compromise or opacity would materially change user outcomes. The review names them explicitly and tests their coverage directly. ISO/IEC 27001 provides one precedent for critical-asset identification in information security management: organizations identify assets whose compromise would affect confidentiality, integrity, or availability, then calibrate controls to the asset's criticality. The adaptation for protocol disclosure extends the asset class beyond information to include control surfaces, governance mechanisms, and economic parameters, and extends the consequence class beyond CIA (confidentiality, integrity, availability) to include funds, finality, and governance outcomes.
The system MUST maintain a critical-component inventory covering all components whose failure or compromise could materially affect funds, control, finality, governance, or system-wide availability.
Every critical component MUST have an explicit assurance coverage status.
Absence of known incidents, TVL, market capitalization, ecosystem size, certification status, partner logos, or revenue scale MUST NOT be used as sole evidence for safety, robustness, or operational maturity claims.
Audit claims MUST disclose auditor identity, date, scope, excluded scope, release or commit mapping, unresolved findings, and whether remediations were independently re-reviewed.
Formal verification claims MUST disclose the exact properties checked, the assumptions under which they hold, the covered scope, and anything left unproven.
Test-based claims MUST disclose the relevant test class, coverage scope, and reproducibility path sufficient for public scrutiny.
Every critical limitation or unresolved risk MUST be recorded in a canonical limitations register and linked from affected claims.
Contradictions, freshness, and review provenance
Contradictions change claim status, and stale evidence expires.
Material contradictions across canonical documents, manifests, audits, source mappings, or incident records MUST force affected claims into contradicted status until resolved.
The system MUST publish reviewer provenance for externally reviewed evidence, including reviewer identity and independence classification where available.
Machine-readable assurance records MUST remain materially consistent with human-readable assurance records.
A material incident, governance intervention, or emergency change affecting a claim MUST trigger reassessment of the affected claim status.
Critical claim evidence MUST be marked expired when material system change invalidates prior evidence or when no longer current by profile freshness rules.
The system MUST publish a public correction path for assurance defects, contradictions, and stale claims.
Public interpretability and accountability
Crucial interpretive knowledge stays public, and accountability stays attached to named stewards. Merton's (1942) norm of disinterestedness (institutional controls that ensure claims serve the community rather than the claimant) requires that the connection between claims and claimants be publicly visible. Brunsson and Jacobsson (2000) demonstrate that standards without accountability mechanisms degrade into certification theatre, where conformance signals replace substantive compliance. The attribution requirement ensures that assurance claims carry reputational consequences for their authors.
Material knowledge required to interpret a critical claim MUST NOT be available only through private support, paid programs, partner channels, or informal community memory.
Canonical assurance claims MUST be attributable to a responsible maintainer, team, or governance-recognized authority.
Reference
Claim and evidence tables
These tables define how claims and evidence are represented in the current draft.
| Claim field | Meaning |
|---|---|
| claim_id | Stable unique identifier. |
| claim_type | Control, dependency, governance, security, economic, interface, operational, performance, or historical. |
| statement | Precise claim text. |
| subject | Component, service, or system surface covered by the claim. |
| scope | Release, network, environment, and boundary to which the claim applies. |
| conditions | Assumptions, preconditions, or usage bounds where materially relevant. |
| materiality | Why the claim matters to allocators, auditors, integrators, operators, delegates, or sophisticated users. |
| evidence_refs | Linked artifacts supporting the claim. |
| limitations_refs | Linked unresolved risks, exclusions, or caveats. |
| verifier_type | Self-asserted, externally reviewed, formally proved, directly observable, or mixed. |
| verified_on | Date of verification. |
| expires_on | Expiry date or expiry condition where the claim decays. |
| status | supported, partially_supported, disclosed_not_verified, contradicted, expired, superseded, or not_applicable. |
| Code | Evidence type | Examples |
|---|---|---|
| DS | Direct state evidence | Onchain ownership or admin state, deployed configuration, signer threshold, current control state. |
| SC | Source and release evidence | Tagged source repo, verified source, release artifact, ABI, proto, schema, versioned registry. |
| TS | Test evidence | Reproducible test suites, coverage reports, invariant, fuzz, or property tests. |
| AR | Audit or review evidence | External audits, scoped reviews, formal assessments, and re-review artifacts. |
| FM | Formal methods evidence | Proofs, model checks, property verification outputs, assumptions, and covered scope. |
| GV | Governance evidence | Passed proposals, executor traces, timelock executions, and constitutional change records. |
| IR | Incident evidence | Incident notices, postmortems, remediation records, and public change notices. |
| OP | Operational evidence | Runbooks, infra tests, failover exercises, benchmarks, and methodology notes. |
| PL | Policy and process evidence | Key ceremonies, release procedures, signer process docs, and escalation policies. |
Machine layer
Manifest family and hard failures
The machine layer keeps structured manifests and human-readable disclosure aligned on the same material facts.
| Manifest | Minimum contents |
|---|---|
| pdas.json | Standard version, release identifier, canonical roots, claimed profile, status, and last-reviewed timestamp. |
| release.json | Networks, effective date, superseded release, scoped components, and changelog link. |
| artifacts.json | Material artifact identifiers, roles, addresses or endpoints, networks, lifecycle state, and source links. |
| privileges.json | Power, holder, subject, scope, execution path, delay, revocation path, and evidence references. |
| dependencies.json | Dependency type, operator, necessity, trust assumption, failure mode, fallback, and evidence references. |
| interfaces.json | Interface type, spec location, auth model, compatibility policy, rate limits, and deprecation status. |
| governance.json | Proposal actors, approval actors, veto actors, executors, emergency paths, timelocks, and social dependencies. |
| economics.json | Fee surfaces, pricing logic, emissions, vesting, treasury powers, value-capture destinations, and change authority. |
| assurance.json | Claim register, critical-component inventory, limitations register, evidence catalog, contradictions, and review timestamps. |
| incidents.json | Incident id, date, severity, impacted scope, summary, actions taken, and postmortem references. |
| operations.json | Roles, self-hosting posture, minimum infrastructure requirements, supported clients, and operational caveats. |
Automatic non-conformance
- No canonical release identity or assessed scope.
- No canonical artifact registry.
- No privilege disclosure.
- No dependency and trust register.
- No governance disclosure where governance exists.
- No incident ledger for a materially live system.
- No limitations disclosure.
- No machine-readable manifest set.
- Material contradiction across canonical artifacts.
- Material reliance on gated knowledge.
- Use of summary rhetoric in place of primitive-backed disclosure.
- Assessor findings contradict the system's own canonical claims without disclosure of the discrepancy.
- Canonical artifacts claim conformance without substantive change to prior disclosure posture.