-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modification: AC Bot - Thresholds to Enforce Compliance #986
Comments
It looks like a good approach and considered actual scenarios. However I just have one question, how to understand this?:
Share with what? Other LDNs from other people? Or the same dataset from a series of LDNs? How to reduce it to 0% after it's there? By terminating sectors? As we know same dataset prepared by different DPs using the same software, e.g. Singularity, can possibly produce same cars. |
Great proposal, more permissionless! |
Agree |
Currently the bot is deploying a new version, the bot stopped working, it seems like it's been 2 weeks, looking forward to the bot getting back to growing. |
So, has the issue with the bot been resolved? |
No, the bot is still not working. It seems that the ac robot needs to be online to resume operations. |
This is a continuation from the earlier initial proposal in #976 concerning the implementation of the Aggregation and Compliance bot. This bot is designed to compile data from different data sources and enforce guidelines. Based on the tests we have conducted, this proposal outlines more refined thresholds for the AC bot to make determinations on DataCap removal
Test process
To simulate the AC bot's effect on the Fil+ process, we assessed how each client performed against each metric highlighted in the previous proposal. We then visualized the data using histograms to display the distribution of client scores across each metric. Based on insights from these histograms, we started an internal Fil+ governance team discussion to determine the appropriate thresholds. The subsequent sections outline the finalized thresholds, the resulting data in that sequence.
Thresholds
Here are the proposed thresholds schedules for DataCap removal that will begin once the bot is deployed and will gradually be tightened over a 8-week period. This incremental approach will allow clients to adapt to the chaning compliance standards. Failing these thresholds will result in automatic creation of a DataCap removal proposal.
For the metrics "Claimed SP Count," "Claimed SP Count," and "Actual SP Count," we currently lack sufficient data to enforce immediate thresholds. As a result, we suggest a 6-week data collection phase to gather the necessary insights. More about this is described in the "Test Results and Rationale" section.
Next steps and call to arms
If there are no objections and we obtain the required support for implementing the AC bot with these thresholds, we will proceed with GitHub integration and deployment. Please note that the capability for DataCap removal is contingent upon the functionality being developed in line with this proposal
If you support this implementation please indicate so in the comment section below. For those who believe there should be ammendments to the proposal, we welcome your input in comments as well. Additionally, you're welcome to reach out to any member of the Fil+ team or directly to @philippe pangestu on Slack for further discussions.
Test Results and Rationale
The testing phase involved data analysis of 229 client addresses with active GitHub applications, as well as the subset of 116 clients who have initiated their applications within the past three months. The following graphs describe how client addresses have scored against each of the metrics:
CID-checker score
Retrievability bot score
Claimed SP count
Actual SP count after fourth allocation
percent of actual SPs in claimed list
KYC check
SP unique locations
Percent of properly replicated data
Max percent data stored by top provider
Shared data percent
The text was updated successfully, but these errors were encountered: