Continously rerun adapters.
Add data from them.
Warn somewhere on ones that got stale and needs fixing.
If things become heavy automatically reduce load (run updates every week, but give some rule on which adapter to run how frequently based on previous amount of updates).
Reject issues with the validator (which returns to the point of warning. If we updated our validation and not the code, it will tell us)
Currently validator needs some updates, so if done close to now (June 2026), talk to @nelaturuharsha.
Context:
we can additionally bake in the checks for hf_model_id and hf_id into the adapter for now, its stopgap and not the best way - but it will unblock it.
Think I will have to say if we don’t have this information i.e.
platform:
type of deployment:
hf_id (if local) or whatever weights location
dataset_id (if on hf)
or
dataset location
Data will not be accepted
We can make these instructions clear to the person editing the adaptor for now I guess, or manually to submitters.
Continously rerun adapters.
Add data from them.
Warn somewhere on ones that got stale and needs fixing.
If things become heavy automatically reduce load (run updates every week, but give some rule on which adapter to run how frequently based on previous amount of updates).
Reject issues with the validator (which returns to the point of warning. If we updated our validation and not the code, it will tell us)
Currently validator needs some updates, so if done close to now (June 2026), talk to @nelaturuharsha.
Context:
we can additionally bake in the checks for hf_model_id and hf_id into the adapter for now, its stopgap and not the best way - but it will unblock it.
Think I will have to say if we don’t have this information i.e.
platform:
type of deployment:
hf_id (if local) or whatever weights location
dataset_id (if on hf)
or
dataset location
Data will not be accepted
We can make these instructions clear to the person editing the adaptor for now I guess, or manually to submitters.