Skip to content

The last1.org Public Accountability Information Architecture

Registry → Proof → Standards → Oversight Committees

Design Document v1.0 — September 13, 2026 Last 1 Enterprises · last1.org

The public-facing information architecture for last1.org as an arm's-length standards body. Companion to LOOP1_PROGRAM_TEMPLATE_MODEL.md (§3 the transparency layer) and the SSRN accountability standard. This spec defines three connected-but-separate public surfaces and the navigation chain that lets anyone walk the full accountability chain — from who is in the process, to what they have verified, to against what standard, to who governs that standard.

Ryan's four design decisions (2026-09-13) are locked in this spec: (1) Proof is both all-orgs and per-org; (2) oversight committees are PER-DOMAIN; (3) structure built now, governance populated later (honest placeholder states while the council is vacant); (4) the Standards library shows ALL published standards, proof shows only standards with published loops.

0. The Principle: A Navigable Accountability Chain

The public should be able to walk the entire accountability chain, surface to surface:

REGISTRY          who is in the accountability process, and where are they in it?
   │  (open an org)
   ▼
PROOF             what have they actually verified — against what standard — can I confirm the hash?
   │  (open the standard)
   ▼
STANDARDS         what is the standard — its structure — and who governs it?
   │  (the oversight committee)
   ▼
OVERSIGHT         which domain committee governs this standard, and is it certified?

No other veteran-services (or accountability) platform makes this chain public and navigable. It is the differentiator: not "we verify outcomes" but "verified outcomes, against a published standard, governed by a named committee, confirmable by anyone." Each surface is distinct; together they are the whole trust story.

1. The Three Surfaces

1.1 REGISTRY — the orgs and their standing

Answers: "who is in the accountability process, and where are they in it?"

  • Lists every organization in the standards process, with lifecycle status: applied → under review → in certification pipeline → certified.
  • Each org row: name, application type (e.g. "Certification (requested)"), status ("Under review"), IRS standing, and any conflict-of-interest disclosure (e.g. "last1.app enterprise customer — relationship disclosed on governance").
  • Honesty rules (already in force):
  • Nothing reads as "certified" while the Standards Council is vacant. Application type ("Certification requested") is distinct from a granted status.
  • is_demo orgs are excluded from the registry entirely (test data never appears as a real applicant).
  • Entry point: opening an org navigates to that org's Proof (§1.2, per-org view).
  • Data source: last1.app GET /api/public/registry/pending (is_demo excluded), merged with any known pending applications; proxied by the last1.org registry function.

1.2 PROOF — the orgs' verified outcomes

Answers: "what have they verified, against what standard, and can I confirm the hash?"

  • Two views (Decision 1 — both):
  • All-orgs overview (/proof): all published orgs and their outcomes — the proof substrate at a glance. (This is the current O0/O1/O3 page.)
  • Per-org view (opened from the registry or the all-orgs list): a single org's proof detail.
  • Progressive disclosure (built, O3): Org → Outcome Category → Verification Detail (loop id, Λ, hash chain, attestations). Org card condensed; expand for categories; expand a category for the ledger.
  • Each outcome category shows which template it ran against (the standard), linking to that standard on the Standards surface (§1.3).
  • Only shows templates/standards that have published loops (Decision 4) — contextual, not the full library. A template with no published loops (or whose only loops are small-n-suppressed) does not appear on Proof. The full library lives on Standards (§1.3).
  • Honesty rules (in force): honest denominator (failures shown — lapsed, contradicted); Stage-1 disclosure (draft standard, TEST templates, no external anchor yet, chain-linkage not full recomputation); small-n suppression at org AND category grain, with the residual disclosed (org totals may exceed shown categories because withheld small-n loops stay in the org grain — stated, not silent); is_demo shown only in a loud, labeled DEMONSTRATION section, never as real, hideable when real orgs publish.

1.3 STANDARDS — the standards and their governance

Answers: "what are the standards, who governs each, and are they certified?"

  • The library (Decision 4): shows ALL published standards/templates — the full catalog, not only ones with proof. This is the standards-body catalog ("here are the standards we publish and are developing"), distinct from Proof (which shows only standards-with-loops). So templates with no loops (e.g. the generic/demo templates) live here, TEST-labeled — they belong to the library, not to Proof.
  • Each standard/template shows:
  • Structure: phases, events (signal / output / outcome), typing, V_req (verifier roles) — the standard made visible. Collapsed by default (title + outcome class + status), expand for the phase detail.
  • Its oversight committee (§2) — which domain committee governs it.
  • Certification status — currently all "Not certified" (council vacant). Honest.
  • Plain titles — no internal dev jargon (no "I1A", "I1B", "ED standard" in public names).
  • Honesty rules (in force): TEST instruments are labeled "TEST instrument, not certified"; nothing reads as last1.org-approved while the council is vacant; is_demo templates handled per the demo-labeling rules.

2. Oversight Committees — Per-Domain Federated Governance (Decision 2)

The governance model: standards are not certified by a single monolithic council rubber-stamping everything. They are governed by per-domain oversight committees, each with the domain expertise to govern the standards in its domain.

  • Per-domain, not per-template (Decision 2): committees are organized by domain, each overseeing multiple templates in that domain. Examples:
  • Clinical / Behavioral Health Standards Committee — governs MH/BH, health, and clinical templates (connects to Mic / clinical advisors as the domain experts; ties to the MH/BH continuous-outcome model).
  • Employment Standards Committee — governs employment / job-placement templates.
  • Housing Standards Committee — governs housing-stability templates.
  • Benefits / Rating Standards Committee — governs disability-rating / benefits templates.
  • Why per-domain:
  • Credible: domain experts govern domain standards (a clinical committee governs MH/BH, not a generalist council). More trustworthy than one body certifying everything.
  • Scalable: new outcome class → new template → assigned to the existing domain committee (not a new committee per template). A domain committee governs many templates.
  • Separate, not subordinate: the Standards Council (7 category seats) is a different body from the four domain committees. Committees are working bodies: a domain standard takes force when that committee adopts it. The Council authors and ratifies the founding standard and hears petitions only (cause, deferential review, supermajority, published reasons). Do not say committees sit "under" the Council. That language implied a hierarchy the petition model forbids. The Council does not routinely edit domain standards. A committee does not occupy a Council seat.
  • Each template → exactly one governing domain committee (a template's outcome class / domain determines its committee). Shown on the Standards surface (§1.3) and referenceable from Proof.

2.1 Locked constitution (2026-09-13)

Public copy lives on /governance. Names are binding:

Term Means
Board director Fiduciary. Veto or approve a tally with a published reason. Process petition only. No voting seat on the Council or a committee.
council member Holds one of 7 Standards Council seats. Founding standard + appellate only.
committee member Seated on one of 4 domain committees. Authors/adopts that domain standard.
cohort org An organization in the accountability process.
org delegate The person who casts that org's cohort vote.
Never Bare "member." "Domain council." Treating the Council as the committees.

Seat split: 2 practitioners / 2 funders / 2 measurement / 1 person served. A Council seat is always a category seat, never "Housing's seat."

Filling: Founder-appointed and labeled until the Council has quorum (4 of 7). After quorum, nomination into a vacant category (committee, cohort org, funder, measurement body, or open call). The Council seats. Nomination is not a seat. Nominations machinery in admin waits until a committee exists to nominate.

Dual-hat: No. One standards seat per person. Org delegate is allowed (cohort vote, not a standards seat).

11th cohort org: Until 4/7, founder-invited and labeled. After 4/7: committee recommends on domain fit, Council admits on founding-standard fit, board on process only. DEMO cohort stays a separate TEST object.

Sequencing: Founding-standard ratification waits for the Council. Domain committees may seat in parallel; domain drafts can start when a committee has quorum. Domain standards take force on committee adoption. If the Council is still short of 4/7, say the appellate path is not available yet.

SSRN gap (critical path, gated): the Council ratifies the founding standard. last1.org currently publishes a teaser (SSRN 6184939) and a short v0.1 draft, not the full accountability-standard text. Integrating that text onto last1.org as the draft the Council will ratify is a real item (last1org-ssrn-founding-standard-on-site in Muster). Do not claim ratified or in force until the Council exists and votes.

Store (Gate 1): last1org-db schema scripts/last1org/schema/003_governance_roles.sql. People, seats, affiliations, typed invites, per-field consent. No nominations table.

3. The Navigation Chain (Decision 1 — both directions)

The surfaces link so the accountability chain is walkable in both directions:

Forward (discovery): 

Registry (an org, its standing)
   → open the org →
Proof, per-org (that org's verified outcomes, by category)
   → open an outcome category → the ledger detail (Λ, hashes)
   → open the standard the category ran against →
Standards (that standard's structure + its oversight committee)
   → the domain committee that governs it

Also (direct): - /proof (all-orgs overview) → open any org → its per-org proof. - Standards library → each standard → its oversight committee, and (where loops exist) a link back to the Proof showing outcomes against it.

So a funder, veteran, or auditor can start anywhere and walk the whole chain: who is in the process → what they proved → against what standard → governed by whom.

4. Structure Now, Governance Populated Later (Decision 3)

The Standards Council is vacant (0 of 7), and the per-domain oversight committees are not yet formed. So:

  • Build the STRUCTURE now: the three surfaces, the navigation chain, the per-domain committee model, the template→committee assignment — all built.
  • Populate GOVERNANCE later: seated council members and committee members, certifications, and "certified by [committee] on [date]" content are populated as the Council and domain committees seat. They may seat on different dates. Do not wait for 7/7 before seating a committee.
  • Honest placeholder states (Decision 3): while governance is unpopulated, show honest placeholders, not fake authority:
  • Oversight committee: "Domain committee: [Clinical Standards — forming]" / "Committee not yet seated" — NOT a fake list of members.
  • Certification: "Not certified — council vacant" / "Certification pending committee formation."
  • Never imply a committee has certified something when no committee exists.
  • This mirrors the existing Stage-1 honesty: the structure is real and navigable; the governance content is honestly marked as forming until it exists.
  • Gated to: the 501(c)(3) standards-body reclassification, the council seating, and O5 (the marketplace / certified templates — council-gated).

5. What Exists vs. What's New (build inventory)

Surface / piece State Build
Registry (applications page) EXISTS (honest, is_demo excluded) Extend: lifecycle statuses, org → proof entry point
Proof — all-orgs (/proof) EXISTS (O0/O1/O3, honest, small-n) Extend: per-org view, standard links to Standards
Proof — per-org view NEW Build: single-org proof detail (reuse progressive disclosure)
Standards library NEW (partial — /standards exists for the founding standard) Build: the full template/standards catalog, plain titles, collapsed, all published standards
Oversight committees (per-domain) NEW Build: the committee model, template→committee assignment, honest placeholder states
Navigation chain (the links) PARTIAL Build: registry→proof, proof→standard, standard→committee links
Governance content GATED (council vacant) Populate later; placeholders now

So it is a real multi-surface build, but much of it connects and extends what exists (registry + proof exist; the standards library, the per-domain committees, and the navigation chain are the primarily-new parts). The proof page is the anchor; the standards library + governance + navigation complete the architecture.

6. Build Increments (proposed, gated)

Each increment shippable, verified on the live site (observation, not report — the operating discipline).

  1. Standards library surface — the full published-standards catalog (all templates, plain titles, collapsed/expand, TEST-labeled). Moves the full library off Proof (Proof stays contextual). Establishes the Standards surface.
  2. Per-domain oversight committee model — the committee structure, template→committee assignment (by outcome class / domain), honest placeholder states ("committee forming / not seated"). Shown on Standards.
  3. The navigation chain — registry → per-org proof; proof category → its standard on Standards; standard → its oversight committee. The links that make the chain walkable.
  4. Per-org proof view — opening an org (from registry or the all-orgs proof) → that org's proof detail (reuse the progressive disclosure).
  5. Reconcile the surfaces' framing — Proof = "outcomes + the standard behind them" (contextual); Standards = "the full standards library + governance"; Registry = "orgs + standing." Clear, non-overlapping purposes.
  6. [Later, gated] Governance population — real council members and committee members, certifications — as the Council and committees seat. Public faces/bios/orgs are per-field opt-in. O5 (marketplace/certified) rides on this. The SSRN founding-standard text must exist on last1.org before the Council can ratify it.

7. Why This Is the Credibility Layer

Registry → Proof → Standards → Oversight is the complete public trust story, navigable by anyone: who is in the accountability process, what they have actually verified, against what published standard, governed by which domain committee. Built with honesty at every surface (failures shown, small-n protected, TEST labeled, governance honestly marked as forming), it is what turns "trust us, we verify outcomes" into "verify it yourself — walk the chain." That is the arm's-length standards body made real and public.

Document maintained by: Ryan Curry, Founder, Last 1 Enterprises Companion to: LOOP1_PROGRAM_TEMPLATE_MODEL.md, the SSRN accountability standard Governance content is structure-now / populate-later — honest placeholders while the council forms. Ties to the 501(c)(3) standards-body reclassification and O5 (marketplace/certified).