Mirror public evidence
GitHub applications and comments, two operational Google Sheet tabs, linked Forum topics, and Community Grants Updates are preserved with source identity and provenance.
Working prototype
Zcash Community Grants Decision Support
ZCG currently operates across GitHub, the Zcash Community Forum, Google Sheets, and private operational workflows. This prototype mirrors the public evidence, reconciles it into a coherent grant history, and makes uncertainty reviewable without asking ZCG to replace its current tools first.
This is an independent prototype and architecture proposal, not an official ZCG production system unless relevant Zcash ecosystem stakeholders adopt it.
Working now
From public records to traceable grant data
Reconcile grant history
Related records become canonical applications, funded-grant records, normalized FPF milestone/disbursement ledger rows, labels, decision history, confidence scores, and explicit review issues.
Keep reviewer judgment durable
Manual source links, dismissals, and application relationships are audited and replayed after generated reconciliation instead of disappearing on refresh.
Search and brief from grounded evidence
Full-text and vector retrieval connect applications, source evidence, labels, meeting decisions, and open review issues. Authorized reviewers can generate versioned committee briefings or temporary, private, and shared custom analyses with citation snapshots.
Why this approach
Modernize the data layer without breaking public trust
Today, people are the integration layer keeping application intake, discussion, decisions, milestone reporting, and financial tracking aligned. The prototype makes those relationships explicit while retaining the original evidence.
Migrate before replacing
The prototype reads existing public systems first. ZCG can evaluate a unified data model without requiring an immediate workflow cutover.
Make provenance first-class
Source IDs, URLs, checksums, payloads, confidence, relationship roles, and reviewer rationale stay attached to the records they support.
Surface uncertainty
Missing and ambiguous relationships belong in a visible review queue. The system should not manufacture certainty or silently discard conflicting evidence.
Separate public and private data
Public projections are allowlisted. KYC, agreements, payment instructions, custody, and internal deliberation require explicit private boundaries.
Connected today
Current source coverage
- GitHub grant issues, labels, and comments
- ZCG All Grants plus normalized FPF milestone and recorded-disbursement ledger rows
- Forum topics discovered from applications and registry records
- Community Grants Updates and meeting-decision history
Explicit boundary
Not yet first-class workflows
- Progress updates, payment requests, approvals, and settlement verification
- Jotform RFP intake and website content
- KYC, agreements, attachments, and private operations
- Applicant workflows and controlled writeback to current systems
Explore the prototype
Inspect the data, evidence, and reviewer workflow
Public read-only views expose selected operational surfaces. Writes, richer retrieval modes, synchronization, indexing, and user management remain permissioned.
Deliberate public projection
Public pages and exports use an explicit allowlist rather than exposing raw operational rows: publicGrantId, title, publicApplicantName, status, githubLabels, category, requestedAmountUsd, approvedAmountUsd, publicMilestones, publicProgressUpdates, publicPaymentSummary, sourceLinks, updatedAt.