Your Attributes, Your Services

A sketch of an idea we're building in Jurisdictional: find every public service that belongs to you, see what each one asks of you, notice where those questions overlap, and fill government forms the way your browser already fills everything else.

Every public service you use asks you who you are.

Your name. Your address. Your phone number. Your date of birth. Sometimes your income, your household size, your employer.

You answer the same questions again and again, on different forms, for different agencies, in slightly different ways.

Your web browser already solved a small version of this problem years ago. Start typing your address into a shopping site and your browser offers to finish it for you.

Government forms rarely get that kind of help. This post sketches how they could.


The idea in four steps

  1. Find your services. See every public service that belongs to you, based on where you live.
  2. See what each one asks for. For each service, see the information it may require from you.
  3. See the overlap. Notice which pieces of information show up across many services.
  4. Fill forms once. Keep your own set of answers, and apply them to a form the way browser autofill does.

Some of this we have built. Some of it we will build next. We’ll be clear about which is which.


Step one: find the services that belong to you

Status: built.

Jurisdictional starts from a single point on a map — usually your home address.

From that point, it finds every government whose boundaries contain you. Your city, or your county if you live outside a city. Your state. Your school district, water district, fire district, and the other special districts most people never hear about.

From those governments, it finds their agencies. From those agencies, it finds their services.

The result is a list that no single agency can give you, because no single agency knows about the others.

The same address in Vacaville, California, and one a few miles away in unincorporated Solano County, produce different lists. That difference is the whole point. Which services are yours depends on where you are.


Step two: see what each service asks of you

Status: partly built.

Each service in Jurisdictional already carries a description of how to apply, what documents are required, and who is eligible.

For a growing number of services, eligibility is also recorded in structured form — not just a paragraph of text, but rules like “age 65 or older,” “household income below 200% of the federal poverty level,” or “resident of California.”

The next step is to record the fields each service’s forms ask for. Not the answers — just the questions.

A library card application might ask for:

  • Name
  • Home address
  • Phone number
  • Email

A utility payment assistance program might ask for:

  • Name
  • Home address
  • Phone number
  • Household size
  • Monthly household income
  • Account number

A business license renewal might ask for:

  • Name
  • Business name
  • Business address
  • Email
  • Annual gross receipts

These lists are public information. They describe what the government asks, not what any one person answered. That makes them a natural fit for open data.

We aren’t starting from scratch. Touchpoints, our form platform, already records each question on a form: its wording, what kind of answer it expects, and whether it is required. The eligibility rules in Jurisdictional already name many of the facts that programs care about — age, income, household size, residency, veteran status. Bringing those two together gives each service in Jurisdictional a list of the questions it asks.


Step three: see where the questions overlap

Status: next to build.

Put the field lists side by side and a pattern appears fast.

Name, address, phone, and email show up almost everywhere. Date of birth shows up often. Income shows up in any program that depends on need, and it shows up in many shapes: monthly or yearly, before or after taxes, for you alone or for your whole household.

We call these recurring fields personal attributes — facts about you that more than one service wants to know.

Seeing the overlap is useful on its own, even before any form gets filled.

For a resident, it answers “how many times am I being asked for the same thing?”

For an agency, it answers “which of our questions could we standardize, or stop asking, because someone else already asks it the same way?”

For a city, it is a map of the paperwork burden it places on the people it serves.


Step four: fill forms once, the way your browser already does

Status: next to build.

The most familiar version of this idea is browser autofill. You’ve saved your name and address once, and your browser offers them back whenever a form asks.

Civic autofill works the same way, with two differences.

First, you can see and manage the whole set. Your personal attributes are a simple list of labels and values:

legal_name:        Jordan A. Rivera
home_address:      123 Main St, Vacaville, CA 95688
phone:             (707) 555-0134
email:             jordan@example.com
household_size:    3
monthly_income:    4,200

You can add to it, correct it, and delete from it at any time.

Second, you can see where each value goes before it goes there. Before a form is filled, you see which of your attributes it will use, and which it won’t. Nothing is sent anywhere until you choose to submit the form yourself.

There is a quiet, practical hook here, too. Web forms can already label their fields with standard names — given-name, family-name, street-address, postal-code, tel, email — so that browsers know what goes where. Many government forms don’t use them. An agency that adds those labels to its forms today gets better browser autofill for every resident, right away, with no new system at all.

Where your answers live

Jurisdictional holds the public half: which services exist, who offers them, and what they ask for.

Your answers are the private half. They should live with you — on your device, or in a place you choose — not in a central database we run.

We think that separation is the most important design decision in this whole idea. The map of questions is a public good. The answers belong to the person.

A companion to signing in

Today, services like Login.gov answer one question well: who are you? They let you prove your identity once and reuse that proof across many agencies.

Your attributes answer the next question: what do you need to tell us?

We think of the two as a pair. Your identity, and beside it, a small set of standard keys — name, address, phone, household size — with your own values attached. Sign in once, share what a service needs, and see exactly what was shared.

Either one on its own is useful. Together, we think they change how public services are delivered.


Edge cases

The simple version of this idea is easy to explain. The real version has to handle a lot of mess.

Same word, different meaning

“Address” might mean where you live, where you get mail, or where the service happens. “Name” might mean your legal name as printed on an ID, or the name you go by. “Income” might mean last month or last year, before or after taxes, yours or your household’s.

A field is not just a label. Each attribute needs a precise definition, and each form field needs to point at the right one. When we aren’t sure, we should ask rather than guess.

Information about other people

Household size, a child’s date of birth, a spouse’s income. Many forms ask about people who aren’t the person filling them out. Those people have their own interests in that information, and it shouldn’t follow you around without care.

Sensitive information

Some attributes should never fill in silently. Social Security numbers, immigration status, disability status, health conditions, criminal history. For these, the safe default is to ask every time.

Self-reported versus verified

Typing your income into a list doesn’t prove your income. Some services will accept what you say. Others need a pay stub, a tax return, or a verified record from another agency. Over time, an attribute could carry proof of where it came from — but self-reported values will always be part of the picture, and the tool should be honest about which is which.

Mistakes spread

If one wrong value gets reused across ten forms, you now have ten wrong records. Reuse makes good information go further. It makes bad information go further too.

Edges of a map

Some addresses sit right on a boundary. Some boundaries are out of date. Some services serve an area that doesn’t match any government’s borders. When we place you in the wrong district, every downstream step inherits the error.

Shared devices and unsafe households

A saved profile on a shared family computer is convenient — until the wrong person can read it. For someone leaving an abusive situation, a saved home address is a risk, not a convenience. Locking, hiding, and quickly erasing attributes are safety features, not extras.


Change

Attributes change. Services change. Both kinds of change matter.

When your life changes

You move. You change your name. You get a new job, or lose one. A child is born.

Each change touches some of your attributes, and each attribute is used by some set of services. So a single change produces a to-do list:

You updated your home address. These six services have your old address. Two of them belong to your old city and no longer apply to you. Three new ones apply at your new address.

Moving is the clearest case. A new address can mean a new city, a new county, a new school district, and a new set of services. Jurisdictional already knows how to answer “what applies here?” — it just needs to answer it twice and show you the difference.

When a service changes

Agencies revise their forms. A program adds a question, drops one, or changes how income is counted. Jurisdictional already tracks changes to the government records it holds. Field lists should be tracked the same way, so that “what does this service ask for?” always has a date attached, and old answers can be checked against new questions.

When the rules change

Eligibility thresholds move every year. The federal poverty guidelines are updated annually, and many programs follow them. A value that qualified you last year might not this year. Stored attributes need a “last updated” date, and the tool should nudge you when a value is old enough to be wrong.


Emerging rights around data use and re-use

This idea arrives at a time when people’s rights over their own information are expanding — unevenly, and in different ways in different places.

A few threads are worth watching.

The right to take your data with you

In Europe, the General Data Protection Regulation gives people a right to data portability — to get their personal data in a usable format and move it elsewhere. In the United States, a growing number of state privacy laws give residents rights to know, correct, and delete what businesses hold about them. These laws mostly apply to companies, not governments, but they are shaping what people expect from everyone who holds their information.

The right to be asked only once

Several governments have adopted a “once-only” principle: if the government already has a piece of information about you, it shouldn’t make you provide it again. Estonia built much of its digital government around this idea. The European Union has written it into rules for cross-border public services.

Civic autofill is a resident-side version of the same principle. Even where agencies can’t share with each other, the person can carry their own answers between them.

Limits on how government uses what it collects

In the United States, federal agencies have long been bound by the Privacy Act of 1974, which limits how personal records are shared and used. The Paperwork Reduction Act requires federal agencies to justify each form they use and to estimate the time it takes the public to fill out. Many states, including California, have their own laws governing how state agencies handle personal information.

These laws already treat paperwork burden as something to measure and reduce. A public map of which services ask for which fields makes that burden visible across agencies and levels of government — not just one form at a time.

Showing only what’s needed

A newer set of standards for digital credentials — like the W3C Verifiable Credentials standard, and the mobile driver’s licenses now offered by several states — make it possible to prove one fact without revealing others. You could prove you’re over 65 without sharing your birthday. You could prove you live in the county without sharing your street address.

This is where personal attributes are likely headed: not just stored and reused, but selectively shared, with proof attached.

What we think follows

We think a few things follow from all of this:

  • You should be able to see what each public service asks of you, before you start.
  • You should be able to keep your own answers, and take them anywhere.
  • You should see exactly what will be shared before anything is shared.
  • Agencies should be able to see how much they ask of people, and where they could ask less.

Where this goes next

The first three steps — find your services, see what they ask, see the overlap — are mostly a data problem. They build on public information, and they belong in the open.

The fourth step — filling forms for you — is a trust problem. It has to be built carefully, in the open, with the person in control at every step.

If you work for an agency and want to see what your services look like through this lens, or if you’re thinking about the same problems, we’d like to hear from you.