Governance Model
SENEX does not currently operate a public DAO or token-holder governance system. ASHA is simulated and test-only, so it grants no voting rights. Governance work is focused on accountable decision processes for a local-first system under development toward a future V1-testnet.
Governance is the process for deciding what the system may do, who is responsible, how changes are reviewed, and how harmful decisions are corrected. It must cover product, data, security, network, and contribution policies—not only software upgrades.
Status
| Status label | Current meaning |
|---|---|
| Working foundation | Development decisions and controlled testing are managed by the project team. Local owners retain authority over their own AIA configuration and participation. |
| V1-testnet target | Publish versioned operating policies, defined test roles, change notices, incident authority, and feedback or challenge paths for testers. |
| Research direction | Broader representation, delegated responsibility, credible neutrality, and long-term stewardship. |
| External validation required | Security, privacy, legal accountability, conflicts of interest, accessibility, and the effectiveness of appeals. |
Governance layers
Local authority
The owner of an AIA should control local configuration, approved connections, and optional participation within the limits of law and platform safety. Network governance should not silently override a local consent boundary.
Operational governance
Operators need documented responsibility for availability, incident handling, policy enforcement, evidence preservation, and safe upgrades. Their authority should be limited to the role they accepted.
Product and protocol governance
Changes that affect interoperability, data handling, safety, contribution recognition, or shared outcomes require a review path proportionate to their impact.
Independent oversight
High-impact claims—especially about security, privacy, fairness, and economic behavior—require review outside the team that designed them. The form of oversight remains to be determined and must match the deployed risk.
Decision classes
Different decisions should not share one undifferentiated voting mechanism.
- Routine maintenance: compatible changes with limited user impact.
- Material product changes: changes to behavior, permissions, data use, or user expectations.
- Security response: time-sensitive containment with documented scope and retrospective review.
- Network policy: admission, interoperability, service obligations, and enforcement.
- Contribution policy: eligibility, verification, disputes, and test-only recognition.
- Constitutional changes: changes to decision authority, rights, or the governance process itself.
Proposed decision lifecycle
The V1-testnet governance target is a legible process:
- Describe the problem, scope, affected parties, evidence, and alternatives.
- Classify the decision by risk and reversibility.
- Review security, privacy, operational, legal, and user-impact considerations.
- Consult affected participants when the decision is not an emergency.
- Decide through the authority assigned to that decision class.
- Record the rationale, policy version, implementation owner, and review date.
- Deploy with monitoring and a recovery plan appropriate to the risk.
- Evaluate actual outcomes and correct unintended effects.
Exact approval thresholds, internal controls, and emergency procedures are not published while the design is under security review.
Participant rights
Governance should preserve:
- clear notice of material policy changes;
- an understandable record of the rule applied to a consequential decision;
- a channel to report errors, vulnerabilities, or abuse;
- a meaningful review path where a decision can be contested;
- protection against retaliation for good-faith reporting;
- disclosure of material conflicts of interest; and
- an exit path that explains what happens to active obligations and retained records.
These are design goals, not a claim of certification or legal compliance.
Safeguards against capture
Future governance research must address concentration, coordinated influence, voter fatigue, hidden conflicts, inaccessible participation, and emergency powers that become permanent. Token ownership alone is not treated as proof of expertise, legitimacy, or public interest.
The system should prefer limited mandates, transparent reasoning, separation of duties, auditable policy versions, and periodic review of delegated authority. Sensitive security details and personal information should remain protected even when the existence and rationale of a decision are public.
Relationship to V1
V1-testnet would be a test environment, not a source of permanent governance rights. Participation, test records, and simulated ASHA activity would not carry into V1. A future V1 production network would require a fresh governance mandate, fresh operating terms, and evidence from external validation.
Related reading: