Connect211 Proposal for New Field of HSDS Standardized Objects

Technical
, ,
1

Hi all — I’d like to open a discussion around adding a small set of new objects to HSDS for exchanging feedback on existing records, and I’d appreciate a read-through and critique from this community. Because of our requirements to deliver for our clients, governance and standards work will have to be done for us in parallel with implementation, but we’re happy to do the work to adopt and conform to the standard as it evolves so long as we get a say in the matter ʕ•ᴥ•ʔ

:bookmark_tabs: Connect211’s Proposal: HSDS Feedback Exchange Standard Proposal - Draft - Google Docs

The problem

A lot of us are building (or want to build) mechanisms which let community partners tell us when a listing in an HSDS directory is wrong — a changed phone number, an outdated eligibility description, a service that’s no longer offered.

But the people submitting that feedback aren’t data professionals. They won’t spend more than a minute or two, and they’ll describe the change in their own words. That’s fine for capturing the correction, but it creates two problems once we try to act on it:

  • There’s no shared shape for exchanging that raw feedback between systems.
  • There’s no shared shape for turning “our number changed” into a structured, reviewable change to a specific field.

AI can help bridge that gap — but only if there’s a standard object model for both the input and the output, with the right governance baked into the data model to communicate the origin of the data, be it from a human or an AI.

I think now, at the beginning of this work, is the right time to bake opinionated governance decisions into the data model to help us distinguish AI feedback and AI-derived edits from human feedback, so we can enforce a high-trust collaboration ecosystem at the infrastructural layer of our industry. We essentially need both AI systems and humans to identify and credential themselves, so feedback can be taken with the adequate grain (or salt shaker) of salt — otherwise we risk wasting the time of people who are already spread too thin, instead of helping them map our social safety net better and faster.

The proposal

I’ve drafted a minimal, transport-agnostic extension with three core objects:

  • FeedbackItem — one submitted piece of feedback, anchored to an existing organization, location, service, or service_at_location. Can be a free-text comment or structured “direct value” input, and always declares whether it came from a human, an AI agent, or an automated system.
  • ChangeOrder — one proposed, field-level replacement derived from a FeedbackItem. A single comment can fan out into multiple change orders (e.g. one phone number, one eligibility description).
  • SuggestedAmendment (optional) — a proposal to add or remove an entire child entity (a new phone number, a newly launched program), for teams that need entity-level suggestions in addition to field-level corrections.

The design tries to stay out of the way of existing workflows: no required transport, no mandated review process, no assumption about whether AI is involved in deriving change orders from comments.

Where I’d especially like feedback

Three things I’m least confident about and would value pushback on:

  1. Identifying who — or what — submitted feedback. Every FeedbackItem now declares an actor type (human / AI agent / automated system) via a SubmitterContext object, so this is required infrastructure, not an afterthought — but the personal-identity fields within it (name, contact info, stated affiliation) stay optional, since HSDS doesn’t try to verify identity; that’s left to each network’s own trust and governance layer. Separately, every ChangeOrder and SuggestedAmendment declares how it was produced (human-supplied directly, AI-derived from free text, manually reviewed, or rule-based) — deliberately kept as a second, independent field, since a human’s comment can produce an AI-derived change order and an AI’s flag can produce a human-confirmed one. Is that the right line to draw? Should we require AI systems to “cite their sources”? I’d love real practical use cases from data managers on what they’d want to see from feedback generated by AI web crawlers specifically.

  2. Privacy, PII, and PHI risk. This is the one I think deserves the most scrutiny. Because FeedbackItem is designed to accept unstructured free text from non-experts, it creates a real risk of incidental disclosure that most of HSDS doesn’t otherwise carry — not just the submitter’s own contact info, but the possibility that a submitter names a specific service recipient in their explanation (e.g. “when [a client] came in, it seemed like…”). That person never submitted anything and never consented to anything. The draft includes a dedicated section proposing what adopters should be expected to define (access control, retention, independent redaction of identity/content, staff handling), while deliberately not trying to solve detection or redaction at the schema level. I’d like to know whether this community thinks that’s the right scope for a data standard to take on, or whether it should go further — or stay silent and leave it entirely to implementers.

  3. Verification (or the lack of it). Right now, both who submitted feedback and how a change was derived are self-declared, with no cryptographic or platform-level verification specified. Is that an acceptable starting point for a v1, or does trust here need teeth from the outset?

Full draft: HSDS Feedback Exchange Standard Proposal - Draft - Google Docs

If this gets traction, I’d like to turn it into a formal JSON Schema and/or collaborate on artifacts describing best practices for implementation. But right now I’m mainly looking for holes in the model.

Thanks for reading — looking forward to the discussion.

David Botos
Connect211

1 Like