Transparency, Records, and Conflicts
Draft 0.1 — 2 August 2026
Transparency must coexist with privacy, security, legal privilege, and legitimate business confidentiality. Public by default does not mean public without judgment.
Objective
Section titled “Objective”ANUKA governance should be inspectable enough that participants can understand:
- which rule applies;
- who has authority;
- how a decision was reached;
- who funded or influenced it;
- what objections remain;
- what was implemented;
- how the outcome will be reviewed.
The core rule is:
Public authority requires durable records; confidential authority requires a recorded reason and later review.
Public-by-default records
Section titled “Public-by-default records”The following should normally be public:
- Foundation documents;
- shared protocols;
- council charters;
- active role and delegation registry;
- proposals;
- decision records;
- formal objections and responses;
- constitutional amendments;
- shared budgets and public treasury reports;
- resident-product charters;
- conformance criteria;
- public conflicts of interest;
- material emergency-action summaries;
- release and implementation status;
- source registries;
- governance health reports.
Legitimate confidential records
Section titled “Legitimate confidential records”Confidentiality may be necessary for:
- personal data;
- authentication secrets;
- active vulnerabilities;
- incident details that would increase harm;
- attorney-client privileged communications;
- litigation strategy;
- confidential customer data;
- trade secrets;
- acquisition or financing negotiations;
- personnel and employment matters;
- protected whistleblower reports;
- sanctions and fraud investigations;
- confidential contract terms.
The existence of a confidential record or decision should still be logged when safe and lawful.
Confidentiality classes
Section titled “Confidentiality classes”C0 — Public
Section titled “C0 — Public”Accessible without authentication.
C1 — Network participant
Section titled “C1 — Network participant”Accessible to authenticated participants or affected groups.
C2 — Role restricted
Section titled “C2 — Role restricted”Accessible to specific councils, reviewers, responders, or product roles.
C3 — Legally or security restricted
Section titled “C3 — Legally or security restricted”Accessible only to authorized legal, security, privacy, financial, or executive personnel.
C4 — Privileged or sealed
Section titled “C4 — Privileged or sealed”Highly restricted due to legal privilege, court order, investigation, or critical security reason.
Every restricted record should identify:
- classification;
- owner;
- reason;
- access policy;
- creation time;
- retention;
- review or declassification date;
- disclosure obligations.
Decision transparency
Section titled “Decision transparency”A public decision record should contain:
- decision ID;
- title;
- decision class;
- responsible body;
- authority basis;
- date;
- participants;
- conflicts and recusals;
- proposal version;
- evidence;
- alternatives;
- objections;
- decision method;
- outcome;
- implementation owner;
- review or sunset date.
When details are confidential, publish a scoped summary such as:
The Security Council temporarily suspended one credential issuer after evidence of key compromise. Technical exploit details remain restricted during remediation. Review is due 9 August 2026.
Meeting discipline
Section titled “Meeting discipline”A governance meeting should have:
- published purpose;
- agenda;
- participants;
- declared decision authority;
- relevant documents;
- conflict check;
- notes or minutes;
- action owners;
- decisions and objections;
- next review.
Meetings must not become a way to bypass asynchronous review.
A decision made in a meeting should be published in the durable decision system.
Asynchronous-first governance
Section titled “Asynchronous-first governance”ANUKA should prefer asynchronous records because they:
- support global participation;
- create archives;
- allow careful review;
- reduce dominance by fast speakers;
- support accessibility and translation;
- let AI tools summarize without becoming the authority;
- preserve institutional memory.
Synchronous meetings remain useful for negotiation, incident response, and complex discussion.
Minutes
Section titled “Minutes”Minutes should record:
- date and duration;
- attendees and roles;
- absences when required;
- agenda items;
- evidence considered;
- conflicts;
- major viewpoints;
- decisions;
- votes or consensus calls;
- objections;
- action items;
- deadlines.
Minutes are not transcripts unless explicitly stated.
Corrections should preserve version history.
Private meetings
Section titled “Private meetings”A private meeting requires a reason such as:
- security;
- personal data;
- legal privilege;
- personnel;
- commercial negotiation;
- active fraud investigation.
The public log should record:
- that the meeting occurred;
- responsible body;
- general category;
- whether a decision was made;
- when a public summary is expected.
Private meetings must not be used for ordinary technical or policy direction that should be public.
Conflict-of-interest policy
Section titled “Conflict-of-interest policy”A conflict may arise from:
- employment;
- investment;
- product ownership;
- customer or vendor relationship;
- sponsorship;
- family or close personal relationship;
- litigation;
- political or governmental role;
- competing product;
- pending payment or bounty;
- personal grievance.
A conflict can be actual, potential, or reasonably perceived.
Disclosure record
Section titled “Disclosure record”Role holders should disclose material interests relevant to their scope.
Suggested fields:
person: participant:anuka:123role: Treasury Council Memberinterests: - type: employer entity: Example Payments Inc. - type: investment entity: Resident Product A materiality: non-controllingupdated_at: 2026-08-02Sensitive financial details may remain private while the relevant relationship is disclosed.
Matter-specific conflict check
Section titled “Matter-specific conflict check”Before a material decision, participants should answer:
- do I or a close relation receive direct financial benefit;
- does my employer or investment benefit;
- am I a party to the dispute;
- did I create the evidence under review;
- do I have authority in both proposing and reviewing roles;
- could a reasonable participant question my independence.
Conflict responses
Section titled “Conflict responses”Possible responses:
- disclose and participate;
- disclose and abstain from vote;
- recuse from discussion and vote;
- assign independent reviewer;
- narrow access;
- create a special committee;
- remove from role;
- terminate a conflicting vendor or contract.
The response should match the risk.
Recusal record
Section titled “Recusal record”A recusal record should identify:
- matter;
- conflicted participant;
- conflict category;
- scope of recusal;
- replacement decision-maker;
- whether confidential details exist.
Recusal must be real. A person should not privately direct the decision after publicly recusing.
Sponsorship and lobbying transparency
Section titled “Sponsorship and lobbying transparency”Material advocacy should disclose:
- sponsor;
- financial or in-kind support;
- proposal or policy affected;
- contract or expected benefit;
- paid representatives;
- timing.
ANUKA should not prohibit advocacy, but hidden influence undermines governance legitimacy.
AI-generated lobbying or mass comments must identify the accountable principal.
Repository governance records
Section titled “Repository governance records”GitHub repositories should expose:
- maintainers;
- CODEOWNERS;
- branch rulesets;
- required reviews;
- required status checks;
- release process;
- security policy;
- contribution policy;
- decision links for governance-sensitive changes.
GitHub rulesets can require pull requests, status checks, code scanning, and protection from force pushes. CODEOWNERS can require review from responsible domain owners.
Protection of governance files
Section titled “Protection of governance files”High-impact files should have explicit code owners and stronger merge rules.
Examples:
- Constitution;
- governance protocols;
- CODEOWNERS itself;
- CI workflows;
- deployment configuration;
- security policy;
- schema registries;
- payment and authorization policy;
- trademark and licensing files.
Protecting CODEOWNERS is particularly important because control over that file can redefine who approves changes.
Audit trail
Section titled “Audit trail”Material systems should record:
- actor;
- action;
- target;
- time;
- authority grant;
- authentication level;
- previous and new value;
- approval chain;
- source IP or device context where appropriate;
- linked incident or proposal;
- result.
Audit logs must be access-controlled and privacy-aware.
An audit log is evidence, not automatic proof of legitimate authority.
Record integrity
Section titled “Record integrity”Controls may include:
- version control;
- signed commits and releases;
- append-only logs;
- hashes;
- trusted timestamps;
- redundant archives;
- provider records;
- offsite backups;
- attestation of selected decision artifacts.
Do not put sensitive records on a permanent public blockchain merely to claim transparency.
Retention
Section titled “Retention”Retention should differ by record type.
Suggested direction:
| Record | Direction |
|---|---|
| Constitution and ratified protocols | permanent archive |
| public decisions | permanent or long-term archive |
| role grants | term plus long-term history |
| conflicts and recusals | role term plus legal retention |
| meeting recordings | short retention unless required |
| minutes | long-term |
| incident evidence | risk and legal based |
| personal applications | limited retention |
| payment and tax records | legal/accounting retention |
| authentication logs | security-based limited retention |
Retention must not become keep everything forever.
Corrections
Section titled “Corrections”A correction should:
- identify original record;
- explain error;
- identify correct information;
- record who approved correction;
- preserve history when appropriate;
- update derived scores or decisions;
- notify affected relying parties where material.
Corrections must not silently rewrite politically inconvenient history.
Whistleblower and protected reporting
Section titled “Whistleblower and protected reporting”ANUKA should provide a route for confidential good-faith reports concerning:
- fraud;
- security;
- harassment;
- retaliation;
- conflicts;
- misuse of funds;
- false evidence;
- privacy violations;
- legal noncompliance.
The process should define:
- recipient;
- confidentiality;
- anti-retaliation;
- triage;
- conflict handling;
- investigation authority;
- outcome communication;
- record retention.
The network must not promise anonymity it cannot technically or legally guarantee.
Public accountability report
Section titled “Public accountability report”At least annually during the founding phase, ANUKA should publish:
- governance bodies and role holders;
- major decisions;
- constitutional changes;
- active delegations;
- proposal and appeal metrics;
- conflict disclosures and recusals;
- emergency actions;
- treasury summary;
- resident-product status changes;
- unresolved corrective actions;
- governance concentration analysis.
Privacy and transparency balance
Section titled “Privacy and transparency balance”Transparency does not justify publishing:
- exact home addresses;
- government identifiers;
- personal financial details;
- private health information;
- confidential employee records;
- authentication secrets;
- sensitive security logs;
- raw whistleblower allegations.
Publish the governance fact and rationale without exposing unnecessary personal data.
Prohibited patterns
Section titled “Prohibited patterns”ANUKA governance must not:
- make public claims with no linked decision record;
- hide ordinary product policy in private chats;
- delete unresolved objections from history;
- rewrite votes after closing;
- allow conflicted participants to secretly direct outcomes;
- use confidentiality to conceal self-dealing;
- treat meeting recordings as permanent surveillance by default;
- expose personal data to perform transparency;
- permit unreviewed force pushes to ratified governance branches;
- claim public consensus when affected parties were not notified.
Minimum implementation baseline
Section titled “Minimum implementation baseline”Before governance is described as transparent, ANUKA should have:
- public proposal and decision registry;
- role and delegation registry;
- conflict disclosure process;
- recusal records;
- meeting and minutes template;
- confidentiality classes;
- retention policy;
- protected governance repositories;
- CODEOWNERS;
- required status checks;
- correction process;
- protected reporting channel;
- annual accountability report template.
Sources
Section titled “Sources”- W3C Process Document
- Apache — The Apache Way
- Apache — Board of Directors
- GitHub — About CODEOWNERS
- GitHub — Creating rulesets
- GitHub — Available rules for rulesets
Verification record
Section titled “Verification record”- Sources opened and checked: 2 August 2026
- Status: Founding draft
- Repository rules implemented: Not yet verified
- Conflict registry required: Yes