Start with a clear, permitted invitation.
Suggested recruitment window: two weeksThis first group is a small convenience sample for product decisions. Seek varied backgrounds where practical, but do not call it representative of global tech workers, hiring teams or any subreddit.
A complete rollout reference and format comparison is now available. Codex executed this local simulation with reference assistance; it does not represent an unaided exercise completed by Atharva or a human-reviewed result.
- Prepare a real example first. Complete one local lab, preserve the actual before/after output and create a concise README and pack for exactly that work. Redact personal data. Describe the actual author and assistance accurately; do not label AI-authored work as unaided personal work. Show this example so people can judge the request.
- Pick two relevant communities. Read their current rules and recruitment/self-promotion guidance. Send the draft permission request only after you decide to do outreach. A moderator's silence is not permission. Use an existing feedback or career thread only if its current rules permit this request.
- Post one approved invitation per selected community. Start with two practitioner places and one reviewer place; fill the remaining three and two after learning whether the request is clear. Let people opt in. Do not scrape members, bulk-message commenters or treat past research quotes as consent to contact.
- Offer a small, bounded commitment. Learner: plan for 20–30 minutes to try the browser rollout lab and export a pack. Reviewer: plan for 10–15 minutes to inspect the completed example. These are planning estimates, not measured completion times. Start with no compensation; say so. If that limits participation, reconsider the burden or a budget before inviting more.
- Close the loop after two weeks. Count invitations/posts allowed, opt-ins, eligible volunteers and completed sessions separately. If you cannot recruit, revise the ask or community fit. Do not reinterpret recruitment failure as proof that the product lacks value.
| Community leads from the research | Potential fit | Before any outreach |
|---|---|---|
| r/devops, r/sre | Operational evidence; reviewers who assess troubleshooting. | Check current rules, appropriate threads and moderator guidance. These are research leads, not verified permission to recruit or post. |
| r/Cloud, r/AZURE, r/aws | Cloud practitioners and people moving from adjacent roles. | |
| r/devsecops, r/sysadmin | Security and operations decisions; support-to-cloud transitions. |
These communities appeared in the existing research. Current posting rules have not been verified for this kit. An alternative is an opt-in request in an existing local technical meetup, study group or alumni group that explicitly permits it; no such relationships are assumed.
Keep eligibility and consent short.
No CV, account or identity checkPractitioner screener
- Are you 18 or older and willing to spend the stated time? A yes/no is enough.
- Which broad area best describes your current or intended work: support/sysadmin, DevOps/SRE, cloud, security, or another technical role?
- Within the last six months, have you tried to explain technical work in an application, interview or internal role discussion? What was difficult? “No recent example” is valid.
- Do you have a small personal/public artifact you are permitted to show? If not, would you prefer the supplied synthetic lab or to decline?
- Would a text-based session or a different time/access format help?
Recruit on role fit and ability to participate, not on whether someone reports pain or likes OpsProof. Seek a mix of current practitioners and adjacent-role participants. Record recent examples and people with no recent difficulty; both can challenge the hypothesis.
Reviewer screener
- Have you personally screened technical candidates or reviewed operational work samples within the last 12 months?
- Which broad role families did you assess? No employer, candidate names or hiring records are needed.
- Can you review one short synthetic artifact in two formats for 15 minutes and identify what you would still need to ask?
- Are you independent of the artifact's author? If not, record the relationship and find another reviewer for the comparison.
Use three distinct reviewers, separate from the five practitioner participants. Self-described experience is sufficient for this pilot and remains unverified. Peer learners can report usability separately; do not count them as recent hiring screeners.
Read this before each session
“This is voluntary feedback on an early evidence-format tool, not a job interview. You may skip a question or stop at any time. There is no payment, hiring assessment, certificate or job promise. We will use a synthetic or permitted public artifact and brief notes under a session code. No CV, account, real employer incident data or recording is needed. Before taking notes, agree on their private destination and when the facilitator will remove them. Online pilot submissions are handled separately: the form explains its storage and provides a private receipt for withdrawal. Do not promise a deletion schedule that has not been arranged. May we proceed and take these notes?”
Record “consent: yes/no,” session code and date. If no, stop without collecting answers. No recording is planned. Obtain separate, explicit permission before publishing any quote or artifact; otherwise report only aggregate observations and paraphrases without identifying details.
Keep scheduling and contact information in the existing private conversation with the volunteer. Do not copy names, handles, email addresses, exact employers, CVs or job application details into the app, this worksheet or a public repository. Restrict notes to the facilitator; export only a redacted summary. This page has no collection endpoint, analytics or storage.
Two ready-to-adapt outreach drafts.
Drafts only · nothing sentReplace the bracketed text before using a draft. Describe yourself honestly as the builder. Send or post only after checking the destination's current rules and obtaining any required permission.
Moderator permission request
Community invitation after permission
Give both formats a fair test.
Same content in both formatsPrepare one fair comparison
Use one real local-run artifact from the pilot, with its author's permission. Create a good README and an OpsProof pack containing the same evidence, explanations, limitations and assistance disclosure. Keep code, report bytes, links and origin identical. Do not weaken the README or hide evidence to favor the pack. Freeze both versions before the first review and assign neutral labels A and B.
Before the sessions, write a short answer key grounded in the underlying artifact: the supported change claim, exact supporting result, actual versus proposed boundary, and one real limitation. Keep it out of the review copy. Score only answers supported by the artifact; log disagreements for discussion rather than treating your key as an external certification.
Facilitated walkthrough · suggested timing
- 3 minutes: consent and the last concrete difficulty explaining work.
- 10 minutes: ask them to attach or describe one permitted artifact, label its origin and connect one claim to a result. Observe without coaching; note help separately.
- 5 minutes: export and locate the claim, limitation and assistance disclosure in the pack.
- 5 minutes: ask “What added work without adding value? What would you remove? When would you use this again?” Invite an optional second use within seven days.
Track exercise/setup time separately from evidence-format time. Someone learning a lab for an hour has not necessarily spent an hour using the pack workflow.
Solo dogfooding week
While recruiting, complete each local lab and produce one pack per scenario. Check first-run instructions, errors, input hashes, data loss, keyboard/mobile navigation and export readability. Keep a dated issue log and fix the most blocking problems.
This is usability and correctness work only. Founder use, AI review and synthetic test data cannot establish independent reviewer demand, hiring utility or community adoption. Leave the participant results blank until people actually take part.
Reviewer comparison · 15 minutes
| Time | Action | Record |
|---|---|---|
| 0–1 min | Read consent. Explain that both formats show the same work and this is not a candidate hiring decision. | Consent, session code and assigned order. |
| 1–5 min | Show first format. Ask: locate one supported claim and its exact result; say what was executed versus proposed; identify one material limitation. | Time to supported answer, completion without help, incorrect/unsupported conclusions. Stop at four minutes. |
| 5–9 min | Show second format. Repeat the same three tasks without changing the artifact or prompting the answers. | Same measures; record familiarity with the work. |
| 9–12 min | Ask: “What was easier or harder in each? What question would you still ask the author? Did either format invite you to over-trust a claim?” | Specific examples and missing questions, not just preference. |
| 12–15 min | Ask: “Would you voluntarily use either format for another artifact? Which existing step, if any, could it replace? Is a good README sufficient?” | Choice, reason and optional invitation to a second review; no simulated answers. |
Alternate order: reviewer R1 sees README then pack; R2 sees pack then README; R3 sees README then pack. If you reach R4 and R5, continue the alternation. Record actual order. Three sessions cannot balance the order perfectly, and the second view benefits from familiarity. Treat times as directional observations; do not claim a causal speed improvement.
One worksheet per reviewer.
Print or copy · no contact fieldsBlank worksheet; no review has been performed. Use a session code such as R1. Do not enter a name, handle, email, employer or candidate information.
| Measure | README | OpsProof pack |
|---|---|---|
| Supported claim + exact evidence located? Yes / no / helped | ||
| Executed vs. proposed correctly distinguished? Yes / no / helped | ||
| One supported limitation identified? Yes / no / helped | ||
| Seconds to complete all three (or “not finished at 240s”) | ||
| Unsupported conclusions or over-trust observed | ||
| Specific helpful / obstructive element |
Which format, if either, would you use again — and why?
What follow-up question remains? Which existing step could this replace?
Facilitator help, interruptions, order effect or scoring disagreement:
Optional second review: declined / invited / accepted / completed. Do not equate acceptance with completion.
Small cohort tally
| Practitioner observations | Count / denominator | Reviewer observations | Count / denominator |
|---|---|---|---|
| Eligible / consented / completed | ___ / ___ / ___ | Eligible / consented / completed | ___ / ___ / ___ |
| Recent concrete evidence problem | ___ / 5 | Specific added utility with all three pack tasks completed independently | ___ / 3 |
| Exported usable pack without facilitator takeover | ___ / 5 | Would voluntarily review another pack, with a reason | ___ / 3 |
| Actually created a second pack within seven days | ___ / 5 | Actually completed a second optional review | ___ / 3 |
Preserve no-shows and incomplete sessions as separate counts. Do not replace them quietly with successful volunteers. Record reasons only when freely offered. Publish counts with denominators, not percentages that imply precision.
Set the gates before seeing results.
Founder decision rules, not scientific thresholdsThese rules choose the next product investment. The sample is too small and selected to establish job outcomes, population prevalence or reliable causal effects. Record a written decision after the sessions, including contradictory evidence.
| Gate | Continue to the next small pilot when… | Otherwise… |
|---|---|---|
| Problem fit | At least 3 of 5 practitioners describe a recent specific difficulty explaining permitted work, before seeing a sales pitch. | Revisit the intended user/problem. Do not add features to compensate for an unclear need. |
| Usable workflow | At least 4 of 5 create and export one clearly labelled pack without facilitator takeover; no unresolved data-loss or privacy defect. | Fix the blocking steps and retest usability. Separate lab difficulty from app difficulty. |
| Reviewer utility | At least 2 of 3 complete all three pack tasks independently, identify a specific benefit over the good README and say they would use the format again. Resolve any false impression of verified identity, production work or actual savings. | Revise the format or keep it a personal documentation tool. Pause employer-facing value claims. |
| Repeat use | At least 2 of 5 practitioners actually make another pack within seven days, and at least 1 of 3 reviewers completes a second optional review. | Ask what prevented return. Keep review optional and defer marketplace/community infrastructure. |
After the first eight people: if the gates pass, add two independent recent screeners to reach the earlier research plan's five-reviewer milestone. Across five, look for at least three who demonstrate specific utility and would use the format again. Then consider a 10-person opt-in repeat-use cohort. Keep later regional/language pilots separate and compare what changes.
If fewer than five practitioner sessions or three reviewer sessions complete, label the result “incomplete pilot” and report recruitment/attendance separately. If results conflict, revise the riskiest assumption and run another narrow comparison. No outcome here justifies saying OpsProof improves hiring odds.
Next action: try the pilot task and feedback flow, choose two appropriate community leads, check their rules and adapt the permission draft. All outreach remains a human decision; this kit has sent no messages, recruited no people and recorded no feedback.