PDAS-Core
Core requirements
The minimum disclosure surface for a release-bound public system.
Release identity and canonical scope
Fix the release, networks, effective configuration, and material artifacts being assessed. This is a reproducibility requirement proposed for PDAS: reviewers need a defined object before comparing claims with evidence.
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
Name who can change behavior, stop operations, move funds, or alter governance outcomes, and identify material external dependencies. These powers matter to reliance whether or not an operator has an incentive to conceal them. The disclosure requirement is the proposal’s policy choice.
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
Include interfaces, hosted endpoints, maintainer responsibilities, and operational dependencies. Hutchins (1995, introduction) studies cognition distributed across people and artifacts. This helps frame operational knowledge as part of a working arrangement. PDAS proposes disclosing the requirements needed to operate or integrate with that arrangement; it does not assume that all tacit knowledge can be codified or that experienced operators are irreplaceable.
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
Publish limitations, incident history, and the changes affecting assurance. Two precedents illustrate different disclosure functions: EPA’s Toxics Release Inventory records annual chemical releases and waste-management information under a program created by the 1986 EPCRA; the first reports covered 1987 and were due in 1988 (U.S. EPA n.d.). It is not a general incident register. Clinical-trial registration makes a planned study record available for comparison with later reporting (De Angelis et al. 2004). Registration does not guarantee the prevention of selective reporting. PDAS adapts the record-and-comparison idea to release and incident history. Its 72-hour and 30-day deadlines below are proposed targets needing operational review.
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
Human-readable disclosure and machine-readable manifests should agree on material facts. Under PDAS, public reliance also requires a public route to those facts. These are proposed obligations with privacy, security, and implementation questions to resolve; scientific norms do not by themselves establish a universal ownership or disclosure rule for public infrastructure.
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 assurance layer that turns disclosure into scoped claims, evidence, limitations, and outcomes.
Claim structure and decomposition
Make assurance claims attributable and specific enough to assess. Exact clauses support consistent checking, but precision alone does not establish substantive compliance. Timmermans and Epstein (2010, abstract) describe standardization as a social process with varied effects, difficulties, and unintended consequences. PDAS needs empirical review of how its categories are interpreted and used.
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
Prior evidence may remain relevant after a release changes, but its applicability must be argued. Lamport (2002, chaps. 2–3) distinguishes a system’s specification from the behaviors it describes. A proof or model check concerns stated properties under stated assumptions. A later implementation or specification change requires an analysis of what remains covered, rather than an automatic claim that all prior proof has become invalid.
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
Name the components whose compromise or opacity could materially affect funds, control, finality, governance, or availability. For each, record what was assessed, by whom, against which release, and what remains uncovered. This is the proposed critical-component method; its completeness requires domain review.
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
Attach claims to responsible stewards and keep the information necessary to interpret them publicly available. Attribution makes a correction request addressable; it does not guarantee independence, reputational consequences, or substantive compliance. Those require separate review and governance arrangements.
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.
| 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 while requirements of the claimed profile remain unmet.
References
These works inform the design discussion. PDAS’s clauses, categories, and deadlines are proposals; the cited literature does not validate their effectiveness. Edition and passage notes identify the material consulted.
- Bowker, Geoffrey C., and Susan Leigh Star. 1999. Sorting Things Out: Classification and Its Consequences. Cambridge, MA: MIT Press. Introduction consulted. Source.
- De Angelis, Catherine, Jeffrey M. Drazen, Frank A. Frizelle, Charlotte Haug, John Hoey, Richard Horton, Sheldon Kotzin, Christine Laine, Ana Marušić, A. John P. M. Overbeke, Torben V. Schroeder, Harold C. Sox, and Martin B. Van Der Weyden. 2004. “Clinical Trial Registration: A Statement from the International Committee of Medical Journal Editors.” Annals of Internal Medicine 141 (6): 477–78. Joint editorial; the ICMJE-hosted statement is the consulted version. Source.
- Hutchins, Edwin. 1995. Cognition in the Wild. Cambridge, MA: MIT Press. Introduction consulted. Source.
- Jasanoff, Sheila, ed. 2004. States of Knowledge: The Co-production of Science and Social Order. London: Routledge. Introduction, “The Idiom of Co-production,” 1–12. Source.
- Lamport, Leslie. 2002. Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers. Boston: Addison-Wesley. Chapters 2–3. Source.
- Meyer, Bertrand. 1992. “Applying ‘Design by Contract’.” Computer 25 (10): 40–51. Source.
- North, Douglass C. 1990. Institutions, Institutional Change and Economic Performance. Cambridge: Cambridge University Press. Pages 3–10. Source.
- Ostrom, Elinor. 1990. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge: Cambridge University Press. Chapter 1 consulted in the publisher’s 2015 reissue excerpt. Source.
- Star, Susan Leigh, and James R. Griesemer. 1989. “Institutional Ecology, ‘Translations’ and Boundary Objects: Amateurs and Professionals in Berkeley’s Museum of Vertebrate Zoology, 1907–39.” Social Studies of Science 19 (3): 387–420. Source.
- Timmermans, Stefan, and Steven Epstein. 2010. “A World of Standards but Not a Standard World: Toward a Sociology of Standards and Standardization.” Annual Review of Sociology 36: 69–89. Abstract consulted. Source.
- Toulmin, Stephen E. 2003. The Uses of Argument. Updated ed. Cambridge: Cambridge University Press. Originally published 1958. Pages 89–100 of chapter 3 consulted. Source.
- TSC Industries, Inc. v. Northway, Inc. 1976. 426 U.S. 438. Supreme Court of the United States. Materiality discussion at 449. Source.
- U.S. Environmental Protection Agency. n.d. “History of the Toxics Release Inventory (TRI) Program.” Accessed October 18, 2026. Source.