docs: explain DIN model fit and partner participation

[Santiagocetran]

Summary

• Add a new-user guide to what can be trained on DIN, separating the tested MNIST example from models that need custom work (Clarify what can be trained on DIN and how to bring a dataset #157).
• Add a short introduction for potential testnet partners, covering participation paths, setup, costs, support, and experimental limitations (Create a shared introduction for potential testnet partners #158).
• Link the two guides to each other and from the documentation index and Getting Started.

Review focus

@abrahamnash: Please review the vision, public contact, and policy language before this is shared externally, especially the fair-launch and testnet-reset rows.

@umeradl: Please check technical accuracy, current DevNet 2.0 scope, hardware baseline, fees, slashing, and rewards language.

The partner guide deliberately does not promise rewards, future allocation, or continuity of testnet state. Issue #155 still tracks testnet tokenomics settings; issue #75 still tracks fair-launch eligibility. The contact email is the one already listed in the repository README and should be confirmed as the partner intake route.

Validation

• python3 .github/scripts/check_doc_links.py Documentation — 181 relative links resolve.
• Checked relative link targets and heading fragments in both guides separately.
• git diff --check passes.

Related: #157, #158

[abrahamnash]

Thank you, @Santiagocetran - excellent, I've read it through and I am happy on the vision, public contact, and policy language. Clear from my side.

[umeradl]

Reviewed against develop in an isolated worktree. The branch applies cleanly on top of current tip ea349d6 (merge-base 7b66392, 2 commits, no conflicts). Both a local git merge-tree --write-tree and GitHub's mergeable: MERGEABLE / mergeStateStatus: CLEAN confirm it. This is a docs-only PR, so I checked each technical claim in the two new pages against foundry/src/ and the existing docs instead of only reading the prose.

Claimed: check_doc_links.py Documentation resolves 181 relative links, and git diff --check passes.

Verified, holds: I re-ran both in the worktree. The script printed checked 181 inline relative link(s) in: Documentation and all inline relative links resolve (exit 0). git diff --check origin/develop...HEAD exited 0. I also checked the one heading fragment by hand: ../technical/services/clients.md#manifest-driven-dp-configuration matches ## Manifest-Driven DP Configuration (clients.md:96).

Claimed (technical-accuracy review requested): fees, slashing, rewards, staking, and scope language match DevNet 2.0 on develop.

Verified, all hold against foundry/src/:

• Separate open-source and proprietary fees, for both registration and manifest updates, and changeable: DINModelRegistry.sol has openSourceFee, proprietaryFee, openSourceUpdateFee, and proprietaryUpdateFee (L108-111), plus owner-only setters (L448-499).
• Fee routing exists; the destination depends on deployment: setFeeRouter / sweepFeesToRouter (L499, L511), with IDinFeeRouter.routeFeeETH. "Check the selected deployment" is the right hedge.
• New models and manifest changes pass an approval step: approveModel / rejectModel (L217/L261) and approveManifestUpdate / rejectManifestUpdate (L324/L342), all onlyOwner.
• Validators get DIN by depositing ETH: DinCoordinator.depositAndMint() (L92) at dinPerEth (L30, owner-updatable at L171).
• Auditors and aggregators can lose stake: DINTaskAuditor.slashAuditors (L1305, S1 partial s1SlashFractionBps / S3 full minStake()) and DINTaskCoordinator.slashAggregators (L938, AGG_T1/T2_NO_SUBMISSION at S2 fraction, AGG_T1/T2_BAD_CONSENSUS at full minStake). The fraction params are exactly what issue No. 155 is still settling, so "parameters under review" is accurate.
• Clients don't stake: DINTaskAuditor.submitLocalModel (L721) checks only GI state, one submission per address per GI, and MAX_LM_SUBMISSIONS. There is no stake check.
• Emission and claim contracts exist, amounts not set: DinEmission.sol and DinFairLaunchDistributor.sol (Merkle claim, reverts NoRootSet until a root is set).
• DP is off by default: clients.md:194 ("DP is off by default.") and cache_model_0/services/client.py:323 ("enabled": False).
• Model_0 hardware baseline: getting-started.md:152-154 lists 4 GB RAM, ~30 GB disk, and a standard CPU, and the PR labels these Model_0-only.
• Contact and discussion: mailto:abrahamnash@protonmail.com is the same address as README.md:88. Discussion No. 102 is open and titled "DevNet 2.0 pre-launch — bugs & feedback (develop)".
• Issue scope: Both pages cover every bullet in issue No. 157 (fit, customization, steps to bring a model and dataset, who starts a task, costs) and issue No. 158 (what DIN is, ways to contribute, needs, support and limits, settled vs. undecided on fees, rewards, distribution, and resets).

Policy row, for @abrahamnash: the fair-launch row ("no ICO, pre-sale, or VC allocation in the current plan") matches BL-18 in Developer/BACK_LOG.md, which records the Jul 31 decision and resolves the ICO-vs-airdrop fork in favor of the validator airdrop. However, Developer/design/MECHANISM_DESIGN.md §9 item 14 and the §7 "Supply policy" table on develop still describe ICO and airdrop as "both kept open". That staleness is on develop, not in this PR, but please confirm the BL-18 position is still the one to state externally.

Non-blocking nits:

• No. 1: Title mismatch. The H1 of what-can-be-trained.md is "What can I train on DIN?", and partner-introduction.md uses that wording. The link text in Documentation/README.md and getting-started.md says "What can be trained on DIN?" instead. Pick one.
• No. 2: Fee currency. Registration and update fees are paid in ETH (msg.value in requestModelRegistration / requestManifestUpdate), not DIN. In partner-introduction.md, the "Test tokens and operating costs" bullet puts fees right after the DIN-token sentence, so a reader could assume fees are paid in DIN. Suggest "Model owners pay registration fees in test ETH".
• No. 3: Second registration gate (optional). Before registry approval, the DIN-Representative must also authorize the model's task contracts as slashers (DinCoordinator.addSlasherContract; the coordinator's AwaitingDINTaskCoordinatorAsSlasher state). "A new model must be reviewed before it appears in the registry" is correct but leaves this step out. A half-sentence or a link to model-workflow.md would set expectations for a model owner planning a timeline.

Not independently re-verified: the claims about framework portability (TensorFlow, scikit-learn, JAX) and LoRA-style adapter fine-tuning. The PR correctly labels them as untested possibilities, and nothing in the repo exercises them.

---

Every checkable technical claim held up against the current contracts and docs. From a technical-accuracy standpoint this is mergeable once it leaves draft, with the three nits as optional polish. The remaining gate is Abraham's sign-off on the vision, contact, and policy wording.

[umeradl]

Files changed (4) — as of 51cb27a (PR head)

Diffed against merge-base 7b66392 (develop). develop has moved 11 commits since the branch was cut, touching 6 files. None of them are among this PR's 4 files, so there is no overlap. GitHub agrees: mergeable: MERGEABLE, mergeStateStatus: CLEAN. A local git merge-tree --write-tree dry run is also clean (exit 0).

Documentation/public/what-can-be-trained.md

Field	Value
Change	New
Lines	+56/-0
Diff (what exactly is in this PR)	New public guide for issue No. 157: a fit table by kind of idea (similar-data, tabular/language, LLM fine-tune, async), what a model owner must bring (task, client training, test data and scoring, aggregation, people and resources), the GI round in 5 steps, a pre-start checklist (fit, resources, data and privacy, people, costs), and how to try it.
Functionality — how & why	How: Pure docs. It separates the tested MNIST/Model_0 path from the custom-service path (services.md, manifest.md) and from untested ideas. The protocol-level claims match foundry/src/ (registry approval gate approveModel/approveManifestUpdate, fee tiers) and the reference services (DP off by default, clients.md:194). Why: Issue No. 157. A newcomer or partner couldn't tell from services.md and client-onboarding.md which parts of "any framework / any model" are tested and which are aspirational.
Diff vs current develop HEAD	None (new file)
Recommended merge proposal	Merge as-is. Optional nits No. 1 (H1 vs. link-text wording) and No. 3 (mention the slasher-authorization gate before registry approval) from the verification comment.
Actual merge proposal	Soon
Pending proposal	Nits No. 1 and No. 3 (optional)
Local merge conflict	No
GitHub merge conflict	No

Documentation/public/partner-introduction.md

Field	Value
Change	New
Lines	+55/-0
Diff (what exactly is in this PR)	New partner-facing introduction for issue No. 158: what DIN is, a roles table (client/auditor/aggregator/model owner/developer), team needs (time, hardware, setup, tokens and costs), 4 steps from interest to a first round, a settled-vs-undecided table (fees, validator rewards, slashing, future token distribution, testnet resets), and a contact section (README email plus Discussion No. 102).
Functionality — how & why	How: Pure docs. Every "in the code" row matches the contracts: fee tiers and fee router in DINModelRegistry; slashing via slashAuditors/slashAggregators with fraction params still open in issue No. 155; DinEmission and DinFairLaunchDistributor present but unparameterized; clients stake-free in submitLocalModel. The fair-launch row follows BL-18. Why: Issue No. 158. Outreach needed one consistent, reviewed explanation of participation that makes no reward, allocation, or continuity promises.
Diff vs current develop HEAD	None (new file)
Recommended merge proposal	Merge after Abraham's sign-off on the vision, contact, and policy rows (the author asked for this; the PR is still draft). Optional nit No. 2: say registration fees are paid in test ETH, not DIN.
Actual merge proposal	Soon
Pending proposal	Abraham review of the fair-launch/ICO and testnet-reset wording; nit No. 2 (optional)
Local merge conflict	No
GitHub merge conflict	No

Documentation/README.md and Documentation/public/getting-started.md

Field	Value
Change	Modified (both)
Lines	+2/-0 each
Diff (what exactly is in this PR)	README: two new rows in the public-docs index table for the two new pages. getting-started.md: one pointer line under the welcome paragraph, sending readers with a different model or dataset to the new fit guide.
Functionality — how & why	How: Link-only additions. check_doc_links.py resolves all 181 relative links, including these. Why: Makes the new pages discoverable from the docs index and from the Model_0 entry point, where readers with their own model would otherwise stop.
Diff vs current develop HEAD	None. Neither file changed on develop since the merge-base.
Recommended merge proposal	Merge as-is. Nit No. 1 would change the link text here if the H1 wording is chosen instead.
Actual merge proposal	Soon
Pending proposal	Nit No. 1 (optional)
Local merge conflict	No
GitHub merge conflict	No

Verification

Docs-only, so there is no forge or pytest signal to add. python3 .github/scripts/check_doc_links.py Documentation reports 181 links, all resolving (exit 0), and git diff --check passes. Each technical claim is traced to foundry/src/ line references in the verification comment above.

Local vs. GitHub agree: yes. Both report a clean merge with no conflicts.