Community Engagement in Government AI
Commissioner Aisha Okonkwo had done everything by the book. Her city's new AI system for prioritizing housing-inspection complaints had a privacy review, a bias audit, and a public comment period. Forty-five days, posted on the city website. Exactly four people commented, three of them vendors. So when the system launched and tenant advocates discovered it deprioritized complaints from neighborhoods with historically low reporting rates, the outrage was total. "You never asked us," said the head of the tenants' union at the council meeting. Technically, Aisha had. She had posted a notice. What she had not done was engage a community. Eight months and one rebuilt system later, she understood that the difference cost her more than the engagement ever would have.
This lesson is for agency heads and senior leaders who are past the question of whether to involve the public and are now facing the harder question of how to do it so that it actually shapes the system. Community engagement in government AI is not a comment box. It is a governance structure, and at your level you are the one who builds it. It is also the area where a well-intentioned leader is most likely to mistake a completed process for a discharged obligation, which is the failure Aisha made and the one this lesson spends most of its time on.
The Difference Between Notice and Engagement
There is a well-worn ladder in public participation, and most government AI efforts sit on its bottom rung without realizing it. Picture five rungs, running from least to most power-sharing:
- Inform: you tell people what you decided. A press release.
- Consult: you ask for input after deciding. Aisha's comment period.
- Involve: you bring people in while options are still open.
- Collaborate: you build the criteria and trade-offs together.
- Empower: the community holds real decision authority, such as a veto.
Aisha's comment period was a consult dressed as participation, and it ran after the design choices were locked. The tenants' union wanted to be at the involve rung at minimum, before the priority rules were set. Nothing about the process was improper. The notice went up, the window ran, the comments were read. The process simply could not have changed the system, because by the time it opened there was nothing left that a comment could move.
The single biggest lever you control is when you engage. Engagement after the architecture is fixed is theater. Engagement while the priority weights are still adjustable is governance. Decide which rung each AI decision deserves, and engage at that rung before, not after, the code is written. Be honest with yourself about which rung you are actually on, too. Leaders describe processes as collaboration that are, on inspection, an inform with a question-and-answer session attached, and the community usually notices well before the leader does.
Choosing the rung is a proportionality judgment, and it is yours to make explicitly rather than by default. An internal tool that drafts routine correspondence does not warrant a community panel, and pretending otherwise wastes the community's attention on something that does not affect them. A system that ranks who gets an inspection, a benefit, a placement or an enforcement visit is a different matter, because it distributes a scarce public good and the distribution rule is a value choice. The rough test is whether the system decides something about identifiable people that they would want to contest. The more consequential and the less reversible the effect, the higher the rung, and the earlier the engagement has to start.
What a Completed Process Does Not Establish
This is the section to read twice, because the error it describes is nearly universal and it is not a cynical error. It is made by people acting in good faith who have confused doing the thing with achieving the thing.
A listening session does not confer legitimacy on the decision that follows it. An advisory board does not establish that a system is fair. A translated notice does not by itself provide language access. A published response to comments does not discharge whatever participation obligation applies to your agency. Each of these is a means, and each of them is capable of producing exactly nothing while looking, in a status report, indistinguishable from success. Aisha's comment period is the clean example. It ran its full length, it was properly noticed, and it engaged nobody who would be affected.
The reason this matters at the leadership level is that the artifacts are what get reported upward. Nobody briefs a deputy secretary on how many tenants were in the room. They brief on whether the comment period was held, whether the panel met, whether the response was published. If you accept those artifacts as the measure, you will build a program that reliably produces them and just as reliably fails to change any system. Ask instead the only question that discriminates: what specifically is different about this system because of the engagement? If the answer is nothing, the engagement did not happen, whatever the file says.
The corollary is a discipline about authority. Consultation informs a decision that your agency still owns. A community panel that agrees with you has not transferred responsibility to itself, and a community panel that disagrees with you has not made the decision for you either. Citing community support as the justification for a contested system is a misuse of the process, and it is the fastest way to teach a community that participating is a trap. If you are not prepared to own the decision, do not run the engagement.
Participatory Governance for AI
Participatory governance means the community is built into the system's lifecycle rather than consulted at one gate. For a public-facing AI system, there are four moments where community voice changes the outcome, and you should plan engagement at each of them rather than choosing between them.
- Problem framing. Before any tool is scoped: is AI even the right answer here, and what would fair look like to the people affected? Aisha's whole error was skipping this. The community would have flagged the reporting-rate bias as a design question rather than discovering it as a launch failure.
- Design trade-offs. Every AI system encodes value choices. Should the inspection model prioritize the most severe hazards or the most numerous complaints? That is not a technical question, it is a values question, and the people who live with the answer should weigh in on it.
- Pre-launch review. A community panel sees the system's behavior on real-looking cases before the public does, and can stop a launch.
- Ongoing oversight. The community has a standing seat to see how the system performs over time and to trigger review when something looks wrong.
Notice how the four moments differ in what they can still change. Problem framing can change whether the system is built at all. Design trade-offs can change what it optimizes for. Pre-launch review can delay or block. Ongoing oversight can only trigger a correction after the fact, which is valuable and is also the weakest of the four. A program that engages only at the last moment has chosen the cheapest option and should not describe itself as participatory.
The ongoing oversight moment is also the one agencies quietly let lapse, because it has no deadline forcing it. The panel that met monthly before launch meets quarterly after, then when convened, then not at all, and nobody decides this. It simply happens as the project team disperses to the next system. Give the standing seat a fixed cadence, a defined packet of performance information that arrives whether or not anyone asks, and an explicit trigger the community can pull to force a review. Without a trigger the community's only escalation route is the one Aisha experienced, which is the council meeting.
This mirrors the spirit of the federal direction. Office of Management and Budget guidance issued in 2024, Memorandum M-24-10, requires agencies to consult affected communities for AI that affects people's rights or safety, and the NIST AI Risk Management Framework, which is voluntary and non-binding, treats input from affected groups as a core part of mapping risk rather than as a courtesy. Both rest on the same insight: the people closest to the harm see it first. Neither one tells you what a sufficient consultation looks like in your jurisdiction, so establish that with your own counsel rather than assuming a federal memo settles it.
Building a Citizen Advisory Panel That Has Teeth
The default failure mode is a panel that meets, talks, and is ignored. A panel with no defined power is worse than none, because it manufactures the appearance of legitimacy while delivering none of it, and it burns the goodwill of the people who gave up their evenings to sit on it. Those people will not come back, and they will tell others. A failed panel makes the next attempt harder, which is why building one badly is a worse outcome than not building one at all.
To build one with teeth, decide four things before you recruit anybody.
- Mandate. What can the panel actually do? Advise only? Require a written response to its concerns? Delay a launch? Veto a high-risk use? Name it in writing before recruiting members, because the answer determines who is willing to serve.
- Composition. Who sits on it, and how do you reach the people least likely to volunteer? Aisha's comment period drew vendors because vendors read government websites. Reaching tenants meant going to tenant organizations, paying members for their time, and providing childcare and translation.
- Information access. A panel that sees only a sanitized summary cannot govern. Define what they get: the data sources, the known limitations, the audit results.
- Accountability loop. What must the agency do with the panel's input? "Consider it" is meaningless. A written response on the record, within a period you commit to publicly, is real.
Be careful with that last one, because it is where agencies quietly weaken their own design. Any response period you name is a commitment you are choosing to make, not a rule you are inheriting from somewhere, and it binds you only as tightly as you let it. Whatever period you set, set it publicly, and treat a missed response the way you would treat a missed statutory deadline. The panel will learn what your commitments are worth from the first time you slip one.
A panel with a real mandate also changes who says yes. A community organization asked to nominate someone to an advisory body with no power will send a junior person or decline. Asked to nominate someone to a body that can halt a launch, it will send a leader. The mandate is not just a governance detail. It is the recruitment argument, and it determines the quality of the room.
Reaching the People Who Do Not Show Up
The people most affected by a government AI system are systematically the least likely to respond to a government process. They are working during your meeting time. They do not read the city website. They have reason not to trust the agency that is asking. They may not read the notice in the language it was written in, and they may not have a stable address at which to receive it. A process designed for people with time, transport, childcare and confidence will reach people with time, transport, childcare and confidence, and Aisha's four commenters, three of them vendors, is what that looks like in practice.
Reaching further costs money and takes a different posture. Go to organizations that already hold the trust you do not: tenant unions, community organizations, faith groups, legal aid. Meet at their times and in their spaces. Pay participants for their time, because asking people with the least slack in their lives to donate labor to your governance process is a filter disguised as an invitation. Provide childcare and interpretation. None of this is generosity. It is the cost of the process working at all, and it belongs in the project budget from the start rather than in a supplemental request after a council meeting goes badly.
Language access deserves a specific warning, because it is where a good-faith agency most often mistakes an artifact for the thing itself. Translating the notice is the beginning, not the achievement. Ask what a person can actually do in their language across the whole interaction. A person who can start an application in their language but cannot contest a denial in it has not been given access. If your engagement materials are translated but your panel runs in English without interpretation, if your comment portal accepts submissions in one language, if the person who answers the phone cannot continue the conversation, then the translation bought you a document and not a participant.
What the Panel Has to Be Able to See
Information access is the row of the design that agencies fill in last and weaken most, usually without meaning to. A panel is convened, a briefing is prepared, and the briefing is written by the same team that built the system, for an audience assumed to be non-technical, with the reasonable-sounding aim of being accessible. What arrives is a summary of what the system is meant to do. A panel that sees only that cannot govern, because every question worth asking is about the gap between what a system is meant to do and what it does.
Three things have to survive the simplification. The data sources, so that the panel can ask where the training data came from and who is missing from it, which is the question that would have caught Aisha's reporting-rate problem. The known limitations, stated as the team would state them to each other rather than as reassurance, including the populations on which performance is worst. And the audit results, in full rather than in summary, because a bias audit reported as passed tells a panel nothing about what was measured or against what threshold.
Plain language is not the same as thin content, and conflating the two is how a panel gets quietly disarmed. Explaining a priority rule in terms a tenant can act on is real work and it is worth doing. Removing the numbers, the caveats and the disagreements from that explanation is a different act, and it produces a briefing that is easy to approve and impossible to challenge. If nobody on your panel has ever asked a question the project team found difficult, the problem is more likely the briefing than the panel.
A Community Engagement Charter for an AI System
Use this charter to design engagement for any public-facing AI system before development starts. Fill it at the leadership level and attach it to the project's authorization. A blank cell is a decision you are deferring to the angry council meeting later.
Fill it at the start of the project, when the answers are cheap, and revisit it at each lifecycle moment rather than filing it once. Rows change as a system takes shape: a use that looked routine at scoping turns out to rank people, and the rung has to move up. Treat a change to the rung or the mandate as a decision worth recording, with a reason, because the drift is almost always downward and almost always unremarked.
| Element | Decision to make | Worked example (housing-inspection AI) |
|---|---|---|
| Engagement rung | Inform, consult, involve, collaborate or empower | Involve at design, empower with a veto at high-risk launch |
| Who is affected | Name the groups, including the quiet ones | Tenants, especially in low-reporting neighborhoods; landlords; inspectors |
| How you reach them | Real channels, not a website notice | Tenant unions and community organizations; paid time, childcare, interpretation |
| When you engage | Which lifecycle moments | Problem framing, design trade-offs, pre-launch, standing oversight |
| Panel mandate | Advise, require response, delay or veto | Co-set priority rules; veto launch if the bias check fails |
| Information shared | What the panel actually sees | Data sources, priority logic in plain terms, bias-audit results |
| Accountability loop | What the agency must do with input | Written public response within the period the agency commits to; changes logged |
| Success measure | How you know it worked | Design changed by community input; complaint equity gap closes |
One warning about the charter, and it applies to every artifact in this lesson. A completed charter is a plan, not an outcome. It is entirely possible to fill every cell, attach it to the authorization, execute each row, and still ship a system that no affected person influenced, because each row was satisfied in its thinnest available form. Use the success-measure row as the check on all the others. If you cannot name what changed about the system, the charter documented a process rather than producing one.
Community Technology Assessments
For higher-stakes systems, go beyond a panel to a community technology assessment: a structured process in which affected residents help evaluate whether and how a technology should be used at all, before procurement. Think of it as an environmental-impact review for an algorithm. The community examines the proposed use, the alternatives, including doing nothing or fixing the underlying process instead, the likely benefits, and the likely harms across different groups.
Done seriously, an assessment can conclude that AI is the wrong tool. That possibility is what makes it real engagement rather than a sales pitch, and it is also why assessments are so often scheduled after the procurement is effectively decided. If the contract is already shaped, the vendor already selected, or the political commitment already made, the assessment cannot reach its most valuable conclusion and everyone in the room knows it. Timing is not a scheduling detail here. It is the difference between an assessment and a briefing.
Aisha's inspection problem, examined this way, might have surfaced that the real issue was not triage speed but that some neighborhoods never reported in the first place. An AI that ranks existing complaints faster does nothing for the people who never file one. The community would have seen that on day one, because they were the people not filing. Her system optimized a process that was already excluding them, and no amount of accuracy improvement inside that process would have reached the excluded population. That is the class of insight that only comes from the affected community, and it is worth the entire cost of the assessment on its own.
The alternatives limb of the assessment is the one most often skipped and the one that carries most of the value. Comparing a proposed AI system against nothing is not an evaluation, it is a demonstration. The comparison that matters is against the other things you could do with the same money and attention: fixing the intake process, hiring, changing the rule the system would automate, or simply doing nothing and accepting the current performance. Communities are consistently better than agencies at naming these alternatives, because they experience the underlying service rather than the project, and they have no institutional stake in the answer being technology.
Making Engagement Survive You
The final leadership task is durability. Engagement that depends on one committed commissioner collapses when that commissioner leaves, and in local government that can be a single election. Embed it in structure: a standing community AI council with a charter, a budget line for participant compensation, a public commitment in the agency's AI policy, and a requirement that every new public-facing AI system file an engagement charter before authorization. When engagement is a rule rather than a favor, the next administration inherits it rather than deciding whether to continue it.
The budget line matters more than it appears in that list. Participant compensation, interpretation and childcare are the first things cut when a project runs long, and they are precisely the components that determine whether you reach anyone beyond the people who would have shown up regardless. Protecting them as a named line, rather than as a share of a project's discretionary spending, is the most reliable structural defense available to you.
The charter requirement is the other durable piece, and it works because it changes the default. When every public-facing AI system must file an engagement charter before authorization, the burden shifts from the person arguing for engagement to the person arguing against it, and that reversal survives changes of leadership in a way that enthusiasm does not. Put the requirement where authorization already happens, so that it is checked by a process that runs regardless of who is in charge, rather than in a policy document that a new administration has no particular reason to read.
When Aisha rebuilt the inspection system, she stood up a tenant-majority advisory panel with the power to halt a launch, brought them in during problem framing, and paid members for their time. The rebuilt system added a separate path to surface under-reported hazards in low-reporting neighborhoods, which the panel insisted on. It launched without a council meeting ambush. The engagement cost roughly $60,000 a year. The eight-month rebuild she did without it cost far more, in money and in trust she is still rebuilding, and the trust is the part she cannot buy back on any schedule.
Anti-Patterns
- The community meeting as consent. Holding the session, however well attended, does not mean the community agreed to what follows. Attendance is not endorsement, silence in a room is not assent, and a person who came to object and was outnumbered has not consented to anything. Agencies slip into this language almost unconsciously, describing a system as one that "the community was engaged on" in a way that implies approval nobody gave. Record what people actually said and what you actually changed, and let that stand as the record instead.
- The artifact as absolution. A completed charter, a filed impact assessment, a published response to comments and a panel with a signed roster are evidence that a process ran. They are not evidence that anyone affected influenced the system. This is the dominant failure in the domain precisely because the artifacts are what get reported and audited, so producing them feels like succeeding. Test every artifact with the same question: what is different about the system because of this?
- The translated notice as language access. Translating the notice is a first step that is routinely treated as the finish line. Access means a person can complete the whole interaction in their language, including the parts that go wrong. Someone who can start an application in their language but cannot contest a denial in it has not been given access. Audit the full path, not the entry point, and check the panel, the portal, the phone line and the appeal, not just the flyer.
- The advisory board with no defined power. Recruiting community members to a body whose mandate was never written down produces the appearance of legitimacy without any of its substance, and it spends the credibility of the organizations that nominated the members. Define what the panel can require, delay or stop before you approach anyone, and be honest if the answer is that it can only advise. Some people will still serve on an advisory-only body. Nobody forgives finding out afterwards.
- Engaging after the architecture is fixed. A consultation that opens once the model, the data sources and the decision rules are settled can only collect objections it has no capacity to act on. This is the most common form of the problem and the one that most reliably produces the launch-day ambush, because the community's substantive concerns arrive as public anger rather than as design input. If nothing about the system can still change, say so plainly and call the exercise what it is, which is informing.
- Citing the community as your justification. Using a panel's support to defend a contested decision offloads accountability onto people who had neither the authority nor the information to carry it, and it guarantees that the next panel will be harder to fill. Consultation informs a decision your agency still owns. Own it in public, including when the panel agreed with you.
- Compensation treated as optional. Asking people with the least slack in their lives to donate evenings, transport and childcare to your governance process filters your participants down to those who can afford to help you, which is close to the opposite of the intent. When the budget tightens, participant compensation and interpretation are cut first and quietly. Protect them as a named line and treat a proposal to cut them as a proposal to cancel the engagement.
Practice Prompts
- Locate your current rung honestly. Take one public-facing AI system your agency runs or is building and place its engagement on the five-rung ladder. Then find one person who would describe it differently and ask them why. The gap between your placement and theirs is the working problem.
- Run the difference test. For the most recent engagement your agency completed, write down every specific change to the system that resulted from it. Not themes raised, not concerns noted: changes made. If the list is empty, work out at which point in the lifecycle the process was opened, and whether anything was still movable at that point.
- Fill the charter for your next system. Complete every row before development starts, and pay particular attention to the success-measure row, which is the only one that cannot be satisfied by running a process. Attach it to the authorization package so that a blank cell has to be defended.
- Audit your language access end to end. Pick a language your service population uses and trace the full path in it: the notice, the application, the questions, the phone line, the panel, the denial, the appeal. Find the first point where the path breaks back into English. That break is where your access actually ends.
- Write the panel mandate before recruiting. Draft, in one paragraph, exactly what your advisory panel can require, delay or stop. Show it to a community organization you would want to nominate members and ask whether they would send someone senior. Their answer tells you whether the mandate is real.
- Cost the engagement properly. Build the line item: participant compensation, interpretation, childcare, meeting costs, staff time. Compare it against the cost of the last system your agency had to rebuild or defend publicly. Bring both numbers to the budget conversation together.
Reflection
Think about a decision your agency made recently that affected a group you do not belong to. Not an AI decision necessarily, just a consequential one. How did that group's perspective reach the room where the decision was made, if it did? Was it through someone who represented them, someone who studied them, or someone who was them? Those three routes produce very different information, and the last one is by far the rarest in government decision-making, which is why community engagement takes deliberate structure rather than good intentions.
Now examine your own instinct about this lesson. Most senior leaders read a section like this one and think about how to run engagement that is defensible: complete, documented, hard to criticize. That instinct is not wrong, but notice that it optimizes for surviving scrutiny rather than for improving the system, and that those two goals produce different designs. An engagement built to be defensible produces artifacts. An engagement built to change the system produces changes and is often messier to describe. If you had to choose, which one would your agency's incentives actually reward, and what would you have to change about your own reporting to make it reward the other?
Glossary
- Participation ladder. A five-rung scale of power-sharing running from inform, through consult, involve and collaborate, to empower, used to name honestly how much authority a given process actually shares.
- Participatory governance. An approach in which affected community voice is built into a system's whole lifecycle, at problem framing, design trade-offs, pre-launch review and ongoing oversight, rather than collected at a single gate.
- Citizen advisory panel. A standing body of affected community members convened to review an AI system, whose value depends entirely on a mandate, information access and accountability loop defined in writing before recruitment.
- Panel mandate. The written statement of what a panel can do: advise, require a response, delay a launch, or veto a use. It is both the governance definition and the recruitment argument.
- Community technology assessment. A structured pre-procurement evaluation in which affected residents examine whether and how a technology should be used, including the option of not using it.
- Engagement charter. A leadership-level planning artifact filed before development that fixes the rung, the affected groups, the channels, the lifecycle moments, the mandate, the information shared, the accountability loop and the success measure.
- Accountability loop. The defined obligation on the agency to respond to community input on the record, within a period it commits to publicly, and to log what changed.
- Language access. The ability to complete an entire interaction in one's own language, including the adverse parts such as a denial or an appeal, as distinct from the translation of a notice or an entry point.
Related Lessons
- Public Consultation on AI Policy covers the policy-level counterpart of this lesson, where the subject of consultation is a rule rather than a specific system.
- AI and Equity: Reaching All Communities goes deeper on the outreach problem of reaching populations that government processes systematically miss.
- Building and Maintaining Public Trust takes up the longer-run relationship that a single engagement either builds or spends.
- Transparency: Citizens' Right to Know addresses what you disclose about a system, which determines whether a panel can meaningfully review it.
- Ethics Boards and Advisory Structures compares the internal advisory bodies an agency convenes with the community-facing panel described here.
- Algorithmic Impact Assessments covers the assessment instrument that a community technology assessment complements rather than replaces.
Closing
The distance between Aisha's first attempt and her second is not effort, budget or sincerity. She was diligent both times. The distance is that the first process was designed to be completed and the second was designed to change something. Every structural recommendation in this lesson, the rung, the four lifecycle moments, the written mandate, the compensation line, the charter's success measure, exists to keep a well-run process from becoming a well-documented one.
The test you can carry out of here is a single question, and it is worth asking out loud in a project review where it will be uncomfortable. What is different about this system because of the people it affects? An answer means the engagement happened. A description of the process, however complete, means it did not. Everything else in this lesson is machinery for being able to answer that question with something concrete, from a leader who will still be accountable for the system either way.
Key Takeaways
- A comment period is not engagement. Know which rung of the participation ladder each AI decision deserves, and engage at that rung before the design is locked.
- Timing is the lever you control. Engagement while priority weights are still adjustable is governance; engagement after the architecture is fixed can only collect objections it cannot act on.
- A completed process establishes nothing on its own. A listening session does not confer legitimacy, an advisory board does not establish fairness, a translated notice does not provide language access, and a published response does not discharge an obligation.
- Consultation informs a decision your agency still owns. Community support is not a justification you can hide behind, and citing it that way teaches people that participating is a trap.
- Build voice into four lifecycle moments. Problem framing, design trade-offs, pre-launch review and ongoing oversight differ sharply in what they can still change, and only the first can question whether to build at all.
- Give panels real power or do not build them. Define in writing what the panel can require, delay or stop before recruiting members; the mandate is also the argument that determines who agrees to serve.
- Reach the quiet groups deliberately and pay for it. Website notices draw vendors. Reaching affected residents takes community partners, meeting them on their terms, paid time, childcare and interpretation, protected as a budget line.
- Language access means the whole path. Someone who can start an application in their language but cannot contest a denial in it has not been given access.
- Let assessments be able to say no, and make it structural. A community technology assessment that can conclude AI is the wrong tool is the only kind that is real, and a charter requirement, a budget line and a standing council let all of this survive the leader who started it.
Frequently Asked Questions
How long should a comment period or consultation run? That is not a question this lesson can answer for you, and you should be suspicious of anyone who answers it generically. Notice requirements, comment windows and consultation obligations are set by the law and policy that apply to your agency, your jurisdiction and the specific program, and they vary widely. Get the answer from your counsel and treat it as a floor rather than a target. The far more consequential question is not how long the window is but whether anything about the system can still change while it is open.
What if the community disagrees with each other? They will, and a process that produces unanimity has probably not reached far enough. Tenants and landlords want different things from an inspection system, and both are affected. Your job is not to find the consensus position but to surface the trade-off explicitly, decide it, and say publicly which interests you weighted and why. That is more defensible and more honest than presenting a contested choice as though the community endorsed it. Disagreement is information about the decision you are actually making.
Is a panel with veto power realistic for a government agency? Sometimes, and the honest constraint is legal rather than cultural. Your agency's authority may not be delegable to an external body, in which case a veto is not available to you regardless of how much you want it. What is usually available is a set of strong intermediate mandates: a required written response, a required public explanation for proceeding over an objection, or a delay that runs until a specified condition is met. These are meaningfully stronger than advice. Work out with counsel what you can actually commit to, and then commit to it in writing.
How do we engage when the system involves sensitive or security-related detail? Start by separating what genuinely cannot be disclosed from what is merely uncomfortable to disclose, because the second category is usually larger. Community members can review purpose, scope, the categories of people affected, the values encoded in a trade-off and the pattern of outcomes without seeing operational detail. Where information genuinely must be withheld, say what is being withheld and why, rather than presenting a summary as complete. A panel that knows the shape of what it is not being shown can still govern. A panel that has been quietly given a partial picture cannot.
We are small and have no budget for this. Where do we start? Start with timing, because it is free. Moving your existing engagement earlier in the lifecycle, from after design to during problem framing, costs nothing and is the single highest-return change available. Then go to one organization that already holds the trust of your affected population and ask them what would make participation possible for their members. The answer is usually smaller than you fear, and it gives you a specific, defensible budget request instead of an abstract one.
Skill.re