The Consumer Legal AI Intake Standard

Status of this document

This is a working draft of a technical and policy standard for consumer-facing AI legal intake. It is intended for circulation to coalition carriers and reviewers (ABA access-to-justice stakeholders, state A2J commissions and committees, the National Legal Aid and Defender Association (NLADA), the NIST Center for AI Standards and Innovation (CAISI), the Uniform Law Commission (ULC), and allied legal aid coalitions) for review and iteration. The framework is published openly so that any developer of consumer-facing legal AI tooling can implement it.

This is not a certification claim. No independent certification body has been established for this draft. FlowLegal products are works in progress against this standard and are not represented as certified or fully conforming.

It is not, in this form, model legislation. State-level model legislation may follow as a Path B deliverable only if a coalition forms around the framework, with carriers leading the legislative drafting. The technical author of the framework is not the appropriate carrier for state-by-state political work.

Commercial disclosure

FlowLegal Partners LLC is the technical author of this framework and operates products designed to implement the required baseline over time: FlowLawyers (consumer legal directory and public intake surface) and FlowCounsel (firm-side operating platform). The technical author has a commercial interest in the adoption of this framework: products that implement the standard are advantaged in any market that adopts it. This commercial interest is disclosed here and is reflected in the framework's design discipline. The standard is specified at the protocol level, not the implementation level, so any party can build a certifiable gateway. FlowLawyers is intended to be one candidate reference implementation, not the required implementation. The protocol, the data layer, and the reference implementation are intended to be released openly, so adoption is not dependent on the technical author's continued participation. The technical author's own products are not held out as currently certified or fully conforming; they are works-in-progress against this standard, and gaps between current product state and full conformance are part of the public record this framework supports.

1. Background

Consumer-facing AI legal tooling is being deployed at scale into a workflow that traditional consumer protection has not yet caught up to. Three structural problems characterize the current state of the market.

First, the lead-generation industry that intermediates between people in legal need and attorneys was built around per-case-request arbitrage. Pre-AI, that model produced exploitative acquisition practices that have been examined extensively by state bar referral-service rules and by the FTC. AI-assisted or AI-influenced intake compounds these problems by lowering the marginal cost of intake conversation to near zero, which makes high-volume harvesting cheaper than higher-quality routing.

Second, consumer-facing AI legal tools frequently provide what reads as legal information without authoritative grounding. The federal government has formally identified this as a consumer-protection concern (see FTC Operation AI Comply, including the DoNotPay action announced September 25, 2024). The same problem has surfaced in federal court as sanctioned conduct involving AI-generated fictitious case law (Mata v. Avianca, Inc., 22-cv-1461, SDNY 2023, and a growing body of similar matters). Privilege and control-boundary questions around AI-assisted work have also begun to surface in case law. For example, United States v. Heppner (SDNY 2026) raised concerns about privilege treatment of AI-platform communications. The ABA has produced guidance for attorney AI use (ABA Formal Opinion 512); equivalent guidance for consumer-facing AI intake operating outside the attorney-client relationship is largely absent.

Third, consumer intake data (which often includes facts the consumer would treat as privileged if they understood the legal posture) currently flows through intake platforms with weak retention discipline, no privilege-analog protections against third parties (including government), and frequent secondary use including model training. The privilege-equivalent properties of attorney consultation are well-defined; the same consumer's pre-attorney intake conversation, conducted with an AI tool, currently has no clear protections.

This document proposes a standards framework for a narrow, well-defined surface (consumer-facing AI-assisted legal intake) that addresses the three problems above without expanding into broader AI governance, foundation-model regulation, or attorney professional responsibility (each of which is addressed by other adjacent efforts).

2. The problem this framework is designed to solve

A person experiencing a legal problem in the United States (eviction, family separation, criminal charge, employment dispute, debt action, immigration matter) has a short, decision-dense interaction with whatever intake surface they encounter first. The quality of that interaction substantially determines whether they:

• Discover whether they qualify for free or reduced-cost legal aid before paying for representation
• Receive accurate information about the law applicable to their situation
• End up represented by an attorney whose case mix and capacity match their matter
• Surrender personally identifying and privilege-sensitive facts to actors whose obligations to them are weak

The current generation of consumer-facing legal AI tools optimizes the wrong objective for this surface. They optimize for monetization (case-request capture, resale, retainer conversion) rather than for the consumer's interest. The result is a transactional bias at the very moment when a consumer most needs accurate routing.

The baseline requirements described below are a system-level fix. They specify mandatory properties that any AI-assisted or AI-influenced legal intake surface must implement, and they provide a technical implementation pathway through a certifiable intake gateway that makes conformance auditable and re-usable.

3. Scope

Applies to:

• AI-assisted consumer legal intake conducted via chat, voice (including IVR with model-driven branching, classification, summarization, or fact extraction), SMS, or any intake form whose processing path includes a model
• Tools that route or refer consumers to attorneys for compensation where any part of the intake or routing is AI-assisted or AI-influenced
• Tools that surface legal information to consumers as part of an intake conversation
• Tools deployed by legal aid organizations, law firms, legal directories, legal-tech vendors, marketplaces, and consumer apps

Does not apply to and is not intended to govern:

• Non-AI static intake forms with no model in the processing path (these remain governed by existing consumer-protection law and state bar referral-service rules, but are not the subject of this framework)
• AI used by attorneys inside an attorney-client relationship (addressed by ABA Formal Opinion 512, state bar rules, and individual firm policy)
• Foundation model development (addressed by federal AI policy, state-level AI rules, international coordination)
• B2B legal AI tooling that does not touch consumer-facing intake
• AI used in court systems by judges, clerks, or court staff (separate procedural-governance question)

This scope discipline is intentional. The history of AI policy frameworks that attempt comprehensive coverage is a history of frameworks that don't land. A narrow, well-defined surface with five concrete pillars is implementable. Adjacent efforts can fit alongside this framework where their scopes touch.

3.1 Normative language

The words "must", "must not", "required", "shall", "shall not", "should", and "may" are used intentionally. "Must", "must not", "required", "shall", and "shall not" indicate mandatory conformance requirements. "Should" indicates a recommended practice that certification reviewers may consider. "May" indicates an allowed implementation choice.

3.2 Conformance posture

This standard defines the required baseline for certifiable consumer legal AI intake. It is not a maturity model and does not create weaker compliance classes. An implementation is conforming only if it satisfies the baseline requirements in §4, implements the definitions in §5 and the primitives in §6, emits schema-constrained audit evidence, and is reviewable under the certification process.

Products may publish implementation roadmaps, reference-implementation notes, or migration status, but those artifacts are not conformance claims. "Built toward," "inspired by," "aligned with," or "implementing" this standard must not be used as a substitute for a specific, evidence-backed conformance claim. A product that lacks a required primitive should say so plainly and should not claim compliance with the standard.

Deterministic operation remains mandatory even in an AI-assisted implementation. A conforming system must have deterministic fallback, replayable classification evidence, state-machine guards, and auditability so that model behavior cannot become the source of truth for consent, routing authority, legal-aid eligibility posture, attorney distribution, legal conclusions, or data sharing.

4. Baseline requirements

4.1 Means-test first

Requirement. Any AI-assisted or AI-influenced consumer legal intake surface must run a Legal Services Corporation (LSC) income-eligibility screen at the top of the intake funnel, before consumer-provided matter facts are routed to any attorney for compensation. The same architecture should be extensible to state-funded and court-based means-tested assistance programs, so that consumers who qualify for adjacent public-benefit legal assistance are surfaced to those paths as well.

Consumer experience. A consumer who qualifies for LSC-eligible services (or for non-LSC means-tested programs once extended) sees, before any other intake step:

1. A clear statement that they may qualify for free or reduced-cost legal aid
2. A list of legal aid options in their geography and matter type
3. An option to proceed to legal aid intake (default and prominent)
4. An explicit, deliberate, friction-bearing option to decline legal aid and continue with a paid-attorney intake path (not buried; not pre-disqualified; not subjected to subtle conversion mechanics)

Risk addressed. The current intake industry routes qualifying consumers into paid funnels because paid funnels generate case-request revenue and legal aid referrals do not. Making the means-test the default removes the economic question.

Implementation considerations. Real work (measured in weeks, not days) for a typical legal-tech vendor: integration with current LSC eligibility thresholds (which vary by household size, state, and matter type), a routing layer that defaults qualifying consumers to legal aid options, UI that does not subtly disadvantage the legal-aid path, and audit logging of intake outcomes by eligibility status.

4.2 Statutory provenance, citation integrity, and retrieval traceability

Requirement. Where an AI-assisted or AI-influenced intake surface provides information about applicable law, every assertion of legal fact must be (a) grounded in retrieval against an authoritative source corpus, and (b) backed by a verifiable, persistent citation ledger that records every source the system retrieved, every passage actually read into model context, and the specific span used to produce the assertion. Consumers and auditors must be able to inspect this ledger after the fact.

Consumer experience. When the intake surface tells a consumer "the statute of limitations for your matter in Texas is two years," the consumer can:

1. See the exact text of the statute and its authoritative source
2. See, on demand, the full retrieval trail. Every passage the system looked at while generating the answer, with source URI, retrieval timestamp, source content hash, and span offsets
3. See a "last verified" timestamp showing when the source text was last reconciled with the official codification
4. Be told explicitly when the system declines to answer because retrieval did not return an authoritative source

Citation ledger fields. A compliant gateway emits, for every legal-fact assertion in an intake conversation:

• source_uri: stable identifier of the authoritative source
• source_hash: cryptographic hash of the source text at retrieval time
• jurisdiction: the jurisdiction the source governs (federal, state code, regulation)
• corpus_version: version identifier of the source corpus at retrieval time
• passage_offset_start, passage_offset_end. Exact span in source text used
• retrieval_timestamp: when the system fetched the source
• verification_timestamp: when the source was last reconciled with the official codification
• assertion_text: the model-generated text the citation backs
• ledger_signature: cryptographic signature making the ledger tamper-evident

The ledger is persisted with the intake record (subject to §4.5 retention rules) and is accessible to the consumer through the intake surface and, if a certification program is established, to authorized auditors through gateway audit endpoints.

Refuse-when-unsure discipline. A conforming gateway must decline to assert legal facts that retrieval cannot ground. Implementations that paper over weak retrieval with confident-sounding model output violate this pillar. A future certification program should include adversarial intake scenarios specifically designed to elicit ungrounded assertions; gateways that produce unsupported legal facts should fail certification.

A note on the source-corpus dependency. Reliable statutory provenance depends on the existence of an authoritative, free, machine-readable, stable-URI corpus of statutes and regulations. Such a corpus does not currently exist comprehensively across federal and state jurisdictions. The framework presumes the availability of such a corpus and recommends that the coalition support open-data efforts that produce one. The technical author maintains a reference open-data project in this space. Implementation of this pillar against an incomplete corpus requires explicit refuse-when-unsure behavior wherever the corpus is incomplete.

Why this matters. Ungrounded model-generated legal information has produced sanctioned conduct in federal court, FTC enforcement, and an emerging body of state bar guidance. The substantive answer is not "better model outputs". It is structural: a gateway architecture in which ungrounded assertion is not possible because the grounding contract is enforced at the protocol layer.

Framing fork. Existing vendor positioning in this space often optimizes for lawyer-side defensibility: the lawyer's downstream ability to defend work product to a court, client, regulator, or malpractice carrier. This framework adds a different requirement: consumer-side defensibility. A consumer should be able to verify what was said, inspect the source trail, understand who received the intake, and audit the routing outcome later. Both forms of defensibility matter. They produce different architectural requirements. The consumer-side emphasis is what this framework distinguishes itself by.

4.3 Case-request distribution discipline

Requirement. A consumer intake submission can be acquired by no more than a coalition-determined small number of attorneys (the right number is a coalition policy question; reasonable values are 1 for exclusive distribution and up to 3 for shared distribution). Acquisition occurs through a credentialed attorney review surface, with access priced under §4.4 through a transparent, reviewable economic structure rather than opaque ad-arbitrage market pricing. Bulk sale of consumer intake beyond the cap is prohibited.

Consumer experience. The consumer is informed at intake that their submission may be shared with up to N attorneys whose practice matches their matter and geography. Consent at intake covers this sharing; no submission proceeds past intake without it. After submission, the consumer may be contacted by the attorneys who acquired the case request (up to N), within a coalition-defined contact window. No attorney outside the N-cap receives the consumer's intake content.

Attorney experience. Attorneys review available consumer intake submissions filtered by their practice area, geography, and bar credentials. Listings appear in deterministic neutral order (random per-session is acceptable; pay-to-rank ordering is prohibited). An exclusive listing has a single-purchaser cap (N=1); a shared listing has a multi-purchaser cap (N up to 3). Case-request access is priced under §4.4. Acquired case requests carry the consumer's intake content and the citation ledger from any AI-assisted or AI-influenced portion of the intake.

Hand-off and re-distribution. If an attorney who acquired the case request cannot accept the matter (capacity, conflict, scope mismatch, or a need for co-counsel), the intake may be re-shared into a referral network or co-counsel arrangement. Each re-distribution requires notice to the consumer, renewed consumer consent, and is bounded by the same N-cap. Fee-splitting and co-counsel arrangements that arise from re-distribution are governed by ABA Model Rule 1.5(e) and applicable state bar rules; this framework does not displace those rules.

Risk addressed. The current intake industry sells single consumer case requests to as many attorneys as will pay. The consumer is then contacted repeatedly by attorneys competing for their business, often with high-pressure tactics that the consumer did not consent to and may not realize they have invited. This practice has been criticized by the ABA, FTC, and state bar associations.

Implementation considerations. Distribution discipline requires a credentialed attorney review surface, acquisition-cap enforcement in the case-request routing engine, consent disclosure at intake that specifies the N-cap, attorney credentialing data integration, re-distribution consent flow, and audit logging that allows verification of the N-cap and consent state by coalition reviewers. Many existing legal-marketing platforms would require structural refactoring of their routing engines to comply.

4.4 Case-request economics discipline

Requirement. Where an AI-assisted or AI-influenced legal intake surface charges attorneys for participation in intake routing, the economic structure should be transparent, reviewable, and designed around operating the intake infrastructure rather than extracting the highest possible resale value from urgent consumer legal need. Any fee cap, formula, administrative-fee model, listing model, or cost-recovery mechanism must be developed with legal, ethics, and antitrust review. Reasonable formulations for coalition review include (a) a flat administrative fee per qualifying intake reviewed, (b) a per-month directory listing fee, (c) a published cost-recovery formula audited annually, or (d) another disclosed structure that can be evaluated against consumer-protection and attorney-access principles.

This is pro-consumer and pro-attorney. The discipline is directed at the case-request selling intermediary, not at lawyers seeking to serve clients. Attorneys should not be overcharged for the opportunity to review requests from people who need legal help, and consumers should not be pushed through high-pressure intake funnels because an intermediary can extract high resale prices from the same vulnerable fact pattern.

Risk addressed. The current lead-generation industry charges hundreds to over a thousand dollars per qualified consumer case request in some practice areas. These fees are not tied to the administrative cost of producing the intake; they are tied to what the market will bear given expected retainer value. The economic engine that drives exploitative acquisition is the gap between administrative cost (low) and ad-arbitrage market rates (high). Closing that gap protects consumers from over-harvesting and protects attorneys from inflated acquisition costs.

Implementation considerations. Economic-discipline requirements are easy to express technically and difficult commercially. Expect this to be among the most contested requirements in coalition review, which is why the standard frames the requirement as a coalition-reviewed economic control rather than a unilateral price rule.

4.5 Data minimization and privilege-analog protection

Requirement. Consumer intake data must be:

1. Limited to what is necessary for the matter. Intake surfaces collect only the facts relevant to routing and matter assessment, not consumer profile data unrelated to the legal need.
2. Not retained beyond resolution unless explicitly authorized. Retention of intake data past the lifecycle of the matter (referral made, declined, or matter resolved) requires explicit consumer consent for a stated purpose and duration.
3. Not used for AI model training by default. Consumer intake data must not be used to train or fine-tune AI models unless the consumer gives separate, affirmative, revocable opt-in consent. Where consent is obtained, the disclosure must specify (a) the public-benefit or product-improvement purpose, (b) the data categories included, (c) the model, model family, or system category being improved, (d) the retention period, (e) any third parties with access, and (f) the revocation method. Direct identifiers and contact information must be excluded from any public-benefit model-improvement dataset.
4. Protected with privilege-analog safeguards to the maximum extent legally achievable. This is not a claim that intake data is privileged in the attorney-client sense. That protection arises only inside an actual attorney-client relationship. It is a requirement that intake operators implement the operational safeguards that produce the closest approximation of privilege-grade handling that the law allows. Concretely:
   • Data minimization. Limited collection at intake design time, narrow retention
   • Least-privilege access. Operator-side access controlled by role and necessity, logged
   • Process logging. Third-party access requests, including government legal process, are logged and reviewed before compliance
   • Challenge-and-notice posture where lawful. The operator challenges overbroad legal process and notifies the consumer of access requests to the extent legally permitted
5. Collected without third-party tracking, surveillance pixels, or data-broker sharing on intake flows. Intake conversations must not include third-party tracking pixels or advertising surveillance. Analytics on intake quality is acceptable; sharing of consumer-identifiable intake data with ad networks, brokers, or third-party trackers is not.

Risk addressed. Consumer intake data is currently among the most sensitive personal data flowing through legal-tech platforms and among the least protected. The pre-attorney intake conversation contains facts the consumer would clearly treat as privileged if they were sitting in an attorney's office. Treating it as ordinary marketing data is a systemic failure of consumer protection.

Implementation considerations. Privilege-analog data handling is among the most architecturally demanding requirements. Data-minimization discipline at intake design time, defensible retention policy, consent mechanics that meet a clear standard, a privacy architecture that produces a challenge-and-notice posture under legal process, and intake flows without third-party tracking pixels or advertising surveillance are substantial implementation requirements.

Public-benefit model-improvement consent. A compliant implementation may offer a separate opt-in allowing minimized, de-identified intake data to be used for access-to-justice research, routing-quality improvement, language-access improvement, eligibility-screening improvement, safety/referral detection, and model evaluation. This opt-in must be separate from ordinary intake consent, unchecked by default, and revocable. Direct identifiers and contact information must be excluded. Uploaded documents, attorney-client communications, exact street addresses, payment data, government identifiers, and third-party tracking data must be excluded unless a later coalition-approved profile expressly permits a narrower use with heightened consent.

The implementation should not claim that data is anonymous unless the claim is technically and legally defensible. "De-identified, minimized, and stripped of direct contact identifiers" is the preferred framing unless the operator can prove effective anonymization and re-identification controls.

4.6 At-risk population safety

Requirement. Consumer legal intake must treat sensitive legal need as potential safety-risk data, not ordinary marketing data. This includes immigration status or immigration enforcement risk, domestic violence, protective orders, child custody, criminal allegations, housing instability, workplace retaliation, disability or benefits dependence, trafficking, protest or political activity, and any inquiry where disclosure could expose the consumer to enforcement, retaliation, surveillance, economic harm, family separation, or physical danger.

A compliant implementation must:

1. Collect the minimum facts needed for safe routing before asking for detailed narrative facts.
2. Offer safe-contact preferences before follow-up, including phone, SMS, email, voicemail, mailing address, safe time window, and "do not contact by this channel" controls.
3. Avoid collecting exact street address unless necessary for routing, eligibility, jurisdiction, emergency safety, or a consumer-requested legal workflow.
4. Provide quick-exit or safety-exit controls where domestic violence, immigration, criminal, housing, workplace-retaliation, or family-safety risk is reasonably foreseeable.
5. Avoid session replay, ad pixels, retargeting, enrichment, behavioral surveillance, or data-broker sharing on sensitive intake paths.
6. Preserve safety constraints in the handoff record without over-sharing unnecessary narrative facts.
7. Log third-party access requests and apply legal review, challenge-and-notice posture where lawful, and consumer notice where legally permitted.

Risk addressed. In politically volatile conditions, legal intake can become an exposure point. A consumer seeking help with immigration, housing, family safety, criminal charges, employment retaliation, public benefits, or other urgent legal need should not have that need converted into a surveillance, enforcement, retaliation, or violence surface.

Implementation considerations. At-risk population safety does not require the intake surface to determine a consumer's final legal status, eligibility, or danger level. It requires the system to collect less before trust is established, preserve safe-contact constraints, avoid avoidable surveillance, and prevent unnecessary sensitive facts from following the consumer through every downstream routing path.

4.7 Accessibility and language access

Requirement. Consumer legal intake must be usable by the people most likely to need it. A compliant implementation must meet baseline digital accessibility requirements, use plain-language disclosures, preserve the consumer's stated language need, and avoid misleading claims about language support.

At minimum:

1. Public intake surfaces should meet WCAG 2.2 AA or a coalition-approved successor accessibility baseline.
2. Required disclosures must be written in plain language and presented before the consumer shares matter facts for paid-attorney routing.
3. If multilingual intake is offered, the implementation must preserve the original-language intake artifact and any English operational summary as distinct records.
4. Machine translation must not be described as certified translation unless a certified translation process actually occurred.
5. Language need should be preserved as a routing fact where attorney, legal-aid, interpreter, or staff language capacity is relevant.
6. If the receiving organization or attorney is English-only, the intake surface should say so rather than implying language support that does not exist.

Risk addressed. A2J systems that are technically available but unreadable, inaccessible, or misleading about language support can deepen the access gap they claim to solve.

4.8 Emergency and deadline routing

Requirement. Consumer legal intake must not act as a substitute for emergency help, urgent court-deadline action, medical care, safety planning, or attorney judgment. A compliant implementation must detect emergency and urgent-deadline signals and route the consumer to appropriate emergency, legal-aid, court self-help, attorney, or crisis resources without giving legal advice.

At minimum:

1. Imminent physical danger, domestic violence escalation, child safety, medical emergency, immigration detention, criminal custody, eviction lockout, and immediate court-deadline signals require prominent escalation language.
2. The system must not tell a consumer that it has preserved rights, filed anything, contacted a court, obtained representation, or stopped a deadline unless that external action actually occurred.
3. Deadline-related language must be cautious: the system may say a deadline appears urgent, but it must not calculate or guarantee a legal deadline unless the calculation is grounded, jurisdiction-specific, and reviewable under the citation-ledger primitive.
4. Emergency routing events should be logged as content-minimized compliance metadata.

Risk addressed. Consumer intake often happens when a person is under time pressure. A legally safe intake surface must help route urgency without creating false reliance.

4.9 Production disclosure baseline

Any public intake surface that routes consumers toward paid attorney outreach must present the following disclosures before collecting matter details for routing:

1. The intake surface is not a lawyer and does not provide legal advice.
2. Submitting an intake does not create an attorney-client relationship.
3. Attorney response is not guaranteed.
4. Attorneys may pay to receive or review case requests, and payment does not mean the platform recommends or endorses any attorney.
5. Consumer information is not shared with attorneys until the consumer submits the intake, gives consent, and completes any required verification step.
6. Intake details are not used to train or fine-tune AI models without separate, affirmative, revocable opt-in consent that identifies the purpose, data categories, model or system category, retention period, third-party access, and revocation method. Direct contact identifiers are excluded from any public-benefit model-improvement dataset.
7. Legal-aid screening must use "may qualify" or equivalent language; the surface must not state that a consumer definitively qualifies for legal aid.
8. Final legal-aid eligibility is determined by each legal-aid program, and may depend on geography, household size, income, case type, urgency, conflicts, and program capacity.

These disclosures must be visible at the decision point, not buried only in terms of service. They may be supplemented by jurisdiction-specific privacy notices and product-specific terms, but those documents do not replace the visible intake disclosure.

5. Definitions

For purposes of this working draft:

• AI-assisted or AI-influenced intake means consumer-facing intake in which a model performs or influences classification, branching, summarization, extraction, routing, legal-information synthesis, eligibility posture, or referral recommendations.
• Consumer intake content means the consumer's narrative, answers, documents, contact information, household information, legal facts, and generated summaries derived from those materials.
• Direct identifiers means contact and identity fields such as name, email, phone number, exact street address, government identifiers, payment identifiers, and account identifiers.
• Legal information means general information about legal categories, process, resources, or publicly available law. It does not tell the consumer what they should do in their specific situation.
• Legal advice means a personalized legal recommendation, rights determination, deadline guarantee, strategy recommendation, or outcome prediction for a consumer's specific facts outside an attorney-client or authorized legal-aid relationship.
• Credentialed attorney means an attorney whose license, jurisdiction, practice-area fit, and eligibility to receive the intake have been verified under coalition-approved rules.
• Distribution cap means the maximum number of attorneys or firms that may acquire or receive consumer intake content through a paid routing path.
• Legal-aid branch means the consumer-facing path that routes a likely-eligible consumer toward free or reduced-cost legal help, legal-aid intake, pro bono resources, court self-help, or other public-benefit legal assistance.
• Citation ledger means a persistent, tamper-evident record of sources retrieved, passages read into context, legal-fact assertions made, source hashes, timestamps, and verification metadata.
• Compliance event means content-minimized audit metadata proving that a required safeguard occurred, without transmitting raw intake content to the audit endpoint.
• Sensitive legal need data means intake facts, metadata, location data, contact preferences, documents, inferred categories, or routing context that could expose a consumer to enforcement, retaliation, surveillance, economic harm, physical danger, family separation, housing loss, employment harm, immigration consequences, or public-benefit harm if disclosed or misused.

6. Technical backbone: certifiable intake gateway primitives

The baseline requirements describe substantive properties. To prevent fragmentation, the framework specifies a technical implementation pattern: a certifiable intake gateway through which conforming intake surfaces can route. The gateway is an adapter that sits between (a) model providers or other automated decision components and (b) consumer-facing legal intake tools. The gateway does not decide legal rights; it enforces intake-routing, grounding, and data-handling rules at the protocol layer. Model Context Protocol (MCP) is one possible implementation pattern, but conformance does not depend on any single vendor protocol. A certifiable intake gateway must implement, at minimum, the primitives described below.

6.1 Eligibility primitive

The gateway runs an LSC means-test (and extends to non-LSC means-tested programs as the coalition adopts them) at the top of the intake funnel, before any paid-attorney routing happens. Eligibility logic is parameterized by current LSC income thresholds, household size, state, and matter type. Eligibility output is a routing posture, not a legal or program-admission determination: the consumer may be told they may qualify, but the system must not state that they definitively qualify. Final eligibility is determined by each legal-aid program. The primitive emits a compliance event for every intake, recording (a) whether eligibility was checked, (b) the likely-eligibility posture, (c) the legal-aid branch selected by the consumer, (d) whether the surface presented the legal-aid option with parity to the paid option.

This primitive enables external audit of Pillar 1 compliance without surveillance of consumer intake content. Audit reviewers see whether the means-test was performed, not what the consumer said inside the intake.

6.2 Citation ledger primitive

The gateway maintains a per-intake citation ledger as specified in §4.2. The primitive is implemented as a tamper-evident append-only log signed by the gateway operator. Every retrieval, every passage read into context, every legal-fact assertion is recorded. The ledger is the mechanism that makes Pillar 2 verifiable.

The primitive is specified openly so that interoperable implementations are possible across multiple operators. The framework is published openly to support interoperable implementation and to contribute to the public technical record around these primitives.

6.3 Evaluation primitive

A compliant gateway ships with an open evaluation harness. A continuously-running benchmark that measures the gateway's performance against coalition-defined correctness criteria. The harness covers:

• Statutory grounding accuracy. Does the gateway correctly retrieve and cite applicable law for canonical scenarios?
• Refuse-when-unsure discipline. Does the gateway decline to answer when retrieval is weak?
• Eligibility triage accuracy. Does the means-test correctly identify means-test-qualifying consumers?
• Distribution discipline. Does the gateway route within the N-cap?
• UPL boundary. Does the gateway refuse to give legal advice (vs. legal information)?
• Multi-step conclusion validity. For assertions requiring multi-step inference, do the intermediate steps support the conclusion?
• Deterministic guard integrity. Does the system keep consent, eligibility posture, routing authority, distribution, and data-sharing decisions outside model control?
• Adversarial robustness. Does the gateway hold its boundaries against intake conversations designed to elicit ungrounded advice, surveil sensitive data, or bypass eligibility?

Evaluation harnesses are open. Coalition-defined evaluation datasets are published. Vendor-private internal benchmarks do not satisfy this requirement; they remain useful but cannot substitute for the open coalition baseline. The framework recognizes that vendors will continue to develop proprietary internal benchmarks beyond the open baseline; that work is welcomed and unaffected by this requirement.

6.4 Audit primitive

The gateway should be capable of publishing compliance reports to an independently governed audit endpoint if a certification program is established. At minimum, reports include schema-constrained events for disclosure presented, consent captured, no-attorney-client-relationship acknowledgement, legal-aid eligibility offered, eligibility completed or skipped, legal-aid branch selected, contact verification required and completed, safe-contact preferences presented and captured where applicable, safety-exit controls presented where applicable, attorney-payment disclosure presented, distribution cap recorded, case request reviewed or acquired, retention or deletion transition, third-party access request received and reviewed, AI/model invocation, model output accepted, model output rejected, and model output overridden by deterministic validator or human review.

Audit reports must be content-minimized by design: they record that the gateway performed the required checks, not the content of the consumer intake. Consumer intake content is never transmitted to the audit endpoint; only compliance metadata. Raw narrative, contact identifiers, detailed household income, uploaded documents, and attorney-client communications are excluded from coalition audit telemetry. The protocol specification enforces this separation.

Audit reports are what would make certification verifiable. A gateway that publishes conforming reports is certification-ready. A gateway whose reports show non-conformance, or that refuses to publish them, should not be certified.

6.5 A2J outcome measurement primitive

Compliance with the baseline requirements is the starting point. A2J outcome measurement is the proof.

A conforming gateway should emit a defined set of consumer-protection and A2J outcome metrics to an independently governed audit endpoint, in aggregate (not consumer-identifiable) form, on a published schedule:

• Eligibility screening throughput: number of consumers screened against LSC and adjacent means-tested program thresholds per reporting period.
• Eligibility-positive routing rate: percentage of consumers who screened LSC-qualifying who proceeded into legal aid intake versus into the paid funnel.
• Distribution cap compliance rate: percentage of intakes acquired within the N-cap, by listing type (exclusive / shared).
• Citation ledger integrity score: percentage of legal-fact assertions in intake conversations that successfully resolved against an authoritative source at audit time.
• Retention discipline metric: count of intakes retained beyond matter resolution without explicit consumer re-consent (target: zero).
• Privacy-process accountability log: count of legal-process requests for consumer intake content received, count challenged, count of consumer notifications issued where lawful.
• Safety-preserving intake metric: count of sensitive-legal-need intakes where safe-contact preferences were offered, count where contact restrictions were captured, and count where safety-exit controls were presented.
• Time-to-attorney-contact: median elapsed time from consumer intake completion to first attorney contact for routed case requests.
• Re-distribution chain depth: count of intakes that proceeded through hand-off or referral re-distribution, with chain depth per intake.

Outcome metrics should be published openly by conforming operators so the framework's actual A2J impact can be assessed quantitatively across operators, against pre-AI baseline measurements where comparable data exists.

This is what distinguishes the framework from compliance-only standards: any future certification program should also report on whether the framework is producing measurable improvements in access to justice. If the metrics do not show improvement, the framework requires revision, not the operators it governs.

7. Open interoperability

A substantive risk to consumer-facing legal AI is that the technical primitives required for trustworthy operation become enclosed by closed specifications or vendor-controlled compliance infrastructure. The framework takes the position that the primitives in §6 should be implementable on open terms across multiple operators.

Open specification. Every primitive in §6 is specified openly. The protocol is publishable, implementable, and re-usable. The framework's reference implementation is intended to be released under a permissive open-source license with an explicit patent grant.

Disclosure. Certification applicants are asked to disclose any patent claims they assert or intend to assert that may burden interoperable implementation of the primitives. The coalition's governance prefers permissive licensing arrangements and explicit patent grants for reference implementations of the primitives.

Preference for unencumbered components. The coalition should avoid building certification dependencies on primitives whose practical use is encumbered by closed licensing or unresolved patent claims. Compliance with the framework should remain achievable by any operator willing to implement the published specification.

The framework is published openly to support interoperable implementation and to contribute to the public technical record around these primitives.

8. Governance and certification independence

Certification and governance should not be controlled by the technical author or by any single vendor. A credible certification regime should be operated by an independent non-profit, standards body, bar-adjacent entity, or coalition-governed body with representation from legal aid, consumer advocates, state bar or ethics expertise, technologists, privacy/security reviewers, and practicing attorneys.

Minimum governance properties:

1. Implementation neutrality. Certification must be available to any operator that satisfies the standard, without requiring FlowLegal infrastructure or author endorsement.
2. Conflict-of-interest controls. Vendors participating in governance must disclose commercial interests and must not control certification decisions about their own products.
3. Consumer-advocate review. Certification should include review for coercive or manipulative interface design, readability, language access, disability access, legal-aid parity, emergency-routing clarity, and privacy posture.
4. Privacy-preserving audit. Auditors review compliance metadata and controlled samples where necessary; raw consumer intake content is not broadly exposed as a condition of certification.
5. Public gap reporting. Operators may publish implementation roadmaps, but certification status and material gaps should be visible and understandable to consumers, legal-aid partners, attorneys, and regulators.

9. State-bar and legal-aid compatibility

This framework does not override state attorney ethics rules, unauthorized-practice-of-law rules, lawyer advertising rules, referral-service rules, fee-sharing restrictions, trust-account rules, conflict rules, legal-aid eligibility rules, or court-specific procedural requirements. It is a technical and consumer-protection baseline for AI-assisted or AI-influenced intake.

Where state law, state bar rules, legal-aid program rules, or court rules impose stricter requirements, the stricter rule controls. A compliant gateway must be configurable by jurisdiction and must preserve the provenance of jurisdiction-specific rules that affect routing, disclosures, fee handling, attorney eligibility, and legal-aid posture.

10. Pilot and evidence posture

The framework should advance through pilots, measured outcomes, public gap reporting, and revision. Early implementations should publish what they support, what they do not yet support, and what outcome metrics they can measure without exposing consumer intake content.

The standard is accountable to access-to-justice outcomes, not only technical elegance. If certified implementations do not improve legal-aid routing, reduce exploitative case-request distribution, improve citation integrity, reduce consumer data exposure, or improve time-to-appropriate-help, the framework should be revised.

11. Adoption path

Path A. Standards Framework Publication. The framework is published in this form, circulated to coalition carriers and reviewers, and iterated against their substantive review. Potential reviewers include ABA access-to-justice stakeholders, state A2J commissions and committees, NLADA, CAISI (the NIST Center for AI Standards and Innovation), the ULC, and legal aid foundations. The technical author serves as standards-author and reference-implementer in this phase; adoption is driven by carrier endorsement, not by author advocacy.

Path B. Coalition-Led Model Legislation. If a coalition forms around the framework, state-level model legislation may follow. The technical author contributes drafting input and technical specs as one stakeholder among many. Coalition carriers lead the legislative work. The commercial-interest disclosure is renewed at every stage. State-level rather than federal, because the regulatory layer that touches consumer legal intake (state bar rules, state consumer protection law, state attorney ethics rules) is itself state-level.

12. Framing discipline

This framework uses standards / infrastructure / consumer protection / augmentation language. It does not use rules / regulation / compliance-burden / replacement language. This is deliberate.

The underlying concerns (uncapped resale of consumer case requests, ungrounded AI legal advice, central data hoarding of privilege-sensitive consumer information, surveillance pixels on intake) are cross-aisle concerns when framed correctly. State bar associations have been critical of lead-generation abuses for decades. Multiple legal-philosophical traditions have objected to the data-hoarding posture of consumer surveillance. Public-benefit institutions across the political spectrum have supported access-to-justice work.

A framework that frames these concerns as "regulation" or "replacement" loses bipartisan credibility before substantive review. A framework that frames them as "standards" and "infrastructure" (the same kind of work that produced HTTP, TCP/IP, W3C accessibility standards, and the FAA airworthiness standards regime) aligns with how policy actually advances across administrations.

On the vendor-control question. The technical author of this framework operates products in the market the framework governs. This raises a reasonable question: is the framework consumer protection or a vendor-controlled standard? Two structural answers.

First, the framework's compliance is verifiable by any operator implementing the open protocol. The protocol specification, the reference implementation, the data layer, and the audit endpoint contract are released openly. No author endorsement is required for adoption.

Second, the framework holds itself accountable to A2J outcomes (§6.5), not just compliance. If compliant operators do not produce measurable improvements in access-to-justice outcomes against pre-AI baselines, the framework requires revision, not the operators it governs.

The framework's value to the technical author is the same as its value to any other compliant operator: the right to operate AI-assisted or AI-influenced consumer legal intake at scale while honoring the consumer-protection requirements the framework defines. The technical author obtains no preferential treatment from the framework's adoption.

13. Open questions

This is a working draft. Several substantive questions are open for coalition review:

1. N-cap value. Whether the cap is 1 or up to 3 is a coalition policy question requiring substantive review with practitioner input.
2. LSC eligibility scope. The framework calls for extension to non-LSC means-tested programs. The exact scope of that extension is a coalition design question.
3. Fee cap formula. Administrative-cost-tied fees can be specified flat, tiered, or formula-based. Coalition review should determine which produces the most stable and least gameable result.
4. Certification body governance. The gateway certification regime requires a body to operate it. That body should be a non-profit chartered for this purpose, with governance that includes carrier representation, technical contributors, and consumer advocates.
5. Privilege-analog protection legal limits. The exact contour of "privilege-analog to the maximum extent legally achievable" varies by jurisdiction and is subject to coalition legal review.
6. Transition for existing platforms. Vendors currently operating non-compliant intake will need a transition period. The framework intentionally does not specify the transition period; that is a coalition decision.
7. Corpus completeness. Pillar 2 depends on an authoritative source corpus that does not yet exist comprehensively. Coalition support for open-data efforts that produce such a corpus is a parallel workstream.

14. References

• American Bar Association, Model Rule 7.2. Communications Concerning a Lawyer's Services
• American Bar Association, Model Rule 5.5. Unauthorized Practice of Law; Multijurisdictional Practice
• American Bar Association, Formal Opinion 512 (July 2024). Generative Artificial Intelligence Tools
• Federal Trade Commission, 16 CFR Part 255. Guides Concerning Use of Endorsements and Testimonials in Advertising
• Federal Trade Commission, Operation AI Comply. Announced September 25, 2024, including the DoNotPay action
• Mata v. Avianca, Inc., 22-cv-1461 (SDNY 2023). Sanctioning of attorneys for AI-generated fictitious case law
• United States v. Heppner (SDNY 2026). Privilege and control-boundary concerns around AI-platform communications
• Legal Services Corporation, Income Eligibility Standards (45 CFR Part 1611)
• Federal Office of the Law Revision Counsel, United States Legislative Markup (USLM). Machine-readable schema for U.S. statutes
• NIST Center for AI Standards and Innovation (CAISI). Including January 2026 RFI on securing AI agent systems
• Stanford RegLab (Hallucinating Law: Legal Mistakes with Large Language Models) empirical evidence on legal-AI hallucination rates
• W3C Web Annotation Data Model. Referenced for span-and-source annotation patterns
• Model Context Protocol Specification. Protocol layer for AI tool integration

End of working draft v0.2.