Validation status — what is real, what is still being tested
- Product, auth, and permissionsFunctional
- Accounts, private workspaces, invitations, access grants, row-level security, version history, and telemetry are built and enforced in the database — not mocked.
- Everything in the guided walkthroughsIllustrative
- Every organization, figure, and signal in the persona demos is invented to show the mechanism. No real organization appears anywhere in them.
- External market validationIn progress
- Evidence is being collected inside the product itself: decision outcomes at the end of each walkthrough, structured feedback, and pilot requests. Attesta has no onboarded institutional customers yet.
- Pricing and pilot scopesHypothesis
- The published pilot fees and annual tiers are proposals. They stay hypotheses until real institutions answer the price question or commit — nothing here should be read as proven willingness to pay.
- Payments and outbound emailExternal, pending
- Card payment and automated email delivery depend on external configuration that is not complete. Pilot one is invoiced manually, which works today.
- Legal reviewNot complete
- Agreement and data-processing language is drafted but has not been through counsel review.
The product is also the research instrument: each walkthrough ends by asking whether you could actually reach the decision, and the detailed feedback form captures pain, gaps, adoption likelihood, and willingness against the real pilot price for your persona. That is how validation is being gathered — not through interviews.
The problem
Organizational information is fragmented across portals, spreadsheets, and email threads. Every institution re-collects the same financials, board lists, and compliance documents from the same organizations, then re-assesses them from scratch. Organizations spend weeks answering the same questions; institutions still decide on stale, partial evidence and have no reliable way to monitor a relationship after the decision.
Decisions this supports
Is this borrower operationally and financially ready, and is the documentation complete enough to underwrite?
Can this grantee absorb and steward the funding, and will reporting arrive without chasing?
Is this partner credible, compliant, and low brand risk for a public program?
How do I maintain one truthful profile and control exactly which institutions can see it?
The workflow, end to end
- 1An institution brings its own network
A CDFI, foundation, or corporate team creates a private workspace over the organizations it already funds, lends to, or partners with. No directory, no marketplace, no inbound solicitation.
- 2It specifies what a decision needs
Required fields, required evidence, a refresh window, and a deadline — defined once as a campaign, then applied to everyone the institution invites.
- 3Organizations maintain one reusable profile
The organization answers once. The same evidence-backed profile is reused across every institution it has authorized, instead of being re-keyed per portal.
- 4Institutions review privately
Notes, criteria, scoring, and decisions stay inside the reviewing institution. Other institutions in the same network never see them, and neither does the organization.
- 5Staleness and gaps surface on their own
Missing required fields, expired evidence, and data older than the refresh window are flagged continuously, and update requests go back to the organization.
- 6The organization controls access
Every institution's view depends on a grant the organization gave and can revoke. Revocation takes effect immediately for future reads.
Functional, manual, illustrative, and not built
Attesta has exactly two lanes and they are never mixed on one screen. The live workspace at /network is real: real accounts, real database rows, real access control. The demonstration at /dashboard and /org/* is a scripted walkthrough on invented data. Everything below is stated plainly so you can judge the product rather than the plumbing.
- • Institution workspaces with real membership roles, enforced by row-level security in the database
- • Campaigns: required fields, required evidence, refresh window, and deadline defined once
- • Invitation links an organization can review before accepting, with expiry and single-use acceptance
- • One reusable organization profile, reused across every institution the organization has authorized
- • Completion, blocking-gap, and staleness computed against each campaign's refresh window
- • Update requests from institution to organization, and organization-proposed changes back
- • Private institutional review: notes and decisions are visible only inside the reviewing institution
- • Access grants and immediate revocation, controlled by the organization
- • Point-in-time snapshots of what an institution saw when it decided
- • Signed-out and cross-tenant isolation enforced in the database, not only in the interface
- • The /dashboard and /org/* walkthroughs are a scripted demonstration — every organization, score, and signal there is invented
- • Trust and readiness scores are illustrative, not a validated or weighted model
- • Document 'uploads' are recorded as metadata only — no file is stored or transmitted
- • Demonstration edits persist only in your browser and never touch the database
- • Exports render in the browser; nothing is generated server-side
- • Production file storage with virus scanning and signed access — evidence is metadata only today
- • Confirmed email delivery: sending is wired end to end, but the sending domain is not yet verified, so every attempt is refused with an explicit reason rather than queued or silently dropped
- • Enterprise SSO / SAML and directory provisioning
- • External data ingestion and integrations (IRS 990s, registries, credit bureaus)
- • A trained, validated, or weighted scoring model
- • Billing, notifications, and production admin tooling
- • A completed live pilot: the network layer is functional but has not yet been exercised by an external institution
- • Institution approval: a new institution workspace is reviewed and approved by hand before it can invite anyone
- • Invitation and reminder delivery: links are generated by the product, but the founder sends them
- • Briefings and pilot proposals are prepared as unlisted links shared directly with one named institution — they are not indexed, listed, or discoverable, and every one is reviewed and approved by the founder before the link is issued
- • Research and news feeds are checked only when the founder presses a button: nothing polls on a schedule, and each item is recorded as a signal or dismissed by hand
- • Verification of a claim against an external source is a human step, not an automated check
- • Pilot scoping, pricing, and the outcome memo are handled by the founder outside the product
- • A hosted Postgres database holding both the private network tables and the anonymous research tables
- • Row-level security on every network table, scoped to institution and organization membership
- • Row-level security plus database triggers on research tables: visitors may write rows but can never read them back
- • Consent enforcement in the database — contact details are blanked unless follow-up consent is given
- • Automated-traffic tagging so internal and scripted visits are excluded from live results
- • Founder-only research dashboard behind real authentication with a server-side email allow-list
- • Anonymous session identifier for your visit — no login, no name, no cookie-based tracking
- • Product events: workspace selected, guided demo started, tour steps viewed, pages viewed, tour completed or abandoned, feedback opened and submitted
- • Contextual reactions you send (Useful / Unclear / Missing something) with your optional comment
- • Whether you could reach the decision the guided demo asked you to make, plus your optional note
- • Your final feedback submission — contact details are stored only if you explicitly tick follow-up consent; without that consent they are discarded by the database itself
Who buys this, and who uses it
A CDFI, foundation, or corporate social impact team pays for Attesta because its portfolio goes stale between reviews and re-collecting evidence is manual. The institution brings its own network; Attesta never supplies counterparties.
The organization never pays. It participates because one maintained profile replaces repeated portal submissions, and because it — not the institution — controls who can see it and for how long.
What Attesta is not: not a marketplace, not a public directory, not a matching or recommendation engine, not a universal ranking, and not an automated approval. There is no way to browse organizations you have not been granted access to, and no score is comparable across institutions.
Privacy
The demonstration workspace is browser-only: the records you edit there live in local storage and disappear when you clear site data. Nothing you type into the demonstration reaches the database. Document upload is illustrative everywhere — no file you select is read, uploaded, or stored anywhere. The live workspace at /network does write to the database, but only rows scoped to workspaces you belong to, and only after you sign in. Separately, anonymous usage events and the feedback you deliberately submit are held in a research database you cannot read back. Your name and email are stored only if you explicitly tick follow-up consent; entering them without that consent is not enough — the database blanks them on write.
Please do not enter or upload sensitive, confidential, regulated, or real client data — no borrower, grantee, partner, beneficiary, or personal information. Use the seeded demo organizations instead. You may ask us to delete any feedback you submitted at any time.