Privacy-preserving by default

Trust, data governance, and audit

CivicSyn is public/cooperative coordination infrastructure for essential goods and services. Local nodes coordinate demand, capacity, inventory, delivery, funding, and governance. The system recommends; people decide; every decision leaves evidence.

View public dashboardStart a pilotPartner onboardingTrust model
Food security first

The first domain connects kitchens, food banks, delivery partners, agencies, co-ops, and public reviewers around transparent allocation decisions.

  • Current picture: needs, capacity, inventory, delivery windows
  • Evidence trail: source, freshness, confidence, audit record
  • Public view: aggregate dashboards, maps, exports, outcomes
  • Human review: objections, approvals, overrides, follow-through
Public-safeResidents see aggregate information, not private case details.
Human-governedRecommendations require accountable review before action.

Public classes

1

Data classes safe to publish directly.

Aggregate-only classes

1

Partner data published only as summaries or totals.

Restricted/private classes

3

Operational, personal, or incident records requiring protected access.

Data classification policy

  • Public data public_data · public · retention policy-defined

    Safe to publish directly, including open dashboard totals, public proposal metadata, public export catalog rows, and allocation explanations.

  • Partner-confidential data partner_confidential · aggregated_only · retention 1095

    Raw partner submissions, facility details, operational notes, and source uploads are restricted to authorized partner/admin roles and public only in aggregate.

  • Operational-sensitive data operational_sensitive · restricted · retention 1095

    Allocation workflow internals, provider capacity risk, DLQ records, and admin decision evidence are limited to authorized operational roles.

  • Restricted incident data restricted_incident_data · restricted · retention 1825

    Incident-room details, participant records, and emergency response notes are restricted; public APIs expose only approved summaries.

  • Personal data personal_data · private · retention 730

    Names, emails, exact addresses, and other personal identifiers must be suppressed, hashed, or summarized before public export.

Public/private boundary

CivicSyn publishes public data directly, aggregates partner-confidential data, and suppresses personal/restricted incident details from public payloads.

The system is intentionally evidence-heavy, but public pages receive only public-safe fields and links served through API handlers.

Data-governance JSON

Evidence lifecycle intent

  • Tenant evidence area · operational_sensitive · retention 1825 days · access signed_url_only
  • Tenant evidence area · operational_sensitive · retention 1825 days · access signed_url_only
  • Failed background work records · operational_sensitive · retention 1095 days · access private
  • Decision and review evidence · operational_sensitive · retention 1825 days · access signed_url_only
  • Published public exports · public_data · retention policy-defined days · access public
  • Geospatial source data · partner_confidential · retention 1095 days · access signed_url_only
  • Planning and routing evidence · operational_sensitive · retention 1095 days · access private
  • Partner-submitted source files · partner_confidential · retention 1095 days · access private

Redaction rules

  • incident · public summary · public_safe_summary · restricted_incident_data
  • public_payload · exact address fields · suppress · personal_data
  • public_payload · email fields · suppress · personal_data
  • public_payload · private evidence references · suppress · operational_sensitive
  • public_payload · private source-file references · suppress · partner_confidential

Audit logs

Admin actions, partner reports, recommendation reviews, allocation approvals, objections, overrides, incidents, evidence reads, and agent approvals create audit rows with correlation IDs.

Human approval

CivicSyn can summarize evidence and draft decision-support explanations, but human operators approve, reject, publish, or override with reasons before operational decisions move forward.

Mobile and field-use review

Field operators, public reviewers, and residents need the same public-safe boundaries on small screens, tablets, poor networks, and no-JS map fallbacks.

  • Public pages work at 360px width without horizontal scroll.
  • Partner reporting forms are usable on a phone.
  • Incident room critical actions work on tablet.
  • Tables collapse into cards or priority rows on mobile.
  • Maps provide list alternatives and do not trap gestures.
  • Long forms have step indicators, autosave where safe, and summary review.
  • QR/share links for public dashboard, open data, proposal, and incident summary are planned.
  • Offline/poor-network behavior is graceful for partner and incident contexts.

Content quality and plain language

CivicSyn should feel practical and legible before it feels technical. Public pages explain purpose, boundaries, and next steps in plain language.

  • Every public route has a one-sentence purpose statement.
  • Every protected route has a role-specific what you can do here intro.
  • Empty states answer: why is this empty, what happens next, who can help.
  • Jargon is explained once and then used consistently.
  • Need, capacity, allocation, recommendation, proposal, incident, and evidence have consistent product definitions.
  • Error messages are specific but do not leak internals.
  • Public-benefit framing is warm, practical, and non-grandiose.

2026 product experience bar

The product should be understandable to residents, useful to operators, and accountable before it feels impressive.

  • A resident can understand CivicSyn in one screen: what is needed, what capacity exists, what changed, and who decides next.
  • Every page labels whether it is public transparency data, partner operations, restricted incident data, or admin tooling.
  • Public pages use calm, civic, practical language instead of generic SaaS claims.
  • Operator pages are action workspaces with queues, next actions, boundaries, and audit context, not raw database tables.
  • Each flow shows the next best action and explains the consequence before a person commits.
  • Data freshness, confidence, source, and limitations appear wherever people make decisions.
  • AI and agentic assistance is labeled as decision support with evidence, confidence, human approval status, and outcome learning.
  • Maps, dashboards, recommendations, and policy outputs explain themselves without API documentation.
  • Empty states are useful and launch-oriented: they explain missing data, next step, and support path.
  • Public communication supports multilingual patterns through plain headings, stable labels, and translation-ready route purpose copy.
  • The UI is comfortable on smartphones, tablets, laptops, public-meeting displays, and low-bandwidth connections.

Visual system and brand bar

The interface should look like grounded civic infrastructure: calm, legible, and explicit about public versus restricted context.

  • CivicSyn has a distinct visual identity: civic, grounded, public-benefit, not startup-template generic.
  • Color tokens support status, severity, data classification, and role context consistently.
  • Typography has a clear hierarchy for public storytelling, dashboards, data tables, and incident operations.
  • Cards, tables, filters, charts, timelines, maps, forms, and callouts use consistent spacing and density.
  • The UI distinguishes public-safe data from restricted data visually and textually.
  • Status colors never rely on color alone; labels and explanations travel with every state.
  • High-contrast mode is planned for incident rooms and dashboards through contrast media tokens.
  • Visual emphasis guides attention to decisions, risks, approvals, exceptions, and stale data.
  • Empty-state diagrams clarify civic workflows without feeling decorative or unserious.
  • Public pages avoid AI slop visuals, generic gradients, and vague civic stock imagery.

Interaction states and failure modes

Operators and residents should never have to guess whether a route is loading, empty, stale, partial, conflicted, confirmed, or blocked.

  • Loading skeletons preserve layout and explain what data is loading.
  • Timeout and error states include retry, diagnostic ID, and support path.
  • Empty states explain why no data exists, what happens next, and who can help.
  • Stale-data states show source, last update, and next refresh expectation.
  • Partial-data states say which partners, imports, or signals are missing.
  • Conflict states explain duplicate submissions, concurrent edits, or stale approvals before retry.
  • Confirmation states after writes include next action and audit or event reference.
  • Destructive-action confirmations require a reason where policy requires one.
  • No page should show indefinite loading; every wait state resolves, times out, or offers support.

Accessibility and inclusion bar

CivicSyn should work for keyboard users, screen-reader users, field operators, public meetings, multilingual audiences, and people reading under stress.

  • Public and protected pages target WCAG 2.2 AA for structure, names, contrast, focus, motion, and form feedback.
  • Keyboard navigation works across nav, filters, maps, dialogs, tables, and forms.
  • Screen-reader labels exist for charts, maps, status badges, icon-only controls, and progress indicators.
  • Tables include captions, headers, sortable state labels, and responsive card alternatives.
  • Forms include labels, helper text, validation messages, and error summaries.
  • Color contrast passes for text, controls, charts, and status pills.
  • Touch targets are large enough for mobile and field operations.
  • Language avoids stigmatizing recipients, providers, neighborhoods, or incident-affected residents.
  • Public flows account for low literacy, translation needs, and assistive technology.
  • Incident and emergency views prioritize scanability under stress.

Audit, evidence, and decision transparency bar

Trust copy should explain what evidence exists, who acted, why a decision changed, and what remains restricted.

  • Evidence availability is shown as evidence present, not as raw storage keys.
  • Audit logs are readable by humans, not just machine payloads.
  • Admin actions show before/after summaries and required reasons.
  • Recommendation approvals show objections, overrides, and final accountability.
  • Incident pages clearly separate public summaries from restricted operational details.
  • Public-source and provenance pages explain OSS obligations without overwhelming non-technical users.
  • AI decision-support pages show model/source, uncertainty, evidence, limitations, and human approval status.

Performance and resilience bar

Public and protected routes should stay useful under slow networks, partial data, failed widgets, long tables, and queue retries.

  • Public routes render quickly on mobile networks by keeping pages server-rendered, public-safe, and lightweight.
  • Critical public pages stay useful if chart or map data fails by showing list, table, summary, and support alternatives.
  • Dashboards progressively load heavy data sections instead of blocking the whole page.
  • Large tables support pagination, filtering, and export without freezing the browser.
  • Long partner and admin forms preserve drafts where safe and avoid storing restricted evidence in the browser.
  • Queue and import workflow pages show retry, replay, and DLQ status without requiring reload loops.
  • Production telemetry includes route, product, tenant, role context, outcome, and no sensitive PII.