Consent, custody, retention, and what we cannot yet claim, stated plainly enough for your counsel to hold us to it. Where a practice is already checkable in a shipped report, we say so and point to it. Where it is not yet in place, we say "not yet" and say what stands there today. This page describes our practice. The terms that bind RSC on your engagement are the ones in your signed engagement letter, which controls if the two ever differ.
These are checkable today: code that runs on our machine, or language already inside a report you can download. Read them for what they are. RSC has zero signed client engagements, so every one of these is a running system and a written procedure, never yet exercised against a real client's data. Where that distinction changes what you are getting, we say so in the row itself.
A local direct-identifier removal step strips name, email, phone, address, date of birth, and Social Security columns from a raw file, scrubs email addresses, phone numbers, and SSN-shaped strings out of open-text write-ins, and assigns each respondent a stable ID. Names, addresses, and dates of birth inside free-text answers are handled at output review rather than by that automatic pass. This is direct-identifier removal and pseudonymization, not HIPAA Safe Harbor and not expert determination. The ID crosswalk is held separately from the analysis file and is destroyed with it. Indirect identifiers are handled at output through suppression rather than in the working file, so we treat these files as sensitive throughout. It runs on our own machine, with no network call and no AI involved in that step.
We use software tools, including AI-assisted tools, for routine production work: drafting instruments, coding open-ended responses, checking arithmetic, assembling reports. Identifiable participant data is not submitted to any third-party AI service. Where such a tool touches client material, that material is de-identified first.
Raw files land in a quarantine location we do not open into any analysis tool. Only the de-identified copy is analyzed. Raw client data does not ride any version-control history or backup process we run.
Client data is held on RSC-controlled systems in the United States, on a machine we control, and not in a third-party cloud service. For an unusually sensitive dataset (health, domestic-violence shelter, minors), we additionally isolate the analysis so that no portion of the file is processed by any external tool, de-identified or not. Read this limit before you rely on it: disk encryption at rest is not in place on that machine today, and we will not call it a control until it is. As of 2026-08-25, no client data is held there. If your funder requires encryption at rest, tell us before work begins and we will meet that standard or decline the engagement.
Wherever fielding allows it, a survey runs through your own account (your email list, your own Google or Microsoft Forms account), and we receive the export, not the account. That keeps custody of the raw responses with you rather than with us.
No participant is identifiable in a finding. Where a group is small enough that a person could be recognized, results are aggregated further and the report says so. Our published capacity-build sample (built on invented data, as its cover states) is built to a suppression threshold of n<10 with complementary suppression, and that sample states plainly that the rule came from the sample client's own agreement. Our own default version of the same rule, n<10 unless your funder's agreement sets a different number, is written and would apply by default; see the honesty note under "Not yet" below.
We process only the data an engagement needs. At close, your data is returned or destroyed on your written instruction, and we confirm in writing when it is done.
No subcontractor touches your data without your written consent naming that subcontractor. RSC is currently a one-person practice; no subcontractor has ever been engaged, and none is used unless you agree to one in advance.
Your data is used solely to produce your deliverable. It is never shared, sold, pooled across clients, or used to market anything else.
We notify you in writing within 72 hours of discovering any unauthorized access to your data, with what is known at that time. This clause is in every engagement agreement we ship. Florida's Information Protection Act (s. 501.171) governs any consumer notice you owe on top of that. That statute also places a duty on us, not only on you: as a third party holding your data we must notify you of a breach so that you can meet your own obligation, and our own 72-hour written notice term exists to make that possible.
The public demonstration report on our samples page states, and the shipped file carries through, this practice: every source file behind a figure is retained on file with its cryptographic hash, so you can cite any figure back to us and we can confirm, against the retained file, that it matches the source exactly.
Every correction made to your raw data is documented in a cleaning log delivered with your report, so you can see exactly what changed and why.
Reports are versioned with a change log. A factual correction you point out is welcomed; an analytic judgment changes only if the evidence changes, and the log states which kind of change happened. Our own published capacity sample carries a change-log entry that withdraws one of our own earlier claims for exactly this reason.
We keep a direction-of-error ledger: every mistake we catch in our own work is logged with which direction it fell, so an error that happened to flatter RSC gets counted the same as one that did not. On a genuine tie, the tie is scored against us.
Every shipped report is checked in code for a machine-readable document language and title, a text description generated from each chart's own data, properly tagged data tables, and no skipped heading levels. Honest scope: this is a mechanical check we run ourselves, not a formal PDF/UA or Section 508 certification, and no independent validator runs against it.
Our intent, written into our draft engagement letter and not yet attorney-reviewed: on full payment your deliverables become your property, to use, publish, and give to your funder without restriction. Two limits are stated in the same draft and we state them here rather than in the fine print: the deliverables do not include our own pre-existing methods, templates, scripts, and tooling, which stay ours, and you receive the outputs rather than the production system behind them. We will describe our method at whatever level of detail you or your funder needs to trust the result. We name you publicly, or describe an engagement at all, only with your written permission.
This is a map of the basis to obtain for each data type, drawn from the statutes themselves. It tells you what we would work from; it is not a substitute for your counsel's read of your specific program.
| Data type | Basis / exception we would work from |
|---|---|
| Education records (FERPA) | The audit/evaluation exception (34 CFR 99.31(a)(3), 99.35) or the studies exception (99.31(a)(6)), with a written agreement naming RSC as the party designated to receive the data. |
| Florida student records | Section 1002.22, Florida Statutes. |
| Protected health information (HIPAA) | A signed Business Associate Agreement before any PHI moves. None is currently in force with anyone. |
| Substance-use-disorder treatment data | 42 CFR Part 2 consent and Qualified Service Organization Agreement requirements (relevant to CFBHN-funded services). |
| Child-welfare records | Confidentiality under s. 39.202, Florida Statutes; requires funder-side authorization. |
| Library patron records | Florida's library patron-records confidentiality statute as the known pattern; exact citation and basis confirmed per state and engagement. |
RSC is new. These are gaps we can name exactly, so you are never finding one yourself after the engagement starts.
There is no standing RSC consent policy for a parent survey or anything else.
Today: our engagement letter asks you to name any notice or consent your own funder or program agreements require, before participants are surveyed; the legal-basis map above tells us what basis to go get.
Our destruction term, drafted at 60 days from your written close-out instruction, exists as a drafted default, marked "v1 draft for seal," pending one attorney review before first use. It has not yet been executed: no client-level data inventory has been opened and no certificate of destruction has been issued, because no engagement has required one yet.
Today: the drafted default term is what we would put in your data-sharing agreement unless your funder's own rule is stricter, in which case we conform to the stricter one.
Our conflict-of-interest rule is written: one advisory client per opportunity, a four-question screen run at intake, never both sides of the same funded dollar, and a 12-month cooling-off before serving the opposite side of a related program, and no client above roughly 35% of RSC revenue after year one. The register that rule calls for logging every check into has not been created, because no client has triggered a first entry yet.
Today: the rule is enforced by the same one-person practice applying it to itself before any engagement is accepted; the register opens on the first entry.
The governance documents behind this page are our own drafting and have not yet been through attorney review: the data-handling terms, the children's-data kit (our draft data-sharing checklist covering legal basis by data type, Level 2 background-screening triggers, and retention and destruction on engagements involving children's program data), the conflict-of-interest rule, and the engagement letter.
Today: attorney review is the next step we are taking on them, and we will tell you when it is done. Where your own counsel would rather work from their language than ours, we will work from theirs, and we will say so in writing.
We have no record of who was, and was not, consulted in scoping any past engagement, because RSC has not yet run one.
Today: your written scope names who is consulted before data collection begins; ask for this to be explicit if it matters to your board or your funder.
We have no engagement history to point to on this question, one way or the other.
Today: our default field design, running a survey through your own account and receiving only the export, is built specifically so the answer is "no" by design; we cannot yet back that with a track record.
No coverage is currently bound: not professional liability (errors and omissions), not general liability, not commercial auto, not workers' compensation or a Florida exemption on file, not cyber.
Today: nothing is bound. Where it actually stands as of 2026-08-26: a professional liability quote is in hand, and we are working to place professional liability and cyber coverage through an independent agent. We will not represent coverage that does not exist, and our own rule is that we do not sign a participant-data engagement before coverage binds.
RSC has zero signed engagements, so there is no reference to give. We do not claim past performance we do not have; our capability statement says so directly.
Today: the published samples and this page are the closest thing to a track record we have, because they are checkable without a phone call to a stranger.
We have not yet settled whether we sign a county's standard agreement as written or redline it. Two specific frictions are already known internally and unresolved: a liability cap tied to fees paid versus the $1,000,000 professional-liability limit this market typically requires, and which state's law and venue govern.
Today: bring your standard agreement to the scope call; we will tell you plainly what we can sign as-is and what we would need to discuss.
Neither an E-Verify enrollment nor a scrutinized-companies (s. 287.135, Florida Statutes) affidavit has been filed.
Today: tell us if your solicitation requires either; we will complete it before signature rather than after.
Our accessibility checks (above) are mechanical checks we run ourselves. They are not a formal Section 508 or PDF/UA certification, and no independent validator runs against our output.
Today: we will say "checked" and never "certified," and we will tell you exactly what the check does and does not cover.
None has been signed yet, because no engagement has required one.
Today: our data-sharing agreement checklist (data elements, security controls, suppression rule, retention clock) is the redline we would bring to your first one.
We have no Institutional Review Board relationship and no human-subjects protocol on file. We commit to identifying and pursuing any required IRB or human-subjects review, institutional or external, as part of scoping whenever a program's data touches human subjects.
Today: if your program touches survivor data, consent questions, or IRB review, we take the question and answer in writing rather than guessing on a call.
No Level 2 screening has been run. RSC cannot self-initiate one; the hiring or contracting entity has to initiate it.
Today: we are screening-ready on engagement, and will not argue if your program requires it.
RSC is currently one person. The engagement letter's succession clause, who holds access instructions if the principal cannot continue, has not yet been filled in with a name.
Today: if continuity matters to your program, raise it at scoping and we will name someone before signature, not after.
The written-consent rule and the requirement that any bench analyst sign the same terms exist on paper. No subcontractor has ever been engaged under them.
Today: treat this as the rule we would apply the first time it comes up, not as a program already running.
Specific terms, net-30 payment, a milestone split, and the rule that a deliverable failing its written scope does not invoice its milestone, exist inside an unreviewed draft engagement letter, not on any page a visitor can read today.
Today: ask, and we will put the specific terms in writing for you before you sign anything.
Our own reporting standard scores this element missing against ICD 203: we version at the report level, not yet at the level of each individual finding.
Today: the report-level changelog (above) is what exists; per-finding tracking is a known gap in our own standard, not something we are claiming.
Checked directly against every sample PDF on this site, 2026-09-10: our capacity-build sample carries small-cell suppression at n<10, a 60-day destruction term, and source hashing; our outcome-data sample carries small-cell suppression and source hashing; our public demonstration report carries source hashing; our evaluation sample carries a cleaning log; our verification sample carries none of these. None of them uses the words consent, privacy, de-identification, confidentiality, conflict of interest, or IRB. The practices on this page are real, but this page is where most of them are written down, not yet the samples themselves.
Today: read this page alongside the samples; a future sample built for a public-sector buyer will carry this language directly.
Ask us directly and we answer straight, in writing, before you sign anything. If the honest answer is "not yet," you get that answer, not a vaguer one.
Yes, on request. We do not publish it here, because it carries our EIN, which we keep off any public page and hand only to a named payer.
No. We do not give legal advice, do not rule on whether a funder's own requirement is lawful, and do not certify compliance with any of them. Our reporting discipline is modeled on ICD 203, the analytic standard the U.S. Intelligence Community holds its own analysts to; "modeled on" is deliberate, it is not a claim of certification to anything.
Tell us before work begins and we conform to the stricter standard, or we decline the engagement.
Send it directly. You get an answer from the analyst who wrote this page, not a form queue.