@beaconlabs-io/evidence 1.1.0

package/evidence/11.mdx

@@ -0,0 +1,58 @@
+---
+evidence_id: "11"
+results:
+  - intervention: "Administrators participating in offline meeting"
+    outcome_variable: "Increase the volume of users’ editing activity (number of edits) and the posibility of presence of editing"
+    outcome: "+-"
+strength: "3"
+methodologies:
+  - "DID, Covariate matching"
+version: "1.0.0"
+datasets:
+  - ""
+title: "How Administrators’ Participation in Offline Meetings Influences Their Contributions"
+date: "2024-11-05"
+
+citation:
+  - name: "How offline meetings affect online activities: the case of Wikipedia"
+    src: "https://epjdatascience.springeropen.com/articles/10.1140/epjds/s13688-024-00506-w"
+    type: "link"
+author: "BeaconLabs"
+---
+
+## Key Points
+
+- Administrators generally make more edits across all namespaces, but the post-meeting increase in activity is smaller than for other users.
+- Administrators who had been inactive are more likely to resume editing after meetings, but their subsequent increase in activity is not as large as that of other users.
+
+## Background
+
+Prior research suggests that meetings are essential to administrative decision-making and that users who become administrators may increase their activity after participating. This study examines how the administrator role influences contribution behavior following meetings.
+
+## Analysis Method
+
+### Dataset
+
+- We combine a comprehensive dataset on informal offline meetings in the German-language Wikipedia community from 2001 to 2020 with large-scale online activity data.
+- The dataset includes information on 4,408 small-scale meetings and 4,013 participating users.
+- All online actions on Wikipedia are recorded, and users’ editing activities are measured from metadata dumps.
+- Information on whether a user has ever become a Wikipedia administrator is also included.
+
+### Intervation / Explanatory Variable
+
+- In addition to participation in offline meetings, we consider whether the user is an administrator.
+- The models include an indicator for administrator status and its interaction terms.
+
+### Dependent Variable
+
+- Outcome variables are the volume of users’ editing activity (number of edits) and the presence/absence of editing, analyzed over short, medium, and long horizons.
+
+### Identification Strategy
+
+- We use a quasi-experimental design (DiD, matching, multilevel LPM, multilevel negative binomial models), incorporating triple interaction terms to assess how administrator status moderates meeting effects.
+
+## Results
+
+- Users who are administrators tend to make more edits across all namespaces regardless of meeting participation.
+- However, after attending a meeting, administrators show smaller increases in activity compared to other users. This likely reflects a ceiling effect: administrators already have high baseline activity, leaving less room for additional increases from meetings.
+- In the medium-term (1 month) models, inactive administrators are more likely to resume editing after meetings; yet, as in the short-term models, their subsequent increase in activity is smaller than for other users. A similar negative moderating effect of administrator status appears in the long-term (1 year) trends.

package/evidence/12.mdx

@@ -0,0 +1,62 @@
+---
+evidence_id: "12"
+results:
+  - intervention: "Participation in the Google Summer of Code (GSoC) Program"
+    outcome_variable: "Continuity of Students’ Contributions to GSoC Projects"
+    outcome: "+-"
+strength: "1"
+methodologies:
+  - "Interview"
+version: "1.0.0"
+datasets:
+  - ""
+title: "Continuity of OSS contributions after participating in the Google Summer of Code (GSoC) Program"
+date: "2019-12-14"
+tags:
+  - "oss"
+  - "public goods funding"
+citation:
+  - name: "Google summer of code: Student motivations and contributions"
+    src: "https://ctreude.ca/wp-content/uploads/2019/12/jss20.pdf"
+    type: "link"
+author: "BeaconLabs"
+---
+
+## Key Points
+
+Most GSoC students did not continue contributing to their projects after the program, but a minority became frequent contributors. Since students mainly participated for enriching (work) experiences rather than to become long-term OSS contributors, this also shaped contribution continuity.
+
+## Background
+
+OSS projects join Summer of Code programs hoping for retention of newcomers and increased code contributions. Previous research focused on students’ quantitative contributions during GSoC or their outcomes. However, the link between motivations for participation and post-program contributions had not been examined. This study investigates students’ motivations for joining GSoC and their intentions/continuation of contributions afterward. Prior research found that experience levels strongly influence retention, that GSoC fosters strong bonds between mentors and students, and that 18% of students later became mentors.
+
+## Analysis Method
+
+### Dataset
+
+- The study targeted students who participated in GSoC between 2010 and 2015. Out of 1000 survey invitations, 141 students responded (14.1% response rate).
+- From these, 10 students volunteered for follow-up interviews.
+
+### Intervation / Explanatory Variable
+
+- Participation in GSoC, along with associated experiences and rewards.
+- GSoC is a three-month program that provides scholarships and mentorship to students who wish to contribute to open source software (OSS) projects.
+
+### Dependent Variable
+
+- Students’ intent to continue contributing and changes in contribution frequency before/after GSoC.
+
+### Identification Strategy
+
+- Data was collected via survey questions (OSS contributions before/after GSoC, general participation reasons).
+- Descriptive statistics were applied. Results were also compared with prior quantitative research (Silva et al., 2017).
+
+## Results
+
+- Pre-GSoC Contributions: 56.0% had “Never” contributed to their chosen project before GSoC, and 13.5% said “Rarely.” For OSS projects outside GSoC, 34.7% said “Never” and 32.6% “Rarely.”
+- Intent to Continue: About 57% intended to continue contributing (“Yes” or “Definitely yes”).
+- Actual Continuation: Post-GSoC contributions were reported as: “No” 17.0%, “Rarely” 21.3%, “Occasionally” 32.6%, “Frequently” 12.8%, “Core member” 16.3%.
+- Change in Contribution Frequency: About 53% (75 students) reported increased contribution frequency after GSoC. However, prior quantitative research (Silva et al., 2017) showed only ~16% continued contributing after several months, consistent with this study’s findings. This aligns with Roberts et al. (2006), suggesting initial motivations don’t always translate to long-term retention.
+- Frequent Contributors: Both this and prior studies indicated a small subset of students became frequent developers.
+
+Link to Motivations: While stipends were important, experienced developers saw them as essential. Less experienced students emphasized career building as the main reason for joining.

package/evidence/13.mdx

@@ -0,0 +1,53 @@
+---
+evidence_id: "13"
+results:
+  - intervention: "Classification of badgeholders’ voting behavior based on the concept of “temperature”"
+    outcome_variable: "Funding allocation to projects."
+    outcome: "+-"
+strength: "1"
+methodologies:
+  - "Counterfactual analysis"
+version: "1.0.0"
+datasets:
+  - ""
+title: "Analysis of “Hot” and “Cold” Trends in Badgeholders’ Voting Behavior"
+date: "2024-05-22"
+
+citation:
+  - name: "A deepdive into FIL-RetroPGF-1 results"
+    src: "https://medium.com/cryptoeconlab/a-deepdive-into-fil-retropgf-1-results-7e5a0bcdba08"
+    type: "link"
+author: "BeaconLabs"
+---
+
+## Key Points
+
+A simulation analysis of how voting behavior trends (hot/cold) influence funding allocation. “Hot” voters are defined as those who concentrate votes on a small number of projects, while “cold” voters are those who spread votes across many projects. The analysis simulates funding allocation excluding these types of voters and evaluates the impact by comparing it to the original allocation.
+
+## Background
+
+In FIL-RetroPGF-1, each badgeholder (voter) had 100 votes and cast them across multiple projects. This analysis classifies badgeholders’ voting behavior based on the concept of “temperature” and examines how such tendencies affected overall funding allocation. Specifically, it identifies “hot” voters who concentrate votes on a small number of projects and “cold” voters who spread votes across many projects, then simulates scenarios excluding these groups.
+
+## Analysis Method
+
+### Dataset
+
+An anonymized dataset of all votes cast by badgeholders in the FIL-RetroPGF-1 round.
+
+### Intervation / Explanatory Variable
+
+Excluding the top 10% of “hot” badgeholders (those who concentrated votes on fewer projects) and the top 10% of “cold” badgeholders (those who spread votes across many projects) from the dataset.
+
+### Dependent Variable
+
+Funding allocation to projects
+
+### Identification Strategy
+
+A counterfactual analysis comparing three scenarios: the original funding allocation, allocation excluding “hot” badgeholders, and allocation excluding “cold” badgeholders.
+
+## Results
+
+- Excluding the top 10% of “hot” badgeholders had a very small impact on funding allocation.
+- In contrast, excluding the top 10% of “cold” badgeholders led to a disproportionately large reduction in the number of projects receiving funding.
+- This is likely because “cold” badgeholders helped more projects reach the quorum requirement, enabling funding to be distributed more widely. In addition, their low votes (e.g., 0, 1, 2) lowered the average scores of projects, further contributing to broader distribution of funds.

package/evidence/14.mdx

@@ -0,0 +1,52 @@
+---
+evidence_id: "14"
+results:
+  - intervention: "The alphabetical order of the first letter of the project name"
+    outcome_variable: "(a) The total number of votes received by each project, and (b) the average project score"
+    outcome: "!"
+strength: "1"
+methodologies:
+  - "Regression analysis, MCMC"
+version: "1.0.0"
+title: "Analysis of the impact of project display order in the user interface (UI) on voting results"
+date: "2024-05-22"
+
+citation:
+  - name: "A deepdive into FIL-RetroPGF-1 results"
+    src: "https://medium.com/cryptoeconlab/a-deepdive-into-fil-retropgf-1-results-7e5a0bcdba08"
+    type: "link"
+author: "BeaconLabs"
+---
+
+## Key Points
+
+A regression analysis of the bias introduced by the UI project display order on voting results. In the voting interface, projects were displayed in alphabetical order. We conducted a regression analysis of the correlation between this display order (the first letter of the project name) and both the number of votes received and the average score for each project, in order to evaluate the presence and impact of UI bias.
+
+## Background
+
+In the FIL-RetroPGF-1 vote, the software “easy-retropgf” displayed projects in alphabetical order. We tested the hypothesis that this ordering biased badge holders’ voting behavior and, as a result, influenced the allocation of funds.
+
+## Analysis Method
+
+### Dataset
+
+Project-level voting counts and average scores from the FIL-RetroPGF-1 round.
+
+### Intervation / Explanatory Variable
+
+The alphabetical order of the first letter of the project name.
+
+### Dependent Variable
+
+(a) The total number of votes received by each project, and (b) the average project score.
+
+### Identification Strategy
+
+We performed regression analysis to calculate the correlation between the first letter of the project name and both total votes and average scores. Furthermore, we applied MCMC (Markov Chain Monte Carlo) methods to test statistical significance.
+
+## Results
+
+- A negative correlation of -0.27 was found between the first letter of the project name and total votes, and a negative correlation of -0.20 with average scores. This suggests that projects whose names start with later letters of the alphabet tend to receive fewer votes and lower average scores.
+- This effect was confirmed to be statistically significant.
+- Specifically, it is estimated that for each subsequent letter in the alphabet, the average fund allocation decreases by approximately 40 FIL.
+- Based on these findings, organizers are considering improving the UI in future rounds to reduce such effects.

package/evidence/15.mdx

@@ -0,0 +1,53 @@
+---
+evidence_id: "15"
+results:
+  - intervention: "Scoring rules (sum, median, mean, etc.)"
+    outcome_variable: "Distribution of funding amounts allocated to each project"
+    outcome: "+"
+strength: "3"
+methodologies:
+  - "Comparison of simulated counterfactual results"
+version: "1.0.0"
+datasets:
+  - "Voting data from badgeholders (voters) in FIL-RetroPGF-2"
+title: "Impact of Changes to Scoring Rules on Fund Allocation"
+date: "2024-12-19"
+
+citation:
+  - name: "A deepdive into FIL-RetroPGF-2 results"
+    src: "https://medium.com/cryptoeconlab/a-deepdive-into-fil-retropgf-2-results-880234699fe4"
+    type: "link"
+author: "BeaconLabs"
+---
+
+## Key Points
+
+In FIL-RetroPGF-2, the scoring rule was changed from the median in Round 1 to the sum. This change made the fund distribution closer to a power-law distribution, increasing the amount of funding received by top projects.
+
+## Background
+
+Within the Filecoin ecosystem, a Retroactive Public Goods Funding (RetroPGF) program has been implemented to provide funding for public goods. FIL-RetroPGF-2 was the second iteration of this program. Based on the results of Round 1, the scoring rules were revised with two objectives: to make the voting mechanism easier to understand, and to ensure that while top projects received substantial funding, a wide range of projects—including those in the long tail—would also benefit.
+
+## Analysis Method
+
+### Dataset
+
+Voting data from badgeholders (voters) in FIL-RetroPGF-2
+
+### Intervation / Explanatory Variable
+
+Scoring rules (sum, median, mean, etc.)
+
+### Dependent Variable
+
+Distribution of funding amounts allocated to each project
+
+### Identification Strategy
+
+The actual fund allocation results using the sum scoring rule in FIL-RetroPGF-2 were compared with simulated counterfactual results under median or mean scoring. In addition, statistical comparisons were made between Round 1 (median) and Round 2 (sum).
+
+## Results
+
+- The sum scoring rule was observed to generate a funding distribution more closely resembling a power-law distribution than the median or mean rules.
+- As a result, compared to Round 1, a larger share of funding went to top projects in Round 2.
+- This change, together with the shift toward assigning absolute funding amounts rather than percentages by badgeholders, may have contributed to a more exponential distribution of funding.

package/evidence/16.mdx

@@ -0,0 +1,52 @@
+---
+evidence_id: "16"
+results:
+  - intervention: "The first letter of the project name (alphabetical order)"
+    outcome_variable: "Number of votes each project received, and total funding allocated to each project"
+    outcome: "+"
+strength: "1"
+methodologies:
+  - "Markov Chain Monte Carlo (MCMC)"
+version: "1.0.0"
+datasets:
+  - "Voting data from badgeholders (voters) in FIL-RetroPGF-2"
+title: "Elimination of Alphabetical Order Bias through UI Randomization"
+date: "2024-12-19"
+citation:
+  - name: "A deepdive into FIL-RetroPGF-2 results"
+    src: "https://medium.com/cryptoeconlab/a-deepdive-into-fil-retropgf-2-results-880234699fe4"
+    type: "link"
+author: "BeaconLabs"
+---
+
+## Key Points
+
+In FIL-RetroPGF-2, the voting software (Gitcoin easy-retropgf) was updated so that the display order of projects was randomized for each badgeholder. As a result, it was confirmed that the bias caused by alphabetical ordering of project names on vote counts and funding allocations was effectively eliminated.
+
+## Background
+
+There had been concerns that the order in which projects were displayed in the voting interface (UI) could influence voters’ decisions. In particular, to remove the “order effect,” where projects displayed earlier in the list had an advantage, UI improvements were implemented in Round 2.
+
+## Analysis Method
+
+### Dataset
+
+Project data from FIL-RetroPGF-2 (project names), along with the number of votes and amount of funding allocated to each project.
+
+### Intervation / Explanatory Variable
+
+The first letter of the project name (alphabetical order)
+
+### Dependent Variable
+
+- Number of votes each project received.
+- Total funding allocated to each project.
+
+### Identification Strategy
+
+Using the Markov Chain Monte Carlo (MCMC) method, the distribution of correlations between the first letter of project names and both “number of votes” and “funding allocations” was inferred. This was used to evaluate whether the correlation was statistically significant.
+
+## Results
+
+- The analysis revealed a very small negative correlation between the first letter of project names and the number of votes received, but no significant correlation with the amount of funding allocated.
+- From these results, it was concluded that the potential alphabetical ordering effect observed in Round 1 was effectively removed by the UI improvements introduced this time.

package/evidence/17.mdx

@@ -0,0 +1,53 @@
+---
+evidence_id: "17"
+results:
+  - intervention: "Subsets of badgeholders (randomly sampled, ranging from 28 to 33 members)"
+    outcome_variable: "Distribution of funding allocations to projects"
+    outcome: "N/A"
+strength: "0"
+methodologies:
+  - "Bootstrap method"
+version: "1.0.0"
+datasets:
+  - "All voting data cast by badgeholders in FIL-RetroPGF-2"
+title: "Reliability Verification of Badgeholder Set Size"
+date: "2024-12-19"
+
+citation:
+  - name: "A deepdive into FIL-RetroPGF-2 results"
+    src: "https://medium.com/cryptoeconlab/a-deepdive-into-fil-retropgf-2-results-880234699fe4"
+    type: "link"
+author: "BeaconLabs"
+---
+
+## Key Points
+
+Bootstrap analysis demonstrated that the number of badgeholders (33 participants in FIL-RetroPGF-2) is a reasonable scale for estimating the “true signal” of funding allocation.
+
+## Background
+
+Decision-making by a small number of voters carries the risk of significant variation depending on how the voter group is selected. Therefore, it was necessary to verify whether the funding allocation results by the 33 participating badgeholders remained stable, even if a different set of members had been chosen.
+
+## Analysis Method
+
+### Dataset
+
+All voting data cast by badgeholders in FIL-RetroPGF-2
+
+### Intervation / Explanatory Variable
+
+Subsets of badgeholders (randomly sampled, ranging from 28 to 33 members)
+
+### Dependent Variable
+
+Distribution of funding allocations to projects
+
+### Identification Strategy
+
+Analysis was conducted using the bootstrap method. Specifically, 1,000 subsets were randomly drawn from the actual voting badgeholders, and funding allocations were recalculated for each subset. This allowed for the estimation of confidence intervals for the funding distribution, which were then compared with the actual allocation results.
+
+## Results
+
+- The confidence intervals obtained through bootstrap analysis showed little dispersion.
+- This indicates that with 33 badgeholders, the overall funding allocation trends would not change significantly even if some voters were replaced, thereby confirming the reliability of the results.
+- The interquartile range (IQR) also supports the conclusion that this number of badgeholders is appropriate for capturing the “true signal.”

package/evidence/18.mdx

@@ -0,0 +1,52 @@
+---
+evidence_id: "18"
+results:
+  - intervention: "Whether or not the project application included a GitHub link"
+    outcome_variable: "The amount of FIL allocated to the project"
+    outcome: "+"
+strength: "1"
+methodologies:
+  - "Comparison Between Intervention Group (With GitHub Link) and Non-Intervention Group (Without GitHub Link)"
+version: "2.0.0"
+datasets:
+  - "All voting data cast by badgeholders in FIL-RetroPGF-2"
+title: "Relationship Between GitHub Links and Funding Allocation"
+date: "2024-05-30"
+citation:
+  - name: "Reflections on Filecoin's first round of RetroPGF"
+    src: "https://docs.oso.xyz/blog/fil-retropgf-1/"
+    type: "link"
+author: "BeaconLabs"
+---
+
+## Key Points
+
+Projects that included a GitHub link in their applications tended to receive more funding (FIL) compared to those that did not. This suggests that contributions to open-source software development may have influenced how badgeholders (evaluators) assessed project impact.
+
+## Background
+
+In Filecoin’s first round of retroactive public goods funding (RetroPGF 1), projects could include links in their applications to document their contributions and impact on the ecosystem. Among these, GitHub links were the most common, making them an important data point in analyzing how contributions to open-source software were evaluated.
+
+## Analysis Method
+
+### Dataset
+
+Application data from 106 projects that participated in Filecoin RetroPGF 1, verified by Open Source Observer (OSO). Specifically, the analysis examined whether GitHub links were included in applications and the amount of FIL allocated to each project.
+
+### Intervation / Explanatory Variable
+
+Whether or not the project application included a GitHub link
+
+### Dependent Variable
+
+The amount of FIL allocated to the project
+
+### Identification Strategy
+
+Projects were divided into two groups: those with GitHub links (60 projects verified by OSO) and those without (the remaining 46 projects). The median FIL allocation between the two groups was compared.
+
+## Results
+
+- The 60 projects verified by OSO as having GitHub links received a median of 2135 FIL.
+- The remaining 46 projects, either without GitHub links or not verified by OSO, received a median of 1465 FIL.
+- These results show that projects including GitHub links performed better—that is, they received more funding allocations.

package/evidence/19.mdx

@@ -0,0 +1,54 @@
+---
+evidence_id: "19"
+results:
+  - intervention: "Developer months as a proxy for development effort"
+    outcome_variable: "The amount of FIL allocated to each project"
+    outcome: "-"
+strength: "1"
+methodologies:
+  - "Visualized the relationship by using scatter plots"
+version: "2.0.0"
+datasets:
+  - "Data from 60 projects with GitHub links verified by Open Source Observer"
+title: "No Correlation Between Development Effort and Funding Allocation"
+date: "2024-05-30"
+citation:
+  - name: "Reflections on Filecoin's first round of RetroPGF"
+    src: "https://docs.oso.xyz/blog/fil-retropgf-1/"
+    type: "link"
+author: "BeaconLabs"
+---
+
+## Key Points
+
+There was little correlation between the amount of development effort (measured in “developer months”) and the amount of funding (FIL) allocated through RetroPGF. Smaller projects tended to show a higher “ROI (Return on Investment)” in terms of FIL received relative to effort invested.
+
+## Background
+
+For funding mechanisms like RetroPGF to serve as a meaningful source of income for developers, we would expect a proper correlation between inputs (effort), outputs (impact), and rewards. In this analysis, we used “developer months” as a proxy measure of development effort and examined its relationship with rewards.
+
+## Analysis Method
+
+### Dataset
+
+- Data from 60 projects with GitHub links verified by Open Source Observer (OSO).
+- The dataset included each project’s commit history and FIL allocation.
+
+### Intervation / Explanatory Variable
+
+- “Developer months” as a proxy for development effort.
+- A “developer month” was defined as a unique GitHub contributor who made three or more commits to the repository in a given month.
+
+### Dependent Variable
+
+The amount of FIL allocated to each project
+
+### Identification Strategy
+
+We visualized the relationship between “developer months” and allocated FIL for the 60 OSO-verified projects using scatter plots and analyzed correlations.
+
+## Results
+
+- There was little correlation between allocated FIL and “developer months.”
+- Even though the amount of input varied exponentially across projects, the differences in FIL rewards were relatively small. As a result, smaller projects tended to have higher FIL per developer month (higher ROI). For example, one project received 5,000 FIL for 72 developer months (about 70 FIL/month), while another received 4,000 FIL for 36 developer months (about 111 FIL/month; note: the original text stated 140 FIL/month, but the calculation does not match—although the trend remains the same).
+- This issue has also been observed in Optimism’s RetroPGF, where smaller teams tend to receive more rewards per contributor compared to larger teams.

package/evidence/20.mdx

@@ -0,0 +1,53 @@
+---
+evidence_id: "20"
+results:
+  - intervention: "Type of funding program (Filecoin RetroPGF 1 vs. Optimism RetroPGF3)"
+    outcome_variable: "Distribution of funding amounts across projects"
+    outcome: "N/A"
+strength: "1"
+methodologies:
+  - "Visualizing the distribution of funding amounts in both rounds and comparing their shapes (flatness)"
+version: "2.0.0"
+datasets:
+  - "Allocation data for 99 projects from Filecoin RetroPGF 1 and allocation data from Optimism RetroPGF3"
+title: "Comparison of Funding Allocation Distribution in Filecoin and Optimism’s RetroPGF"
+date: "2024-05-30"
+citation:
+  - name: "Reflections on Filecoin's first round of RetroPGF"
+    src: "https://docs.oso.xyz/blog/fil-retropgf-1/"
+    type: "link"
+author: "BeaconLabs"
+---
+
+## Key Points
+
+The funding allocation in Filecoin’s first RetroPGF round showed a very flat distribution compared to Optimism’s RetroPGF3. This means there was not a large gap in funding amounts between high-impact projects and mid-tier projects.
+
+## Background
+
+How resources are allocated in retrospective public goods funding reflects the values and evaluation mechanisms of the ecosystem. By comparing the results of Filecoin’s first round with the more mature Optimism round, we can highlight their characteristics.
+
+## Analysis Method
+
+### Dataset
+
+Allocation data for 99 projects from Filecoin RetroPGF 1 and allocation data from Optimism RetroPGF3
+
+### Intervation / Explanatory Variable
+
+Type of funding program (Filecoin RetroPGF 1 vs. Optimism RetroPGF3)
+
+### Dependent Variable
+
+Distribution of funding amounts across projects
+
+### Identification Strategy
+
+Visualizing the distribution of funding amounts in both rounds and comparing their shapes (flatness)
+
+## Results
+
+- In Filecoin, the top project (GLIF Nodes & RPC API) received 4,365 FIL, which was only about twice as much as the median project (Filemarket), which received 1,925 FIL.
+- This allocation is described as a relatively even “peanut butter spread” distribution.
+- This distribution was much flatter than Optimism’s RetroPGF3.
+- In Filecoin, there was also little difference in funding amounts across categories. Although the “Infrastructure” category was generally favored, the distribution within that category was just as flat as in other categories. In contrast, Optimism showed more pronounced differences by theme.

package/package.json

@@ -0,0 +1,75 @@
+{
+  "name": "@beaconlabs-io/evidence",
+  "version": "1.1.0",
+  "description": "Evidence collection with Zod schemas and content for Beacon Labs MUSE platform",
+  "license": "MIT",
+  "author": "Beacon Labs",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/beaconlabs-io/evidence.git"
+  },
+  "homepage": "https://github.com/beaconlabs-io/evidence#readme",
+  "bugs": {
+    "url": "https://github.com/beaconlabs-io/evidence/issues"
+  },
+  "keywords": [
+    "evidence",
+    "impact",
+    "theory-of-change",
+    "social-impact",
+    "zod",
+    "mdx",
+    "beacon-labs",
+    "ebp",
+    "ebpm"
+  ],
+  "type": "module",
+  "main": "./dist/index.js",
+  "module": "./dist/index.js",
+  "types": "./dist/index.d.ts",
+  "exports": {
+    ".": {
+      "types": "./dist/index.d.ts",
+      "import": "./dist/index.js"
+    },
+    "./types": {
+      "types": "./dist/types.d.ts",
+      "import": "./dist/types.js"
+    },
+    "./content": {
+      "types": "./dist/content/index.d.ts",
+      "import": "./dist/content/index.js"
+    }
+  },
+  "files": [
+    "dist",
+    "evidence",
+    "deployments"
+  ],
+  "scripts": {
+    "prepare": "husky",
+    "validate": "bun run .github/scripts/validate-evidence.ts",
+    "typecheck": "tsc --noEmit",
+    "bundle-content": "bun run scripts/bundle-content.ts",
+    "build": "bun run bundle-content && tsc -p tsconfig.build.json",
+    "prepublishOnly": "bun run build",
+    "changeset": "changeset",
+    "version": "changeset version",
+    "release": "npm run build && changeset publish"
+  },
+  "devDependencies": {
+    "@changesets/changelog-github": "^0.5.1",
+    "@changesets/cli": "^2.28.1",
+    "@types/node": "^22.0.0",
+    "bun-types": "^1.0.0",
+    "husky": "^9.1.7",
+    "typescript": "^5.0.0",
+    "zod": "^4.0.0"
+  },
+  "dependencies": {
+    "gray-matter": "^4.0.3"
+  },
+  "peerDependencies": {
+    "zod": "^4.0.0"
+  }
+}