Rights & Abuse Analysis
A system that gates political capability by a computed score is a real power structure with real failure modes. Answered honestly, not reassuringly — most rows below are open problems, not solved ones. A risk is only ever marked resolved once a safeguard actually exists, is tested, and covers the canonical execution path — not because a document proposes one.
| Question | Current answer | Status | Deployment consequence |
|---|---|---|---|
| Who defines the score? | Initial dimensions, weights and thresholds were authored by the project maintainer. They have not been approved by an independent community, standards body, or democratic process. | Unresolved | Blocks legitimate civic use |
| Can a score be appealed? | No complete public process exists | Missing | Blocks deployment |
| Can rules change retroactively? | Needs an explicit prohibition and formula/weight versioning; not yet specified | Open | High risk |
| Is participation anonymous? | Not guaranteed — identity binding (DID) is integral to the current design | Partial | Requires its own threat model before relying on it |
| Are Guardian powers constrained? | No approved, complete mechanism (scope/quorum/duration/audit/revocation/appeal all unspecified) | Missing | Must remain disabled / unimplemented |
| Is the profile scientifically validated? | No | Not validated; consciousness-measure interpretation rejected | Must not be described as a consciousness measurement |
| Can collusion or capture alter outcomes? | Sybil-resistance is a stated goal, not a demonstrated property. See the disclosed defect class below. | Open | Results are not authoritative |
| Can users leave or fork? | Data export, exit, and constitutional-fork rights need explicit specification — not yet written down | Needs specification | A required sovereignty property, currently missing |
A known authorization-binding defect class could permit actions to be attributed to the wrong agent under affected code paths (DHT entries not cryptographically bound to the real acting agent). Until the relevant invariant is repaired and independently tested on a given path, any governance-relevant result on that path must not be treated as trustworthy.
Scope, honestly bounded: this defect class has been found and mostly fixed across this codebase, tracked cluster-by-cluster. The Governance cluster's threshold-signing piece is confirmed still open (blocked on an external dependency); the rest of the Governance cluster's status hasn't been independently reconciled for this page. Don't infer "affects everything" or "already fixed everywhere."
SECURITY_STATUS.md — the canonical, maintained, cluster-by-cluster remediation record. No request payloads, bypass sequences, or exploitation steps are published there or here; that level of detail belongs in coordinated security documentation once remediation is confirmed, not on a public page.
Why anyone should trust this with real governance authority: right now, they shouldn't — not yet. The honest pitch is real code, real tests, a real (if unfinished) attempt to think through failure modes before deployment, and a policy of disclosing gaps rather than smoothing over them. That's a reason to watch this project, not a reason to hand it authority today.
Security Posture
Threat model
No formal, published threat model exists for the governance mechanisms yet — the disclosed defect class above is the most concrete finding to date. Individual clusters vary in how far their own validation logic has been reviewed; see SECURITY_STATUS.md.
Supported / unsupported use
Supported: local development, protocol research, code review, reproduction of stated claims. Not supported: any deployment affecting real people's governance rights, finances, health, or legal status.
Vulnerability disclosure
GitHub private vulnerability reporting is enabled on this org's active repositories. See the org-wide security policy for target response times and scope. Do not open a public issue for an unfixed vulnerability.
Audit status
Internal only. No independent third-party security review has been performed on any Mycelix cluster as of this page's last-reviewed date (footer).
What would have to be true before real-world use
A concrete research roadmap, not a generic "not ready yet" disclaimer:
- Canonical end-to-end multi-agent tests, not just unit tests
- Author-binding invariant fully closed, independently tested, across all clusters
- A published, formal threat model
- An independent (non-self) security assessment
- Sybil and collusion testing
- Appeals and remedies actually implemented, not just specified
- An accessible participation study
- A community-controlled parameter-change process
- A privacy impact assessment
- Legal review for the intended jurisdiction
- Adversarial simulation
- A limited, opt-in pilot before any general deployment
- A published incident-response plan