Canonical translation + inference COMMUNITY SERVICE — free translation of critically-important need requests, free inference on granted credits, landing as the post-0.6 node adapter

[emooreatx]

Note: an earlier revision of this issue framed credits as a paywall to route around, and designed a separate identity gate beside them. That was wrong on both counts — see the correction. Credits are the free-tier tracking, and the proxy becomes a node adapter post-0.6. This body reflects the corrected design.

The ask

Stand up a canonical community service with two offerings, both free at the point of use:

1. Translation of critically-important need requests — someone expresses an urgent need (safety, medical, shelter, legal, family reunification) in their own language, and it reaches whoever can help, in theirs. The barrier between a person in trouble and the help available to them should not be a language.
2. Free inference — a genuine no-cost tier for community use, not a trial funnel.

Where it lands: the node adapter, not today's proxy

CIRISProxy converts to a node adapter post-0.6 — the same shape CIRISStatus already has (ciris-server + StatusAdapter). So this should be designed to land as that adapter, not bolted onto the current HTTPS service. That is also the honest reading of CIRISProxy#3: the retirement path isn't "add CEG auth to the proxy," it's "the proxy stops being a separate service."

Credits are the mechanism — they already do the hard part

Credits are the free-tier accounting, not a paywall. The per-identity budget this needs already ships: 1 credit = 1 interaction, debited per use. A free tier is credits granted rather than purchased, on the same ledger. Nothing new has to be invented to stop the service being drained.

What the adapter conversion changes is what the account belongs to:

	subject of the credit balance
today	Google OAuth account
post-0.6 adapter	rooted federation identity

Same ledger, same per-interaction debit, different subject. And the abuse story becomes the one the mesh already has: a draining account is a known, rooted, revocable identity, and the rooting/admission gates — not us — rate-limit how fast new ones appear.

The real open question

Rooting an identity requires an onboarding path. Someone in crisis, on a borrowed phone, in a language we don't yet serve, does not have one. If the free tier requires an account, we have put the barrier back in front of exactly the person it exists for.

Two candidate answers, and I lean hard on the second for translation:

1. A low-friction rooted identity minted on the spot — small credit grant, no OAuth, attributable enough to revoke but not so heavyweight it excludes its intended user.
2. Translation is exempt from credits entirely — free, unconditional, unaccounted. It is cheap, it is high-value, and nobody drains a proxy translating text. Credits then govern only the heavier inference. The moment a person must have an account to be understood, the barrier is back.

Mistranslation is a safety property here, not a quality metric

For ordinary chat, a bad translation is annoying. For a need request, it can be the difference between someone getting help and not.

• Attest the translation. Emit it as a CEG-attested artifact bound to the producing identity, so a wrong or harmful translation is traceable and correctable. An unattributable translation in a crisis path is not acceptable.
• Always carry the source text. A human who does speak the language must be able to check it. Never let the translation become the only surviving record of what the person actually said.
• Fail loudly, not fluently. An LLM's failure mode is a confident, fluent, wrong translation. Low-confidence output must be marked and escalated to a human, not smoothed. "Sounds fluent" is precisely the wrong success signal.

No urgency classifier decides who gets served

The tempting design — classify the request's urgency, serve the urgent ones free — must be rejected. It fails in both directions, and the failures are not symmetric:

• False negative: a real need judged "not critical" and denied. This harms someone already in trouble, and they will not appeal it.
• False positive: abuse dressed as urgency gets through, and the classifier becomes an attack surface that teaches an adversary exactly what to write.

It also puts a model in the position of adjudicating whose need matters. Allocate capacity by budget; never allocate dignity by classifier. With translation free and inference budgeted, urgency never has to be judged at all.

Special-category data — a hard blocker, not a nice-to-have

A critically-important need request is GDPR Article 9 special-category content almost by definition — health, safety, immigration status, family circumstances, sometimes religion or sexual orientation. It may come from a minor.

We cannot currently handle that:

• CIRISServer#247 — Art 9 has no enforcer: mandatory subject_key_ids and the deletion_sla <= 30d default are both unenforced.
• CIRISServer#245 — no DSAR export surface: we can delete a subject's data but cannot give it to them.

This service must not be what discovers those gaps in production, with the most vulnerable users' data in it. Before launch: need-request content is subject-bearing, short-retention, ZDR (the proxy already models ZDR for search — apply it here, more strictly), never retained as training data, and the age/child-safety gates apply.

Acceptance

• A person can submit a need request in any supported language and have it translated, free, without an account, a card, or a judgment about whether their need qualifies.
• Every translation is attributable to its producer and carries its source text.
• Free inference runs on granted credits against a rooted identity — abuse is attributable and revocable, using the ledger that already exists.
• Need-request content is subject-bearing, short-retention, ZDR, never silently retained.
• No component in the path decides whose need is important enough to serve.
• Ships as the post-0.6 node adapter, on CIRISProxy#3's trust boundary.

Refs: CIRISProxy#3 (CEG/RET-native trust boundary → the adapter conversion this rides), CIRISServer#247 + #245 (blockers), CC 4.5.13 and the safety/age gates.

[emooreatx]

CORRECTION — I got the premise wrong on two counts. Rewriting the design accordingly.

1. Credits are the free-tier TRACKING, not a paywall. I wrote this as if the credit gate were a payment wall that a free tier would have to route around, and built the whole argument on "gate it by identity, not by money." That was wrong. Credits already ARE the per-identity budget I spent three paragraphs asking for. A free tier is not a second, differently-gated path — it is credits granted rather than purchased, with the same accounting. The mechanism exists; what's new is the allocation policy and who the account belongs to.

That collapses most of the "how do we stop it being drained" section: the answer is the answer that already ships. Per-identity budgets, enforced per-interaction. The open question is much narrower and much more interesting:

What is a credit account attached to, and how does a person in need get one without a Google login?

2. The proxy becomes a NODE ADAPTER post-0.6. So this should not be designed as a feature of today's HTTPS proxy — it should be designed to land as the adapter, the same shape CIRISStatus already has (ciris-server + StatusAdapter). That is also the honest reading of CIRISProxy#3: the retirement path isn't "add CEG auth to the proxy", it's "the proxy stops being a separate service."

The design that actually follows

Credits attach to a rooted federation identity, not a Google account. That is the convergence the node-adapter conversion hands us for free:

• today: Google OAuth account → credit balance → per-interaction debit
• post-0.6: rooted mesh identity → credit balance → per-interaction debit

Same ledger, same debit, different subject. The free tier is a grant of credits to a rooted identity — which means the "abuse story" is the one the mesh already has: a draining account is a known, rooted, revocable identity, and the rooting/admission gates (not us) rate-limit how fast new ones appear. No new gating mechanism needs inventing.

The real question this leaves — and it's the one worth arguing about: rooting an identity currently requires an onboarding path. Someone in crisis, on a borrowed phone, in a language we don't yet serve, does not have one. So:

• Is there a low-friction rooted identity for exactly this case — minted on the spot, small credit grant, no OAuth, attributable enough to revoke but not so heavyweight it excludes the person it exists for?
• Or is translation exempt from credits entirely (free, unconditional, unaccounted — it's cheap and nobody drains a proxy translating text), with credits reserved for the heavier inference? I still lean here for translation specifically: the moment a person has to have an account to be understood, we've put the barrier back.

What survives from the original, unchanged

• Translation free and unconditional, source text always preserved alongside the translation.
• Translations CEG-attested to their producer — a bad translation in a crisis path must be traceable and correctable, never an anonymous black-box output.
• Low-confidence output marked and escalated to a human, not smoothed. An LLM's failure mode is a confident, fluent, wrong translation; "sounds fluent" is the wrong success signal here.
• No urgency classifier deciding who gets served. Denying a real need is the asymmetric harm, and it puts a model in the position of adjudicating whose need matters. Allocate capacity by budget; never allocate dignity by classifier.
• Special-category data is still a hard blocker. A critically-important need request is GDPR Art 9 content almost by definition — health, safety, immigration status, family circumstances — and may come from a minor. CIRISServer#247 (Art 9 has no enforcer: mandatory subject_key_ids + deletion_sla <= 30d both unenforced) and CIRISServer#245 (no DSAR export surface) must land first. This service must not be what discovers those gaps in production, with the most vulnerable users' data in it.

I'll rewrite the issue body to match. Apologies for the noise — better to correct the premise loudly than to leave a wrong design standing in the tracker.