Thursday, June 18, 2026

Diogenese Docket — Court Notification System (CNS)

 

DIOGENES DOCKET — Court Notification System (CNS)

DocumentProduct Requirements Document (PRD)
Versionv0.10 — Draft (structural re-sequence)
StatusFor internal review / partner circulation
AuthorRedwin Tursor and Rhombus Ticks
IT ConsultingTC Ricks
ImprintRed Anvil Creative
DateJune 18, 2026

0. Intake and provenance

This document came out of a model pipeline. DeepSeek generated the first draft and the simulated panel. Versions 1.0 through 1.3 ran adversarial review and several multi-model passes that caught real design flaws, grounded the numbers in the published literature, and added a degraded mode for jurisdictions in counsel crisis. Version 1.4 integrates two legal-panel reviews and, importantly, a direct reading of the actual Roberts opinion, which corrected a conclusion that both panels had drawn from a real footnote but read in the wrong direction.

A note on method that has earned its place by now. Statistics supplied by reviewing models drifted between runs, which is the clearest sign they were generated rather than retrieved. Every number here is cited to a named source, and the one legal claim the whole strategy turned on was checked against the primary text before it was trusted.


1. Executive summary

Diogenes Docket is an AI-assisted court-date reminder system that reduces failure-to-appear (FTA) warrants. It resolves defendants to their hearings from public court dockets and sends reminders by email, with a physical-mail fallback. A secure feed surfaces unreachable, high-risk clients to their own counsel, never to volunteers or third parties.

One rule governs the design. AI does the work where being wrong is cheap and reversible, which means resolution and reminders. Humans do the work where being wrong is costly, which means advice, judgment, and contact about the case.

The MVP stays small: enroll, resolve, remind, and surface the unreachable. Community logistics, SMS, multi-county expansion, and a private-counsel protocol all wait behind proof that the core loop is safe and works.

Three facts shape everything below, and each is stated plainly because each one decides whether the pilot is worth running.

First, reachability runs opposite to risk. The people who drive FTA warrants are the hardest to reach, and self-sign-up enrollment makes that worse by selecting the stable and the organized. So enrollment runs through an authorized party on an opt-out basis for the channels where that is legal.

Second, the lawyer is the gate, but the gate assumes a lawyer exists. Where indigent defense functions, routing contact through counsel solves the hardest ethics problem. Where it has collapsed, the gate has no one behind it, and the system has to say what it does in that case instead of pretending it has a safety net.

Third, the operator is the defense team's agent, not a neutral vendor. That decision, explained in §1B, is what makes the privilege, the consent posture, and the loyalty all line up.


1B. Who the operator is

Every legal question in this document bends around one prior question that the earlier versions left open: when the system contacts a defendant or logs a fact about them, is the operator acting as the defense team's agent, as an arm of the court, or as an independent third party? The answer changes the privilege, the immunity, the consent analysis, and whether the data can ever be pointed at the state. Here are the three paths and the one v1.4 takes.

As an arm of the court. This buys a plausible claim to governmental immunity and makes the court the sender of record, which cleans up consent. But it makes the data a court record, which is more discoverable and often presumptively public, not less. It also forbids the operator from ever being adverse to the state, which kills the aggregate-evidence strategy in §13. This path makes the worst problem in the system worse.

As an independent third party. Rule 4.2 may not bind it at all, since the rule reaches a non-lawyer only when acting at a lawyer's direction, and it is free to be adverse to the state. But it has no privilege, no immunity, naked liability, and the weakest consent footing, because an unrelated company scraping dockets and contacting strangers is the unsolicited-contact problem in its purest form.

As the defense team's agent. This is the path v1.4 takes, for the represented population. Under United States v. Kovel, 296 F2d 918 (2d Cir 1961), privilege extends to a third party a lawyer retains to help deliver legal services. Retained by the public defender office to help it keep clients informed and present, the operator's resolution decisions about represented clients become work product the prosecution cannot simply subpoena. It also makes the Rule 4.2 worry largely disappear, because contacting the office's own clients is not third-party contact at all. And the loyalty sits where it should, with the defendant, which is exactly what the aggregate strategy in §13 needs.

The honest costs. Kovel needs an attorney-client relationship, so this protection covers only the represented. The unrepresented, the pro se, and the privately retained get the benign reminder and nothing more (see §5.3). The operator also gives up any claim to court immunity, so liability is contained another way (see §9.4). And Kovel protects communications made to enable legal advice, so an operational record has to be framed and held as part of that function, not as a generic database, or a prosecutor will argue it is an ordinary business record. The short-retention rule in §5.4 backstops this.

This is a strategic choice with real tradeoffs, not a settled legal fact. If you would rather chase court immunity, or keep the operator fully independent, say so and the architecture changes accordingly.


1A. What this is, and what it is not

This is not a robot lawyer. It is a tool that fills gaps that were never the lawyer's job.

The system only does work where an error is cheap and reversible, which is surfacing information and sending reminders. It refuses the work where an error is costly, which is advice, judgment, and representation. By construction it cannot be a lawyer, because the lawyer's function is the costly-error work the system is built to stay away from. The whole unauthorized-practice analysis in §9.1 exists to mark the line where advice begins and to stop short of it.

The gaps it fills belong to no one right now. Telling someone when their hearing is, which is a calendar fact the court already owes and which the lawyer does not track to the day for every client. Telling a public defender which of their clients are about to fall through, which the PD has the duty to handle but lacks the bandwidth to see. And telling the court and the state how many people have no lawyer and no notice, which is accountability data, not representation.

The harder criticism is not that this is a robot lawyer. It is that filling the gap makes the absence of a lawyer easier to live with and takes pressure off the state to fix it. The answer is a distinction, and it has to be stated rather than assumed. The delivery gap falls on everyone, including the well-represented, so filling it is plainly good. The no-counsel gap exists because the state failed, so filling it carelessly normalizes that failure. The system therefore fills the gaps that were never the lawyer's job, refuses the one that is, and where a person has no lawyer it does not pretend to be one. It caps itself at a reminder and turns the gap into a demand on the state for counsel, through the aggregate data in §13, rather than a quiet substitute for it.


2. Problem statement

Every year, courts issue millions of arrest warrants for missed court dates, and the burden falls hardest on low-income and minority communities. The causes are usually ordinary: a forgotten date, a changed address, no ride. Notification is unreliable, and counsel have no proactive way to see which clients are drifting toward a warrant.

What the evidence establishes, and why it shapes the design:

Reminders work, and the effect size is known. The flagship New York City RCT (Fishbane, Ouss, and Shah, Science, 2020) found that a redesigned summons form plus text reminders cut FTA by 13 to 21 percent and eliminated roughly 30,000 warrants over three years. The text-specific effect was about 26 percent (Cooke et al., ideas42 and University of Chicago Crime Lab). Practitioner syntheses cite up to about 40 percent in the best programs. A 20 percent reduction is therefore at the top of the demonstrated range, which means it is achievable but optimistic, and the metrics in §7 treat it that way.

Baseline FTA is roughly 15 to 25 percent on a defendant basis in functioning jurisdictions, higher in summons-heavy contexts. New York City criminal court fell to about 15 to 18 percent over time, Philadelphia runs about 18 to 26 percent, felony defendants about 17 percent, and Kentucky 14.8 percent. This range is an input to the power calculation in §11.

Enrollment method decides reach, and self-sign-up is the wrong choice. Automatic enrollment reaches 72 to 90 percent of eligible cases (New Mexico and Arizona). Opt-in reaches as little as 2 percent (Pennsylvania) and as much as 30 percent (Alaska) (Pew, 2025). The ideas42 Essential Guide (2025) recommends automatic enrollment with easy opt-out, because opt-in produces low participation and widens equity gaps. That finding drives the channel-specific consent model in §5.1.

Timing and message content already match the evidence. The 7-3-1 cadence is best practice. Plain-language messages that prompt the recipient to make a plan and that state the consequence of missing do better than bare notices.

A standing caution. Several figures supplied by reviewing models in earlier passes (warrant-disparity ratios, contact-invalidation rates, per-warrant cost) were uncited and shifted between runs. None are used here. Local baselines still have to be confirmed against the pilot county's own data before any number goes into a pitch.


3. Vision and core principles

Vision. Every defendant gets a timely, accurate reminder unless they decline it, and every public defender can see which of their clients are unreachable and at risk before it is too late.

Governing principle. AI where being wrong is cheap. Humans where being wrong is costly.

Design pillars.

  1. Informed default, free exit. Eligible defendants are enrolled through an authorized party on the channels where opt-out is legal, with clear disclosure and a one-tap exit honored at once. The operator never scrapes and cold-contacts strangers. Enrollment is an act of the authorized party, which is what makes the default legitimate (see §5.1).
  2. The lawyer is the gate, with a defined fallback when there is no lawyer. No one contacts a represented defendant about their case except their own counsel. For the unrepresented, Rule 4.2 does not apply and unauthorized-practice law is the binding limit, so the system sends a reminder and nothing that resembles advice (see §9.1, §13).
  3. Auditable completeness, with no dangerous residue. The ledger proves who should have been notified and who was, using hashes. It does not keep the substantive "this person was unreachable" content (see §5.4).
  4. Cheap failures, fast corrections, never silent. Errors are caught by human review, by aggregate anomaly detection, and by an urgent correction loop. A safety freeze announces itself rather than going dark (see §5.2).

4. User personas

PersonaCore needWhy they matter
Defendant, representedTell me my court date so I do not catch a warrant.Primary beneficiary, and the only population the privilege in §1B covers.
Defendant, unrepresentedI have no lawyer and no one is tracking my dates.Highest-stakes case. Reminder only, with no counsel behind the gate (§13). A defendant can move between these two states mid-case (§5.6).
Public defender / appointed counselShow me which clients are unreachable and at risk.Secondary beneficiary. The feed is their force-multiplier and the system's reach into the high-risk tail.
Authorized enrolling partyEnroll people at intake without adding burden.The legitimacy of opt-out and the high enrollment numbers both depend on this actor.
System operatorMonitor accuracy, delivery, and safety, and pause instantly on trouble.Holds the integrity of the whole thing.
Community volunteer (v1.5)Help with transport or childcare for a de-identified person.Deferred. Token-based, never sees identity.

5. MVP scope and features

5.1 Enrollment, by channel

Opt-in self-sign-up reaches 2 to 30 percent of eligible cases and widens the equity gap. Opt-out reaches 72 to 90 percent and is more equitable. So the MVP enrolls by default through an authorized party, on the channels where that is lawful, and uses opt-in only where the statute demands it.

  • Email and mail run opt-out. Contact information is collected at PD intake (and, where a court partner exists, at booking) and the person is enrolled by default, with disclosure and a one-tap exit in every message. CAN-SPAM is already an opt-out regime, so accurate headers, a working unsubscribe, a postal address, and transactional framing keep this channel clean. For PD clients, the operator acts as the office's agent (§1B), so this is the office reaching its own clients.
  • Text runs opt-in (deferred to v1.5). The TCPA and the stricter state statutes require prior express consent, and they do not care that a message is ministerial, so SMS needs an actual one-tap "yes, text me" captured at intake. Facebook v. Duguid (2021) narrowed the federal autodialer definition, and texting a curated list of verified numbers from non-autodialer infrastructure likely falls outside it, but the state statutes did not read Duguid, so get the opt-in anyway. Carrier registration (10DLC) is paperwork, not a legal defense, and the two are not the same thing.
  • Consent is scoped to the case. Enrollment ends when the case closes, and contact data is deleted then, except the hash that proves a notice was sent (§5.6, §9.3).

A note on reach and honesty. The high-yield channel runs through the PD relationship, so it serves represented clients best and the unrepresented worst, which is the same reachability gap showing up at enrollment. The MVP is, fairly stated, a represented-defendant tool first.

5.2 Resolution engine

The system runs two resolution paths because it serves two populations, and it re-runs them every cycle because the case underneath changes (§5.6).

  • Deterministic join, for the PD-client path. The office's roster, which carries the case number and the assigned attorney, is joined to the scraped hearing calendar by case number. High confidence by construction.

  • Fuzzy resolution, for the reminder path for enrollees with no roster entry.

    TierMatch basisAction
    1, auto-sendName plus date of birth plus verified contact, confidence at least 0.95Automated reminder at 7, 3, and 1 days before hearing
    2, human reviewName plus a partial matchA non-lawyer screener verifies against a second public source before mail
    3, unresolvedName only or ambiguousNo contact. Surfaced to the feed as a possible, unresolved client
  • Re-resolution every cycle. Reminders are built from the current calendar and the current counsel field. A continued hearing cancels the stale reminder and schedules the new one, and a change in representation moves the case between regimes (§5.6).

  • Data sources. Only the county's public criminal docket, throttled to roughly one request per second with backoff, a retry queue, and a dead-letter path to manual review. No login-gated systems and no CAPTCHA circumvention. The throttle is a legal control under §9.2, not only an engineering nicety.

  • Represented-status detection. The resolver reads the counsel field and labels each case as attorney-assigned, placeholder or none, or unknown. A placeholder string that stands in for "no attorney available" is treated as none, which flips the legal posture and the routing (§13).

  • Deliverability, never a risk score. This is a hard constraint. The system records that a notice could not be delivered, which is a fact about the mail. It never computes, stores, or exposes anything that reads as a judgment that the person is likely to flee. The first fact helps the defendant. The second helps a prosecutor argue for detention, so the system does not produce it.

  • Pre-send cross-check. Every notice is validated against a second public source for date, time, and place, and a mismatch suppresses the send and alerts the operator.

  • Circuit breaker with calibrated thresholds. Aggregate anomalies freeze notice generation before a batch of wrong dates can go out. Sensible defaults, tuned to each docket's own baseline rather than fixed by fiat: an unresolved-rate spike above roughly baseline plus three standard deviations or a five percent floor, a parsed-date mismatch above about ten percent, or a new-hearing count that falls below this court's historical low for that weekday, so a genuinely quiet court does not false-trigger.

  • The freeze speaks. When the breaker trips, enrollees get an affirmative message: we could not verify court dates this cycle, please check directly with the court or your lawyer. A pause must not cause the harm it exists to prevent.

  • Disclaimer on every message. This is a courtesy reminder. Your hearing may have changed. Verify with your lawyer or the court before appearing.

5.3 The feed, which ships last

The feed is the most sensitive thing the system builds, because it is a record about defendants, so it is the last component to launch, behind the benign reminder channel (§11), and it is held to the constraints below.

  • Access. Role-based login. Counsel sees only their own assigned clients.
  • Content is deliverability, not risk. The feed shows that a client was unreachable, never a flight-risk judgment (§5.2). The list is "we could not reach these people," which is a fact about the operator's outreach, not an opinion about the defendant.
  • CMS sync. A daily read-only export from the office's case-management system maps case numbers to specific attorneys. This ingests the office's own confidential roster under a data-sharing agreement, and it depends on the CMS being able to export at all, which many legacy systems cannot, so export capability is a county-selection go or no-go gate (§11).
  • Two elements, nothing more. A list of uncontactable clients with a hearing inside seven days, and a "mark as reached" action that clears the case and feeds the ledger.
  • No-counsel routing, by the recipient's duty. For a case flagged as having no counsel, identifiable data goes only to a recipient that owes the defendant a duty to assist, such as a court self-help navigator. It never goes to a recipient that owes a duty to report non-compliance, such as pretrial supervision, because that would build the surveillance pipeline this project refuses. Where no assist-duty recipient exists, the individual gets the reminder and nothing else, and only aggregate, de-identified counts leave the system, sent to the court and the state public-defense agency. That is the constructive use, and it is the opposite of feeding non-compliance to supervision (§13).
  • Privilege, where it applies. For represented clients, the resolution data sits inside the Kovel relationship (§1B), which is a real legal shield rather than an internal policy. The duty wall and the access controls are policy, and policy does not stop a subpoena, so the privilege does the heavy lifting and the rest is backup.

5.4 Completeness and access ledger

  • What it does. An append-only log of resolution decisions, state transitions, notices sent, delivery and return status, and every access to the feed.
  • What it keeps long-term. Only the hash chain, with a daily Merkle root written to a write-once store outside operator control. A Merkle root is gibberish to a prosecutor, useful only to prove nothing was altered.
  • What it purges. The substantive flags, meaning the "this person was unreachable" content, are deleted on a documented, content-neutral schedule, before any litigation hold can attach. You cannot produce in discovery a record you destroyed on a routine schedule. The completeness claim is satisfied by the hashes, which prove the notices went out, without retaining the content that could be turned against a defendant. The audit goal and the protection goal both survive, because they are met by different artifacts.
  • Access. Attribute-based, minimum-necessary fields, never publicly reachable.

5.5 Error reporting, urgent escalation, and safety shutdown

  • Inbound error channel, staffed. A phone number and email on every message, with defined hours, trained responders, and an after-hours path, because a wrong-date report the night before a hearing is an emergency a 24-hour clock cannot meet.

  • Standard correction. Within 24 hours, investigate, correct the record, send a correction, and provide a letter the defendant can show the court.

  • Emergency alert to counsel. A material defect for a hearing inside 48 hours skips the dashboard and goes straight to the assigned attorney, who can take the fastest available step, which is usually calling the clerk to recall or hold a warrant rather than filing a motion. For the unrepresented, this routes to the assist-duty recipient, or to the court's emergency contact.

  • The breaker speaks. Covered in §5.2. A freeze sends an affirmative "could not verify" message rather than going quiet.

  • Returned mail escalates. Undeliverable mail moves the client to the top of the feed, flagged as digitally unreachable with mail instability. Postal returns lag by days or weeks, so this is a standing flag on future hearings, not a same-hearing rescue.

  • Shutdown trigger.

    ElementDefinition
    Harm event(a) arrest at court after a notice that was materially wrong at send, (b) a defendant acted on our notice over a correct court communication and missed or mis-attended, or (c) a notice reached the wrong person and caused a documented adverse action.
    AdjudicationReviewed within 24 hours by the operator and a counsel liaison against a written rubric: was our record wrong at send, did the person act on our notice, is there a documented consequence. Classified as attributable, contributory, or unrelated.
    TriggerThree attributable events pause the system pending root-cause analysis. Any single systematic defect pauses it at once, regardless of count.

5.6 Case lifecycle and state transitions

A case is a process that runs for months, not a record matched once. The resolver re-checks three things every cycle.

  • Hearings move. Continuances and reschedules are normal. Reminders are built from the current calendar, a continued hearing cancels the stale reminder, and the cross-check guards a superseded date.
  • Representation changes. See the matrix below.
  • Consent ends with the case. Enrollment is scoped to the case, and contact data is deleted at close, except the hash that proves a notice was sent.
  • Everything is logged, so completeness reflects the regime in force at each send.

State-transition matrix.

From, down / To, acrossRepresentedUnrepresentedClosed or dismissed
Represented(no change)Move to the no-advice regime, re-examine whether reminders still fit, drop from the attorney's feed scope, escalation loses its recipient (§5.3)Stop reminders, purge case-tied contact data, keep only the send-proof hash (§9.3)
UnrepresentedMove to the represented regime, add to the assigned attorney's feed scope, enable counsel routing(no change)Stop reminders, purge contact data, keep only the send-proof hash
Closed or dismissednot applicablenot applicable(case is over)

Every "closed" transition keeps the send-proof hash. Deleting it would break the completeness ledger.


6. Post-MVP roadmap

VersionFeatureWhat has to be true first
v1.5De-identified community support boardHigh mail failure from address instability, and a liability-shielded, token-based partner model
v1.5SMS channel (opt-in)Email delivery below target, opt-in capture at intake, and carrier approval
v1.5Same-day missed-appearance notice on how to resolve and avoid a warrantAn evidence-based add-on that pairs with the §5.5 alert
v2.0Multi-county expansion with a reusable scraper adapterPilot reduction meets target, two more counties ask for it, and a per-state legal module is funded (see §9)
v2.0Private-counsel protocolEnough private-counsel volume, and a bar consultation
v2.0Court-order program umbrellaA judicial champion, and a positive pilot. See the caution in §9.5 about what a court order can and cannot deliver.

7. Success metrics and KPIs

MetricTargetMethod
Enrollment rateWell above opt-in's 2 to 30 percent ceiling, toward 72 to 90 percent, tracked by channelEnrollments over eligible population, anonymized
High-risk-tail coverageNo high-risk enrollee, flagged by objective docket proxies, falls through both the reminder channel and the feedCross-tab of risk proxy with delivered reminder or feed appearance
Delivery rateAt least 85 percent get one reminder before each hearing, reported by reachability segment, never as a single headlineDelivery logs
FTA reductionAt least 20 percent relative, which is the top of the 13 to 21 percent range, and only after the power calculation in §11 confirms the pilot can detect itStepped-wedge design (§9.6), with a statistician, controlling for charge severity and prior FTA
Feed engagementAt least 50 percent of counsel log in weekly and act on a caseLogin and "mark as reached" counts
State-transition fidelityContinuances and representation changes propagate within one cycle, and no reminder goes against a stale date or statusAudit of transitions against sends
Post-delivery error rateUnder 0.5 percent of notices produce a verified error that reached the defendantConfirmed mis-sends over total
Leading and guardrailResolution-confidence spread, percent continuances, percent representation changes, scraper uptime, breaker triggers, complaint rateOperational dashboards
Harm eventsZero attributableIncident log and the §5.5 trigger

Two reporting rules that are not optional. First, the easiest-to-reach enrollees are the least likely to FTA, so a clean 85 percent against an unstable population is itself a sign the funnel is selecting the wrong cohort, which is what the tail-coverage metric exists to catch. Second, a result of "20 percent reduction among enrollees" must never be read as "reminders solve FTA," because opt-out broadens the sample and improves how representative the result is, but it does not make it general.


8. Technical architecture, simplified

[Authorized enrollment: PD intake (and court booking where partnered)]
        |  email and mail opt-out, easy STOP; SMS opt-in (v1.5)
        v
[Public court portals]
        |  scraper (about 1 req/s, backoff, retry, dead-letter; robots respected)
        |  + schema assertions and a speaking circuit breaker (freeze plus notice)
        v
[Resolution engine], re-runs each cycle:
        |  deterministic join (roster against calendar)
        |  fuzzy tiers 1, 2, 3
        |  represented-status: assigned / none / unknown
        |  state transitions (hearing / counsel / closure)
        |  deliverability only, never a risk score
        v
[Ledger]                         [Notification service]
 hash-chained, append-only        email (opt-out; SPF, DKIM, DMARC; shared pool)
 transitions logged               mail (batch; returned-mail webhook)
 substantive flags purged         speaking "could not verify" notice on freeze
 daily Merkle root to WORM
        |
        v
[Feed], ships last:
 own clients only; deliverability not risk; CMS-synced attorney mapping;
 no-counsel routing by recipient duty (assist gets PII, report gets aggregate only);
 represented-client data inside the Kovel relationship

Email runs on SPF, DKIM, and DMARC with bulk-sender compliance, on a reputable shared transactional pool rather than a dedicated IP, because pilot volume is too low to warm a dedicated IP. The data-model entities (Defendant, Case, Hearing, Attorney, Notification, LedgerEvent, StateTransition) are a sketch here. The full schema and the API contracts belong in the technical design doc, not the PRD.


9. Legal and ethical framework

9.1 Attorney ethics, and why the operator's identity settles it

For the PD-client population, the operator is the office's agent (§1B). Contacting the office's own clients is not third-party contact, so Rule 4.2 is not implicated, and the resolution data sits inside attorney work product under Kovel. The earlier plan gated the reminder channel on a state-bar advisory opinion about the ministerial-notice theory. That gate is downgraded. A bar opinion is slow, often declined for novel prospective systems, and, more to the point, it does not reach the statutes in §9.3 that actually govern the message. The agent structure does more work than the opinion ever would.

For the unrepresented, Rule 4.2 does not apply, because there is no represented party. The binding limit is unauthorized-practice law, which means a reminder and nothing advice-like. There is a real tension here that earlier versions created and did not flag. The evidence-backed message content (make a plan, here is the consequence of missing) is more effective precisely because it is more advice-like, and delivered to an unrepresented person with no lawyer to verify with, it is the content a UPL regulator looks at hardest. So for the unrepresented, the message is stripped to the bare date, time, and place, plus a referral to an assist-duty resource (§13), and it drops the plan-making and consequence language that is fine for the represented.

Because representation can change mid-case (§5.6), the applicable rule is re-checked at each transition rather than fixed at enrollment.

9.2 Scraping, with the right body of law in view

Only public, non-login docket data is collected. After Van Buren (2021), federal CFAA exposure for public data is minimal. But the federal CFAA is not the law that governs the pilot. Two corrections to the earlier analysis. First, hiQ v. LinkedIn won on the CFAA and then lost on the contract claim on remand, so the residual exposure is breach of the portal's terms of service, not a footnote, and that is where a challenge actually lands. Second, state computer-crime statutes are frequently broader than the CFAA, some lack any Van Buren-style narrowing, and some reach terms-of-service violations directly. So the pre-launch review covers the portal's terms and the state statute, not only the CFAA, and robots.txt is respected, or the reason it is not is documented, because "where feasible" is a hedge a plaintiff will use to argue the operator knew it lacked authorization.

9.3 Consent, which is three statutes, not one ethics rule

The single biggest legal error in earlier versions was stretching one ethics concept, the ministerial notice, across three separate bodies of law. They are separate, and each is handled on its own terms.

  • CAN-SPAM governs the email channel. It is already an opt-out regime, so the email MVP is the least of the consent problems. Accurate headers, a working unsubscribe, a postal address, and transactional framing, and it is essentially clean.
  • The TCPA governs the SMS channel in v1.5. The ministerial-notice idea is an ethics-rule theory, and the TCPA does not care about it. Duguid helps on the autodialer prong if the system texts a curated, verified list, but a prerecorded or AI voice is a separate prohibition Duguid does not touch, and Barr v. AAPC (2020) struck the government-debt carve-out, so "it is a court message" buys no federal exemption. SMS therefore runs opt-in.
  • State mini-TCPAs, such as Florida's FTSA, are the real landmine. Several define autodialer more broadly than the post-Duguid federal standard, impose their own consent requirement, and carry private rights of action with statutory damages. Under a strict state statute, opt-out may not be the prior express consent the text channel needs, which is the second reason SMS runs opt-in. The multi-county roadmap therefore requires a per-state statutory review, and that cost is now in the model (§14).

9.4 Liability, named and contained

The exposure is voluntary-undertaking negligence, Restatement (Second) of Torts §323. By taking on the job of reminding people, with no prior duty to do so, the operator assumes a duty to do it with reasonable care, and is liable if its negligence either increases the risk of harm or causes harm through the person's reliance. The silent-freeze problem is the reliance prong, exactly. Disclaimers do not bar negligence, they are evidence on reliance and comparative fault, and opt-out enrollment removes the one signed artifact that might have helped, so there is no waiver to invoke. The containment is structural, in three parts.

  • Additive, not replacement. Every message supplements the court's official notice and never replaces it, and it never tells anyone to rely on the system instead of the court. If the channel fails, the defendant is exactly where they would have been without it, which defeats the increased-risk prong.
  • The speaking circuit breaker. A freeze that announces itself does not manufacture reliance, which answers the reliance prong (§5.2).
  • A risk pool, not a policy nobody will sell. E&O for a novel, liberty-harm, criminal-justice-adjacent risk written for a thinly capitalized nonprofit may be unavailable or gutted by exclusions, so folding the program into the county's existing risk pool is a condition of the partnership. The county that pockets the savings on every averted warrant carries the risk that comes with it.

9.5 What a court order can and cannot do

A standing court order or local rule is genuinely useful. It can make the court the sender of record, which eases the consent posture, and it can carry an evidentiary shield that bars the use of program data in bail, detention, or charging decisions and makes it non-discoverable, the way mediation-privilege statutes and pretrial-services rules already do in many places. Pursue it.

But two cautions, because the earlier framing oversold it. A single judge's order may not bind other judges, prosecutors in other cases, or survive appeal, so its scope is uncertain. And it does not automatically hand a private operator the court's immunity. Immunity for private actors performing government functions is genuinely mixed: extended to a private lawyer doing government work in Filarsky v. Delia, denied to private prison guards in Richardson v. McKnight, and decided on the specific facts. So the order is leverage worth chasing, but it relocates risk rather than erasing it, and the design does not assume the immunity arrives. The privilege in §1B and the containment in §9.4 stand on their own.

9.6 Evaluation ethics, and the contamination versus power tradeoff

A withheld control would deny a beneficial reminder to some enrollees, which is a moral choice, so the pilot uses a stepped-wedge rollout where everyone is eventually enrolled. Contamination control is required but not free. Randomizing by counsel team leaks treatment, because attorneys share a bullpen and defendants share a waiting room, which biases the result toward null. The fix is a more macroscopic unit, such as separate courtrooms, branch offices, or sub-jurisdictions, rather than internal teams. But a more macroscopic unit means fewer clusters, and stepped-wedge power runs on cluster count, so it makes the power problem worse. The statistician resolves the tradeoff numerically, possibly by pooling counties to get enough well-separated clusters.

9.7 Privacy and data security

The architecture is a high-value target and a single point for subpoenas and records requests, so two things are true. First, tamper-evidence is not confidentiality. The hash chain proves data was not altered, and it does nothing against exfiltration, so a breach of defendant locations and flags is close to a worst case for safety, with breach-notification statutes and negligence exposure on top. Second, access controls govern internal users, not legal compulsion, so the real protections are the ones that change what data exists and who holds it: deliverability rather than risk scores (§5.2), short retention of substantive flags (§5.4), and the Kovel privilege for the represented (§1B). The duty wall is an ethical default, not a legal control.


10. Risk register

#RiskLikelihoodImpactMitigationOwner
R1Enrollment too lowMedium (opt-out cuts it)HighOpt-out at the authorized touchpoint, QR residual only, benchmark to the 72 to 90 percent evidence, instrument by channelBob
R2Reachability and severity skewHighHighFeed as the tail channel, opt-out reduces the enrollment skew, segment all reportingEve
R3Scraper breaks or quietly corrupts dataHighHighPer-record cross-check plus a calibrated, speaking circuit breaker, daily health checkAlice
R3aThe feed becomes a flight-risk exhibit, subpoenable and usable against the defendantHighCriticalDeliverability not a risk score (§5.2), Kovel privilege for the represented (§1B), short-retention purge (§5.4), ships last (§11), and an evidentiary shield in the court order where obtainable (§9.5)Carol
R4Authorized party cannot absorb enrollment or does not use the feedMediumHighOne field plus a checkbox at intake, co-design, embed in the existing CMS, a feed championEve
R5Negligence claim (§323) when a notice is wrong, late, or missingMediumHighAdditive design, the speaking breaker, the county risk pool, not disclaimers (§9.4)Carol
R6Carceral-surveillance criticismMediumMediumThe §1A positioning, transparency, community pre-brief, the assist-versus-report wall, and the aggregate-as-evidence strategy (§13)Carol
R7Statutory consent failure on SMSMediumHighSMS runs opt-in, per-state review, no reliance on the ministerial theory or on 10DLC (§9.3)Carol
R8Biased model in future tiersLow (MVP uses none)HighNo risk model in the MVP, any future model rule-based and auditedCarol
R9CMS sync failsMediumHighA data-sharing MOU in month one, a manual CSV fallback. Export capability itself is a selection gate (§11).Dave
R10Crisis jurisdiction: no counsel to route to, and a risk of routing identified data to a report-duty actorSite-dependentHighRepresented-status detection, the assist-versus-report wall, prefer a functioning-defense pilot county (§13)Carol
R11Pilot underpowered, worsened by the selection-depressed baseline and by macroscopic clusteringMedium to HighHighPower calculation on the selection-aware baseline, fallback to pooling counties or a delivered-before-hearing primary endpoint (§9.6)Carol
R12Email deliverability failureMediumHighSPF, DKIM, DMARC, bulk-sender compliance, shared pool, complaint monitoringAlice
R13Stepped-wedge contaminationMediumHighA macroscopic randomization unit, with the power cost resolved by the statistician (§9.6)Carol
R14Stale case state, a send against a superseded date or changed statusMediumHighPer-cycle re-resolution, the transition matrix, the fidelity metric (§5.6, §7)Alice
R15Reliance harm from a silent freezeMediumHighThe speaking circuit breaker (§5.2)Alice
R16Open-records exposure on handoffMediumHighHand off code only, never the dataset; the operator retains and purges the data (§14)Carol

R3a is the one the prior versions underrated. It is rated critical on purpose.


11. Timeline and milestones, with the sequence reversed

The earlier plan launched the feed first because it looked clean on Rule 4.2. That was backwards. The reminder channel is the benign piece, a calendar notice, and the feed is the data product about defendants. So the reminder ships first, and the feed ships last, after the hardest scrutiny.

Critical path: secure the partner county (with the CMS-export and functioning-defense checks), confirm the operator-as-agent structure with the office and its insurer, complete the power calculation, build and ship the reminder channel, then build the feed last. Legal work (Carol) runs in parallel with the build (Alice and Dave). Add a 20 percent buffer on the legal milestones, because those timelines slip.

MilestoneTargetOwnerGate
Partner county secured, with CMS-export and functioning-defense checksMonth 1Bob, EveGo or no-go on the feed
Operator-as-agent structure agreed with the PD office and its risk poolMonth 1CarolSets the privilege and the liability posture
Scraping review (state computer-crime law plus portal terms)Month 1.5CarolBlocks scraper go-live
Power calculation, on the selection-aware baseline, resolving the cluster unitMonth 1.5Carol, statisticianBlocks the eval design
Reminder channel built (resolver, opt-out email and mail, speaking breaker)Month 2.5Alice, BobShips first
Ledger MVP (hashes, transitions, purge schedule, external Merkle root)Month 3Dave
Reminder channel soft launchMonth 3.5EveThe benign piece goes live
Feed built (deliverability only, CMS sync, duty-walled routing, Kovel framing)Month 4.5Dave, EveShips last, after scrutiny
Stepped-wedge design locked, macroscopic unit, statistician-confirmed powerMonth 4.5CarolBlocks the eval
UAT and safety red-team, including breaker tuning and a subpoena tabletopMonth 5All
Full pilot data collectionMonths 6 to 11All
Post-pilot evaluation, and the handoff decisionMonth 12All

12. Open questions and dependencies, by gate

Go or no-go, month 1, these block the pilot.

  1. County selection: functioning indigent defense (not in crisis), CMS export capability, a scrapable CAPTCHA-free docket, and a willing, capable PD office, which is closer to a gate than a tiebreaker, because the agent structure, the enrollment, and the feed all depend on it.
  2. The operator-as-agent structure: will the PD office retain the operator as its agent, and will its risk pool take the program.
  3. Power calculation: plug in realistic enrollment, the selection-aware baseline, and a top-of-range effect, and pick the fallback before building if it comes back underpowered.
  4. CMS export capability: confirmed in writing before selection.

Design decisions, month 2. 5. The enrolling party for the non-PD population: court booking, a residual QR, or both. 6. An assist-duty recipient for the unrepresented: does the jurisdiction have a navigator or self-help program with a duty to assist. If only report-duty actors exist, identified routing is off and the design defaults to aggregate plus the reminder ceiling. 7. The stepped-wedge unit: the statistician optimizes against contamination and cluster-count power, possibly pooling counties. 8. Refresh cadence: how often to re-scrape counsel status and the calendar to keep transitions inside one cycle. 9. Breaker calibration: baseline variance per docket, tuned in UAT. 10. Mail and email infrastructure: variable-disclaimer batch printing, a returned-mail feed, a shared transactional pool, and authentication. 11. The risk-pool arrangement: the terms on which the county absorbs the program's liability. 12. Sustainability and ownership: see §14. 13. The court-order pathway: the evidentiary point to seek an order, and a realistic read of what it delivers (§9.5).


13. Stress-test case study: a jurisdiction in counsel crisis (Oregon), corrected

Why this is here. The central pillar, the lawyer is the gate, holds only where indigent defense functions. Oregon is the strongest test of what the system does when that fails at scale, and reading the actual opinion corrected a conclusion the panels got backwards.

The facts, verified against the opinion. Oregon has been in a multi-year public-defense collapse, with thousands of unrepresented defendants concentrated in a handful of counties. On February 5, 2026, in State v. Roberts, 374 Or 821 (2026), the Oregon Supreme Court held that dismissal without prejudice is required when, at any point after arraignment, the state fails to provide counsel for more than 60 consecutive days in a misdemeanor case or 90 in a felony case. Within days, more than 1,400 cases were dismissed. When no attorney is available, the trial court appoints "OPDC," the public-defense commission, as a placeholder, which the court itself held is not a real appointment, so the counsel field on the docket can read "OPDC" while meaning no lawyer.

The correction that matters. The opinion's footnote 15 says, in plain words, that dismissal is not required if, during the 60 or 90 day window, the defendant failed to appear as required. Read that against this product. To get the Roberts dismissal, the unrepresented defendant must not have missed court during the window. Appearance is the precondition for the remedy, and a missed appearance forfeits it, and adds a fresh FTA charge and a warrant on top. So a reminder that keeps an unrepresented defendant appearing protects the remedy. It does not defeat it. The earlier instinct, to switch the appearance function off in crisis jurisdictions as a matter of fiduciary care, was the opposite of fiduciary, because going dark would let the client miss court and lose the one remedy the violation hands them. The function stays on, and it is paired with a referral to an assist-duty advocate so the defendant can claim the dismissal affirmatively rather than just accruing days.

What the architecture still has to do here. The feed has no counsel to route to, so the no-counsel fallback in §5.3 applies: assist-duty recipient if one exists, otherwise the reminder and aggregate counts only. The placeholder is caught by the represented-status classifier. The legal regime is the no-advice one, so the message is stripped to date, time, and place plus the referral, per §9.1.

The pressure-valve answer, made stronger by Roberts. A reminder program that quietly props up appearance numbers where the state is violating the right to counsel relieves the pressure that produced Roberts. The answer is to point the aggregate data the other way. The scale and location of the counsel gap, documented in real time, is the exhibit the next right-to-counsel suit is built on, and the operator-as-defense-agent structure (§1B) is what makes pointing it at the state coherent rather than conflicted. Constructive use is aggregate evidence that forces counsel to be provided. The failure mode is feeding identified non-compliance to supervision, which the duty wall forbids.

Site choice. Oregon is the right place to harden the design and the wrong place to run the pilot. The Roberts dismissals pull cases off the docket for reasons unrelated to reminders, which contaminates the FTA denominator. So the pilot goes to a functioning-defense county, and the crisis-hardened mode rides along as standard, because counsel is guaranteed nowhere.


14. Sustainability and ownership

The problem. PD offices run on rigid, grant-bound budgets and rarely absorb a recurring software fee after a pilot, so who pays after the grant is the first adoption question.

Bridge funding, with a real number and honest math. The near-term argument is cost-avoidance, billed to the entity that actually bears the warrant cost, the county general fund or a justice-reinvestment line, never the PD's starved budget. The ideas42 and Pew estimate (2025) puts the cost of a missed appearance at about $1,496 in government costs, blending administration, warrant processing, and possible incarceration. Be honest about realized savings. Many warrants are never actively served, so the pilot reports warrants averted times locally verified cost components, not the national headline times a guess. Structure it as pay-for-success, paid out of realized savings.

The durable model, and a warning the earlier version missed. For a public-purpose tool whose whole pitch is a published method, public audits, and no rent extraction, a perpetual private software license is fragile and off-brand, and an algorithmic-accountability audience would smell it. So the endgame is build, prove, and open-source, with the Administrative Office of the Courts or the state public-defense commission adopting and maintaining the code, because those are the entities with a standing mandate and a budget line. Open-sourcing the code also walks past the procurement and anti-gift rules, because there is nothing proprietary to give. But here is the warning. Do not hand the operational dataset to a government owner. The moment a court or agency holds it, state open-records law may reach it, and in several states court contact data is presumptively public, so a carefully walled private dataset becomes publicly requestable. Hand off the code. The operator keeps the data, and purges it on schedule (§5.4).

Handoff criteria, decided at month 12. Transfer the code at v1.0, or after six months of stable operation and a met reduction threshold. Either way, the data does not move.


Thursday, June 4, 2026

Tentausando: A Protocol for User-Owned Ranking on the Open Web

Tentausando — Product Requirements Document

An open protocol for syndication, discovery, and user-owned ranking on the open web.

Document Product Requirements Document (PRD)
Version v0.10 — Draft (structural re-sequence)
Status For internal review / partner circulation
Authors Rhombus Ticks and Redwin Tursor
IT Consulting TC Ricks
Imprint Red Anvil Creative
Date June 4, 2026

Re-sequence Note (v0.10)

This revision does not change the architecture. It changes the order in which the document earns the reader's attention, on four moves:

  1. Lead with the ranking thesis, not the machinery. The feed's ranking is what decides what you see and what you never do — and someone else controls it. "Ranking sovereignty" is a reader reclaiming control of that ordering. This is now §0, before any acronym. The terms ASM, Ed25519, and federatable index — which trigger the "another decentralization protocol" reflex on contact — are deferred until the thesis is already stated.
  2. Promote bridges from a risk-section footnote to the seeding strategy. A high-quality protocol with no network on it is dead on arrival. Opt-in bridges that let people carry their own existing content in are the only credible cold-start lever, so they are stated up front (§2) rather than buried in §9.2.
  3. Demote the addiction dial's public-number theater. The dial is a powerful private instrument and a dangerous public badge — "my addiction level is 2/10" turns a practice into a status display. The published-setting visibility is now opt-in, not mandatory, and the "culturally significant public number" framing is removed.
  4. Add author accountability. A published ranking algorithm shapes the feed of everyone who subscribes to it. Algorithms now carry a legible feed-composition profile (source concentration, diversity, addiction profile) so an author owns the feed they shape — the same legibility principle the rest of the protocol already rests on.

Prior revision history (v0.2–v0.9) is preserved in Appendix C.


0. Thesis — Whoever controls the ranking controls what you see

You are reading inside a feed someone else controls.

Every feed you use decides which content reaches you, in what order, and how often — and that ordering is not neutral. The ranking is the product: it decides what gets your attention and what you never see at all. Every major platform has captured that ranking and tuned it to a single objective — maximize engagement — and then hidden the controls. The grievance people actually have with modern feeds is not that they cannot reach content. It is that an operator they cannot see is ordering what they read, optimized for someone else's revenue, and refusing to say how.

Tentausando's thesis is that ranking sovereignty — owning the ranking itself, over content that cannot be deplatformed — is the real and underexploited opportunity. Not a better black box. The removal of the box, and the return of control to the reader.

Everything downstream — identity, indexing, syndication markup, the algorithm marketplace — is machinery in service of that one idea, introduced only after the idea is established and justified by reference back to it.

A second, structural claim sits underneath the first: because content lives on the author's own pages rather than on a platform, the substrate itself cannot be deplatformed. None of the post-Twitter destinations — Threads, Mastodon, or even Bluesky — can offer that for the place their users actually gather. You can be removed from every one of them. You cannot be removed from your own pages.


1. Problem Statement

The open web has a distribution problem that is coordination-shaped, not technology-shaped. The individual pieces required to fix it largely exist; no one has assembled them into a coherent stack with a reference implementation and a reason for ordinary users to show up.

The concrete failures:

RSS is structurally impoverished. It carries a title, a body, and a date. It has no native concept of identity, curation, comments, content type, or ranking. It died in the mainstream partly because its de facto coordination layer (Google Reader) was discontinued and nothing replaced the index.

ActivityPub absorbed the decentralization energy and overshot. Federation in the Mastodon model requires running or joining a server, accepting an instance's moderation regime, and operating inside a protocol built for microblogging social graphs rather than general content syndication. It is the wrong weight class for "let me publish a page and have it discovered."

Discovery is a coordination problem. Someone has to run the index, and prior efforts collapsed less from cost than from centralization — when the one index everyone depended on went away, nothing replaced it. Avoiding a single load-bearing index, not funding one, is the hard part (see §9.1).

Algorithmic control is talked about but not delivered. Regulatory pressure (e.g. the EU Digital Services Act's transparency provisions) and post-platform-collapse user sentiment have raised the salience of "I want to control my feed." But every product still ships a black box, and the few that expose knobs do so trivially. No one treats the algorithm — the ranking itself — as a first-class, ownable, shareable object.

Comment federation keeps dying. Disqus, Coral, Commento and others each solve a slice and stall on the same chicken-and-egg adoption curve. A clean, XML-native, identity-anchored approach has not been tried at the protocol level.

1.1 The networks people fled to each fail — and a central actor controls what you see

The post-Twitter migration scattered across three "open-ish" destinations. Each has a documented, structural problem, and they share one: a central operator controls reach, moderation, and whether you continue to exist there — which means a central operator controls what you see and can switch it off.

Threads is Meta — the corporate control people left. At launch it collected so much sensitive data — health, finances, location — that it was branded a "privacy nightmare" and held out of the EU over data-protection law. Its fediverse support arrived roughly eighteen months late and is still hobbled — you cannot even search for fediverse users from Threads — while over 800 servers preemptively pledged to defederate from it (the "Fedipact") over Meta's moderation and privacy record. The embrace-extend-extinguish worry is not hypothetical: 404 Media documented Meta blocking links to Pixelfed, and observers note Meta can make ActivityPub deliberately awkward and later withdraw it once it has served its purpose. Add an engagement-shaped feed that deprioritizes news and politics by design, moderation that has wrongly deactivated numerous accounts, and the end of fact-checking, and Threads is a walled garden wearing open-protocol clothes. To its credit it brings capital-grade infrastructure and the lowest barrier to entry of the three by riding existing Instagram graphs — but that reach is Meta's to grant or revoke.

Mastodon is feudal decentralization. It solves "no single corporate owner" by handing your identity and your moderation regime to a volunteer instance admin, and it makes a newcomer choose a server before they understand what a server is. Discovery runs backwards — search is deliberately limited, and the network has repeatedly dogpiled even consent-respecting search tools into shutting down. Instances shut down and take their users' identities with them; admins suspend accounts; defederation severs whole communities overnight. The operator is smaller and kinder than Meta, but there is still an operator who can remove you.

Bluesky markets a decentralization it does not yet deliver. It raised a $100M Series B (Bain Capital Crypto, April 2025), ~$123M total, 43M+ users, with a 2025 founder-to-CIO and commercialization-hire pivot that sharpens rather than softens the VC-capture concern. Its custom feeds and composable moderation are the closest prior art to Tentausando and deserve real credit. But in late 2025 a user banned by the central team could not, in practice, "just move" — the decentralization is by design, centralized in operation, and a single point of political pressure. The operator can still remove you from where everyone gathers.

The common failure mode: a central actor can remove you, and therefore controls what you see. Tentausando's substrate — your own pages — cannot be deplatformed. Appendix A compares all five at a glance, led by a "who can remove you" row.


2. The On-Ramp — bridges as the seeding strategy

A protocol with no network on it is dead on arrival. The hardest problem Tentausando faces is not design; it is the cold start (§9.2). The answer is to build on top of the networks that already exist rather than wait for a new one to form.

A bridge is opt-in and self-service: an individual on Mastodon, Threads (via ActivityPub), or Bluesky (via the AT Protocol) joins Tentausando and maps their own public content into the index — keeping their existing accounts. "No cooperation required" means the platform — Meta, Mastodon gGmbH, Bluesky PBC — need do nothing; the individual consents by joining. This is deliberately not a firehose scrape: indexing non-consenting accounts is the move the fediverse has repeatedly shut down, and it would contradict the protocol's own curator-allow consent principle.

This is the project's cheapest content-seeding lever and its primary adoption strategy, not a courtesy feature. Done right, the bridge converts the open networks from rivals into a distribution on-ramp: people carry their existing audience and back catalogue in without abandoning anything, the index populates from day one, and the first curators have something to curate before the native publishing base exists. The technical bridge specification (what a bridge can and cannot attest, and how it proves account control without overclaiming origin-signing) lives in §5.4; the strategic point is stated here because it carries the launch.

The walled-garden case — closed platforms with no open API and no opt-in path — is out of scope.


3. Product Overview

Tentausando is a lightweight, open syndication and discovery protocol paired with a user-owned ranking system. It occupies the gap between RSS (too primitive — a dumb pipe with no structure, no discovery, no curation) and ActivityPub/Mastodon (overbuilt — heavy server requirements, protocol lock-in, and an instance model most publishers never adopt).

┌─────────────────────────────────────────────────────────────────┐
│                         AUTHOR'S ORIGIN                            │
│   any static or dynamic page + embedded ASM descriptor (XML)       │
│   + reactions.xml at origin; comments live on commenters' pages    │
└───────────────────────────────┬───────────────────────────────────┘
                                 │ crawled / self-registered / bridged
                                 ▼
┌───────────────────────────────────────────────────────────────────┐
│                          THE INDEX (federatable)                    │
│   stores ASM metadata + pointers only — NOT canonical content       │
│   exposes a public query API                                        │
└───────────────────────────────┬───────────────────────────────────┘
                                 │ queried by
                                 ▼
┌───────────────────────────────────────────────────────────────────┐
│                     AGGREGATORS (also ASM nodes)                    │
│   editorial / topical / institutional curated feeds + bridges       │
└───────────────────────────────┬───────────────────────────────────┘
                                 │ candidate pool
                                 ▼
┌───────────────────────────────────────────────────────────────────┐
│                       RANKING ENGINE (open source)                  │
│   Tier 0: declarative signal weights                                │
│   Tier 1: learning-to-rank (Metarank)                               │
│   Tier 2: collaborative filtering (Gorse / LightFM)                 │
│   configured by ↓                                                   │
│   ┌─────────────────────────────────────────────────────────────┐  │
│   │  THE ALGO STUDIO (GUI) — addiction dial, topic weights,      │  │
│   │  learning throttle, source trust, "why am I seeing this?"    │  │
│   │  publish · fork · subscribe · feed-composition profile      │  │
│   └─────────────────────────────────────────────────────────────┘  │
└───────────────────────────────┬───────────────────────────────────┘
                                 │ ranked feed
                                 ▼
┌───────────────────────────────────────────────────────────────────┐
│                        THE READER APP                               │
│   identity = Tentausando ID · feed · comments client                │
│   read/click/skip signals fed back to the ranking engine ──────────►│
└───────────────────────────────────────────────────────────────────┘

The system has three pillars:

  1. ASM (Annotated Syndication Markup) — a small XML descriptor any text page can embed, with no CMS, server, or platform dependency. A static HTML file qualifies. Hosts emit it for their users automatically, so nobody hand-writes markup.
  2. The Tentausando ID — a portable, self-generated identity that most people experience as an ordinary, recoverable account with a normal handle, and that anyone can export to full self-custody to become uncancellable.
  3. The Algo Studio — a GUI that lets any user design their own ranking algorithm — including a literal addiction dial — and then publish, fork, and subscribe to algorithms the way people now follow accounts.

Joining is designed to be as easy as signing up for any app — one tap, a good default feed immediately, existing Mastodon/Bluesky/RSS accounts connected in one tap, with no instance to choose, no key to memorize, and no file to edit. The instance-choice maze that stranded Mastodon's newcomers is treated as an anti-pattern, not a rite of passage.

The protocol and reference implementations are open source; there are no ads and no sale of user data, because both would corrupt the legible ranking that is the entire point.

The product name derives from its identity layer. A tentausando is the number 10^1000 — one followed by a thousand zeros — and the name evokes that scale the way Google evokes googol. The identity primitive itself is a 256-bit Ed25519 keypair whose ≈10⁷⁷ key space is already vast enough to be effectively uncollidable; the 10^1000 is the name's poetry, not a literal entropy claim (see §5.2).


4. Goals and Non-Goals

4.1 Goals

  • Make joining as easy as any consumer app for a non-technical person — a hard requirement, not a nicety. No one is ever required to choose a server, edit a file, manage a cryptographic key, or understand the protocol to participate; the technical machinery is the host's job, not the user's.
  • Define an XML descriptor (ASM) that any page can embed with zero server requirement.
  • Define a self-sovereign identity token (Tentausando ID) requiring no signup, email, or central authority.
  • Specify a federatable index/crawler that stores pointers and metadata, never canonical content.
  • Specify an aggregation/curation layer where aggregators are themselves first-class ASM nodes, and opt-in bridges are a leading adoption on-ramp.
  • Specify identity-anchored, decentralized comment federation (signed comment objects on the commenter's own substrate, assembled by reference).
  • Deliver a ranking engine built on open-source components, exposing every ranking decision to inspection.
  • Deliver the Algo Studio: a GUI for designing, publishing, forking, and subscribing to ranking algorithms, each carrying a legible feed-composition profile.
  • Keep the protocol and reference implementations open source under a license to be determined in §11.

4.2 Non-Goals

  • Not a social network with a follower graph as the primary primitive. The primitives are content, identity, and algorithm.
  • Not an ActivityPub or AT Protocol competitor. Tentausando does not replace the open networks; users opt in to bridge their own content from them (§2, §5.4, §9.7), keeping their existing accounts.
  • Not an ad-supported product. Engagement-maximizing monetization is explicitly excluded because it is incompatible with a legible, user-owned ranking system.
  • Not a hosting platform for content. Canonical content always remains on the author's origin.
  • Not a content moderation authority. Moderation is addressed as a federated, curator-level and reader-level concern (see §9.6), not a central function.
  • Not an onboarding that offloads complexity onto the user. The instance-choice maze, hand-editing markup, and "here is your private key, don't lose it" are the explicit anti-patterns; any of them appearing in the default join flow is a defect, not a power feature.

5. Component Specifications

5.1 ASM — Annotated Syndication Markup

Purpose. A small, embeddable descriptor that makes any page discoverable, attributable, and curatable with no server required.

<asm xmlns="https://tentausando.org/ns/asm/1.0">
  <author>
    <handle>areed</handle>
    <identity>tnt:8417…</identity>
  </author>
  <content>
    <title>What the Open Web Lost When Reader Died</title>
    <canonical>https://example.com/posts/open-web-discovery</canonical>
    <type>essay</type>
    <published>2026-05-28T14:00:00Z</published>
    <updated>2026-05-28T14:00:00Z</updated>
    <tags>open web, syndication, discovery</tags>
    <license>cc-by-nc-4.0</license>
  </content>
  <syndication>
    <comments>https://example.com/posts/open-web-discovery/comments.xml</comments>
    <reactions>https://example.com/posts/open-web-discovery/reactions.xml</reactions>
    <curator-allow>*</curator-allow>   <!-- * = open, or whitelist of index/aggregator IDs -->
  </syndication>
  <signature alg="ed25519">…(signature over the descriptor's canonical serialization, keyed to author identity)…</signature>
</asm>

Design principle. The index and aggregators receive metadata and pointers. The canonical body stays on the author's origin. This keeps authors in control of their content, keeps the index cheap to operate, and sidesteps the largest class of copyright and content-liability problems.

Who actually writes ASM — almost never the user. ASM is plumbing, and a non-technical user never sees it. The expected path is that a host emits ASM on the user's behalf — exactly as a blogging platform emits RSS without its writers ever knowing what RSS is. Hand-authoring an ASM file, or dropping one on a static site you run, is the power-user / self-hoster path — fully supported, never required.

Requirements:

  • REQ-ASM-01 — The descriptor MUST be valid against the published ASM XML schema (asm-1.0.xsd).
  • REQ-ASM-02author.identity, content.title, content.canonical, and content.type are REQUIRED. All other fields are OPTIONAL.
  • REQ-ASM-03 — The descriptor MUST be embeddable in a fully static page with no server-side processing.
  • REQ-ASM-04 — The descriptor SHOULD carry a signature keyed to the author's Tentausando ID, enabling consumers to verify authorship integrity.
  • REQ-ASM-04b — When a signature is present it MUST be computed over a deterministic serialization of the descriptor (a defined canonical byte form — e.g. canonical JSON/CBOR of the descriptor fields — not a c14n-dependent XML-DSig), and verifiers MUST reject non-canonical Ed25519 signature encodings.
  • REQ-ASM-05curator-allow MUST be honored by conforming index/aggregator implementations; absence defaults to open (*).
  • REQ-ASM-06 — A reference validator MUST be published so authors can confirm conformance before deployment.
  • REQ-ASM-07 — ASM MUST be expressible both as an Atom namespace within an existing feed and as a standalone page descriptor; the two forms MUST carry identical semantics.
  • REQ-ASM-08 — A conforming host MUST be able to generate, sign, and serve valid ASM on behalf of its users, so that becoming discoverable requires no markup authoring or file handling by the user.

5.2 Tentausando ID — Self-Sovereign Identity

Purpose. Give every participant — author, commenter, curator — a portable identity that requires no signup, no email, no platform account, and no central issuer, while still being strong enough to authenticate actions.

Mechanism. Under the hood, identity is a 256-bit Ed25519 keypair; the public half can be rendered as a base-10 integer whose key space (≈10⁷⁷) is already far beyond any feasible collision or brute-force attack. But that number is machinery, not the user's face. What a normal user sees and shares is a human handleyou@host for a host-managed account — while the underlying integer stays under the hood. The private half signs comments, proves ownership of a published algorithm, and signs ASM descriptors; on the default host-managed account the host holds it, so the user never handles a key at all. The name Tentausando evokes 10^1000 the way Google evokes googol — branding for vastness, not a literal entropy figure.

The honest tradeoff — and how the default avoids it. Self-held keys mean no one can lock you out — and no one can let you back in. Most people will never want that responsibility, and the protocol does not force it on them. The default experience is an ordinary account: a user signs up with a host, the host custodies their key, and recovery, key rotation, and a legible handle all work the way they do on any app. The key is exportable at any time: a user who wants full portability exports it and self-custodies, at which point the deal flips — they hold the key, they write it down, and the loss is theirs. Crucially, custody is about the key, not the content: a host holding your key cannot take down your origin pages, so the substrate stays uncancellable regardless of where the key lives. Key custody is addressed candidly in §9.4.

Three ways to hold an identity (custody and anchoring are independent axes):

  • Host-managed (default). A host custodies the key. Easy, recoverable, with a human-legible handle. What most people use.
  • Self-custodied. The user exports the key and holds it themselves. Maximum portability and the strongest deplatforming resistance; the user owns the key-loss risk (§9.4).
  • Host-anchored (optional, additive). Independently of who holds the key, a user can publish their public ID at a location on a domain they control (e.g. /.well-known/tentausando), binding the identity to that origin as a reputational anchor and enabling key rotation.

Requirements:

  • REQ-ID-01 — IDs MUST be generated client-side using a CSPRNG (e.g. crypto.getRandomValues, never Math.random), with no registration.
  • REQ-ID-02 — In self-custody, the private key MUST NOT leave the client and signing MUST happen locally. A host-managed identity MAY escrow the key for recovery, but it MUST remain exportable at any time.
  • REQ-ID-03 — The public ID MUST be representable both as a base-10 integer (human-shareable) and in a compact canonical encoding (machine form).
  • REQ-ID-04 — The user MUST be able to export their key and import it into another client or host.
  • REQ-ID-05 — Host-anchoring MUST be optional and additive; an unanchored ID is fully valid.
  • REQ-ID-06 — Host-managed identities MUST provide account recovery and key rotation. A self-custodied identity has no recovery path; the product MUST state this plainly at the moment of export.

5.3 The Index

Purpose. The discovery layer. A queryable store of ASM metadata.

Behavior. The index crawls ASM-bearing domains (discovered via crawl or self-registration), stores the structured metadata and pointers, and exposes a query API such as:

GET /index?author=areed&type=essay&tag=open-web&since=2026-05-01
GET /index?id=tnt:8417…
GET /index?canonical=https://example.com/posts/open-web-discovery

Federation. Anyone can run an index. Conforming indexes can exchange records, and trusted hubs are expected to emerge organically. No single index is privileged by the protocol.

Binding a URL to a key (possession), and resolving conflicting claims. A signature proves who signed, not who controls the URL. The index therefore binds a URL to a key by proof of possession: at crawl time it confirms the ASM is reachably served from (or rel-linked by) the canonical origin, and the first key to validly claim a URL holds it (first-key continuity / trust-on-first-use). A later descriptor for the same URL signed by a different key requires continuity from the incumbent key (a rotation signed by the old key) — which prevents an attacker who seizes a lapsed domain from silently overwriting authorship. Bridged URLs are resolved through the §5.4 authorship-assertion plus account-control proof instead, and remain distinguishable as asserted rather than origin-signed.

The central risk is centralization, not cost (see §9.1). Because the index stores pointers and metadata only, even a multi-million-item index runs on a modest VPS. Federation buys resilience — no single index whose death is fatal — rather than cheaper infrastructure, which the architecture already makes cheap.

Requirements:

  • REQ-IDX-01 — The index MUST store only metadata and pointers, never canonical content bodies.
  • REQ-IDX-02 — The index MUST expose a public, documented query API.
  • REQ-IDX-03 — The index MUST honor curator-allow directives.
  • REQ-IDX-04 — The index MUST be runnable as a self-hostable reference implementation with modest resource requirements.
  • REQ-IDX-05 — Indexes SHOULD support record federation with other conforming indexes.
  • REQ-IDX-06 — Records MUST be keyed on canonical URL with last-write-wins by updated; the signed ASM descriptor — not index state — is authoritative.
  • REQ-IDX-07 — The index MUST bind a canonical URL to a key by proof of possession and MUST apply first-key continuity.
  • REQ-IDX-08 — The index MUST reject descriptors whose updated timestamp exceeds the crawler's clock by more than a bounded skew.
  • REQ-IDX-09 — Published algorithms MUST be storable and queryable as a first-class index record type under an algorithm: namespace, addressable by author ID plus algorithm name and carrying the author's signature.

5.4 Aggregators and Bridges

Purpose. The editorial/curation layer. Aggregators query the index and assemble curated feeds with their own identity and point of view.

Behavior. An aggregator is a named, curated lens over the index — topical, editorial, or institutional. Critically, aggregators are themselves ASM nodes: an aggregator publishes its own ASM feed, so aggregators can be discovered, subscribed to, and aggregated by other aggregators. Curation composes.

Bridges (the on-ramp — strategy in §2). A bridge is an aggregator whose source is another network rather than ASM-bearing pages — opt-in and self-service. A person on Mastodon, Threads, or Bluesky joins Tentausando themselves, after which their own public posts are mapped into ASM descriptors and indexed. This is the Bridgy Fed model, deliberately not a firehose scrape.

Signing bridged content — what a bridge can and cannot attest. A bridge cannot sign content it does not host. So it does not pretend to. Instead the user — or, for a host-managed identity, the user's host on their behalf — issues a signed authorship assertion: "Tentausando ID X claims canonical URL Y, observed at time T," served from the user's anchor, not faked as origin-served. To bind the assertion to the real account, the bridge requires a one-time proof of control of the source account — a rel="me" link or a signed nonce — performed by the app as a one-tap connect and verify (OAuth where available, or auto-posting the verification link). Bridged records are flagged authorship-asserted (content at origin), distinct from self-hosted origin-signed records, and readers and aggregators may weight the two differently.

Requirements:

  • REQ-AGG-01 — An aggregator MUST publish its own conforming ASM feed.
  • REQ-AGG-02 — Aggregators MUST respect author curator-allow directives.
  • REQ-AGG-03 — Aggregator feeds MUST be subscribable by both reader apps and other aggregators.
  • REQ-AGG-04 — An aggregator MUST be operable without author permission for any content marked open, and MUST exclude content that has not whitelisted it where a whitelist is specified.
  • REQ-AGG-05 — A bridge MUST be opt-in: it ingests only the records of individuals who have explicitly joined, operates read-only against the source, honors source-network opt-out signals (e.g. #nobot, no-index flags), and requires no cooperation from the source platform. It MUST NOT scrape non-consenting accounts.
  • REQ-AGG-06 — A bridge MUST NOT produce ASM that falsely attributes origin-signing to bridged content. Bridged items MUST carry a signed authorship assertion, MUST be backed by a one-time proof of control of the source account, and MUST be flagged as authorship-asserted. The proof of control SHOULD be performed by the client or host on the user's behalf, never handed to the user as a manual step.

5.5 Comment Federation

Purpose. Replace the dead/dying central comment silo with identity-anchored, author-hosted comments.

Mechanism. A comment is itself a signed object that lives on the commenter's own substrate and references the canonical URL it responds to. Each comment is signed by its author's Tentausando ID, so authorship is verifiable without a central account system. A target's thread is assembled by reference: the index and readers gather the signed comment-objects that point at a given URL. This accepts higher latency and assembly cost as the price of staying decentralized; it also dissolves the static-site problem — comments are not POSTed to an author who has no write endpoint, but published by commenters and discovered by reference.

<comments for="https://example.com/posts/open-web-discovery"
          xmlns="https://tentausando.org/ns/comments">
  <comment id="c001">
    <author-handle>mreyes</author-handle>
    <author-id>tnt:5521…</author-id>
    <posted>2026-06-01T10:15:00Z</posted>
    <reply-to/>
    <body>This matches what the post-Reader discovery data shows about…</body>
    <signature alg="ed25519">…</signature>
  </comment>
</comments>

The protocol explicitly rejects routing comments through a single hosted comment service: that would re-centralize exactly what the protocol exists to decentralize. A reader app may cache or aggregate threads for speed, but caching is never authoritative.

Requirements:

  • REQ-COM-01 — Each comment MUST be a signed object on the commenter's own substrate, referencing the canonical content URL, with no central comment store.
  • REQ-COM-02 — Each comment MUST be signed by the commenter's Tentausando ID.
  • REQ-COM-03 — The author MUST control which referencing comments (if any) are displayed alongside their content; the author does not host or own the comments themselves.
  • REQ-COM-04 — Comment threading MUST be supported via reply-to.
  • REQ-COM-05 — Conforming implementations MUST NOT depend on a single central comment service; caching for performance is permitted but MUST NOT be authoritative.
  • REQ-COM-06 — Moderation hooks (author-level allow/block by ID, reader-level muting) MUST be specified (see §9.6).

5.6 The Ranking Engine

Purpose. Turn a candidate pool into a ranked feed, with every ranking decision inspectable. This is the ranking layer of §0, made open-source and legible.

The engine is tiered, with the same configuration object describing the user's intent at every tier.

Tier 0 — Declarative signal weights (no ML). The honest baseline. The user sets explicit weights; ranking is a transparent weighted sum. This tier alone is a complete, shippable product and the philosophical heart of the system.

ranking:
  recency_weight:        0.6
  topic_affinity_weight: 0.3
  curator_trust_weight:  0.1
  penalties:
    already_read: -1.0
    author_muted: -999

Tier 1 — Learning-to-rank (Metarank). Metarank ingests engagement signals and reranks in real time, configured through a YAML DSL. Because the configuration is YAML, the user-visible algorithm and the auditable machine configuration are the same artifact.

Tier 2 — Collaborative filtering (Gorse / LightFM). For cross-user discovery. Optional and additive.

The moat is the experience and the network, not the algorithm. Every ranking component is open source.

Retrieval vs. reranking — what the user actually controls. Everything above is reranking. Retrieval — generating the pool — is the expensive half; the reference architecture does not solve global retrieval, and aggregators are the retrieval layer. The user controls both stages: their subscriptions are their retrieval policy and their algorithm is the ranking. The one true bound is source diversity — your algorithm can only rank what your subscriptions admit — which is a defaults problem (ship broad, good default sources), not a structural defect.

Requirements:

  • REQ-RANK-01 — At Tiers 0 and 1, every ranked item MUST explain its position in the terms the user configured.
  • REQ-RANK-01b — At Tier 2, the per-item explanation MAY be an honest taste-overlap statement; Tier 2 MUST be individually switchable off.
  • REQ-RANK-02 — The Tier 0 declarative engine MUST be fully functional with no learning component enabled.
  • REQ-RANK-03 — The configuration object MUST be the same artifact the GUI edits, the engine consumes, and the user can publish.
  • REQ-RANK-04 — Engagement signals MUST be collected locally and used only as the learning-throttle setting permits.
  • REQ-RANK-05 — No engagement signal may be sold, shared, or used for advertising. (Hard constraint.)
  • REQ-RANK-06 — Sovereignty spans two stages: subscriptions determine candidate scope, the algorithm determines ordering. The product MUST make that scope visible rather than implying the algorithm surfaces everything.

5.7 The Algo Studio

Purpose. The differentiating product. A GUI that lets any user design their own ranking algorithm, see exactly what it does, and then publish, fork, and subscribe to algorithms. The algorithm becomes a first-class, ownable, shareable object — and an accountable one.

Core controls:

  • The Addiction Dial — a private instrument. A single, explicitly named slider from monk mode (0) to give me the good stuff (10). The dial scales engagement-correlated content features — length, recency, novelty, and virality defined as the open web's own citation graph (how many other ASM authors and aggregators reference an item), computed from index metadata rather than from anyone's clicks or dwell time. These are properties of the item and its public reception, not records of your behavior, so the dial requires zero behavioral tracking of the user. Naming the dopamine variable and handing the user conscious control over it is the anti-dark-pattern; every engagement-optimized product pins this value to maximum and hides it. The dial is designed as a control you set for your feed; its value as a public badge is deliberately not promoted (see "On making the dial a public number," below).
  • Topic Weights. Explicit gravity per tag/type — declared, not inferred.
  • Learning Throttle. A separate control governing whether the system models you: off (declared preferences only), slow learn (periodic batch), active learn (real-time), forget mode (periodic decay to counter filter-bubble entrenchment).
  • Source / Curator Trust. Per-aggregator and per-author trust weights and mutes.
  • "Why am I seeing this?" Every item exposes its ranking rationale in the user's own configured terms.

The dial and the throttle are orthogonal — and that is the point. Because the dial acts only on content features, every dial setting is coherent at every throttle setting. This decomposition yields the product's strongest privacy story: maximum addictiveness requires zero surveillance of the individual, because virality and freshness are facts about the item, not about you.

On making the dial a public number (a deliberate restraint). A published algorithm's addiction setting may be displayed, but visibility is opt-in, never mandatory or default. The reason is behavioral: the moment a low dial setting becomes a public badge, the dial stops being a setting people use and becomes a status display — people perform "my addiction level is 2/10" while quietly subscribing to a spicier fork. That turns a self-regulation tool into a performance, the exact dynamic the product exists to counter. The dial's power is as a private instrument; its public-signal value is treated as a hazard to be contained, not a feature to be amplified.

Publish · Fork · Subscribe — the second product layer. An algorithm is a portable configuration artifact, signed by its author's Tentausando ID.

  • Publish. Make your algorithm public, addressable by your ID plus an algorithm name (tnt:8417…/slow-geopolitics).
  • Subscribe. Adopt someone's published algorithm as your feed ranker — because their algorithm produces a better feed than yours, and you can inspect exactly why.
  • Fork. Copy an algorithm you mostly like, tune it, republish your variant with provenance/lineage preserved. Version control for epistemology.

Accountability — the algorithm author owns the feed they shape. A published ranking function shapes the feed of everyone who subscribes to it. The author should own that, the way the rest of the protocol owns its claims through legibility. Every published algorithm therefore carries a computed feed-composition profile — not the author's marketing copy, but metrics derived from the algorithm's behavior over a reference candidate pool:

  • Source concentration — how much of the resulting feed comes from how few origins (a high number flags an echo chamber).
  • Diversity — spread across topics, source types, and viewpoints the feed admits.
  • Addiction profile — where the algorithm actually sits on the engagement-feature axis in practice, computed independently of the author's claimed dial setting.
  • Freshness/recency skew — how heavily the feed favors the new over the durable.

This makes an algorithm's effects legible the same way ASM makes a page's authorship legible, and gives subscribers a basis for trust that does not depend on the author's self-description. It is the responsibility half of sovereignty: you may shape what others read, but you do so in the open.

This produces emergent layers the protocol does not hand-build: algorithm-as-identity, algorithm marketplaces (an EFF "surveillance-aware" algorithm; a university "slow read" algorithm; a journalist's breaking-news algorithm), and algorithm trust graphs built around revealed intellectual values rather than platform-assigned categories.

Requirements:

  • REQ-STUDIO-01 — The Studio MUST present the Addiction Dial as a single, plainly labeled control that scales engagement-correlated content features only; it MUST NOT require or trigger behavioral tracking at any setting.
  • REQ-STUDIO-01b — The Addiction Dial and the Learning Throttle MUST be independent controls; any combination MUST be valid and coherent.
  • REQ-STUDIO-02 — All controls MUST compile to the same configuration object the ranking engine consumes (REQ-RANK-03).
  • REQ-STUDIO-03 — A user MUST be able to publish an algorithm addressable by their Tentausando ID and an algorithm name.
  • REQ-STUDIO-04 — A user MUST be able to subscribe to a published algorithm and use it as their active ranker.
  • REQ-STUDIO-05 — A user MUST be able to fork a published algorithm; forks MUST retain provenance/lineage metadata.
  • REQ-STUDIO-06 — A published algorithm's addiction-dial setting MAY be displayed publicly, but such display MUST be opt-in and MUST NOT be the default; the product MUST NOT rank, leaderboard, or otherwise gamify dial settings across authors.
  • REQ-STUDIO-07 — Published algorithms MUST be signed by the author's Tentausando ID and verifiable.
  • REQ-STUDIO-08 — Default algorithms (sensible presets and a curated starter set) MUST ship so a non-configuring user gets a good feed without building anything (see §9.3).
  • REQ-STUDIO-09 — A published algorithm MUST carry a computed feed-composition profile (at minimum: source concentration, diversity, measured addiction profile, recency skew), derived from the algorithm's behavior over a reference candidate pool rather than from author self-description, and displayed alongside the algorithm wherever it can be subscribed to.

5.8 The Reader App

Purpose. The consumer surface — feed reader, comment client, identity holder, signal source.

Behavior. The app holds the user's Tentausando ID, subscribes to aggregators and to a chosen ranking algorithm, renders the ranked feed and comment threads, and feeds read/click/skip signals back to the ranking engine subject to the learning-throttle setting. It optionally lets the user be a curator and be an algorithm author. Onboarding is deliberately trivial: a new user taps to join, is handed a host-managed identity and a good default feed, and can connect any existing Mastodon/Bluesky/RSS accounts in one tap.

Requirements:

  • REQ-APP-01 — The app MUST function as a reader against any conforming index/aggregator.
  • REQ-APP-02 — The app MUST hold and use the Tentausando ID for identity, signing, and algorithm ownership.
  • REQ-APP-03 — The app MUST render and submit federated comments.
  • REQ-APP-04 — The app MUST surface the active algorithm's controls (or a link into the Algo Studio), the per-item ranking rationale, and — when subscribing to a published algorithm — its feed-composition profile.
  • REQ-APP-05 — Engagement-signal collection MUST be local and governed by the learning-throttle setting.
  • REQ-APP-06 — First run MUST produce a usable, well-ranked feed with zero configuration; all configuration is strictly opt-in afterward.

6. User Personas

The Refugee. Left a collapsing or hostile platform; wants control without running a server. Subscribes to a starter algorithm, tunes the addiction dial down, and reads in peace.

The Curator. Has taste and wants reach. Publishes an algorithm; builds reputation on feed quality — and on a clean feed-composition profile — rather than follower count. The algorithm is the product.

The Publisher. A writer who wants distribution without surrendering it. The non-technical path: sign up with a host, write, and the host publishes ASM automatically. The power path: drop an ASM descriptor on a site they already run.

The Institution. A library, university, or organization like the EFF that publishes a values-aligned algorithm or aggregator as a public service — a "surveillance-aware" or "slow read" lens others can adopt, inspect, and trust against its published impact profile.

The Monk. Wants the minimum-addiction, declared-only feed. Sets the dial to 0 and learning to off, and the system honestly gives them exactly that.


7. User Stories (illustrative)

  • As a non-technical newcomer, I join in one tap, connect the Bluesky account I already have, and immediately get a good feed.
  • As a non-technical writer, I sign up with a host and just write; my posts become discoverable without my ever seeing a line of markup.
  • As a publisher, I add an ASM descriptor to my static site so my essays are discoverable without joining a platform.
  • As a reader, I generate a Tentausando ID in one tap, with no email, so I have a portable identity I fully own.
  • As a reader, I subscribe to a curator's published algorithm, inspect the config, and check its feed-composition profile before I adopt it.
  • As a reader, I set my addiction dial to 2/10 and turn on forget mode so my feed stays calm and my preferences don't ossify.
  • As a curator, I publish my algorithm and stand behind its impact profile.
  • As a tinkerer, I fork an algorithm I mostly like, raise the weight on my niche topics, and republish my variant with lineage intact.
  • As a commenter, I sign a comment with my Tentausando ID so my authorship is verifiable without any account.
  • As an institution, I publish a values-aligned algorithm as a public service that anyone can subscribe to and audit.

8. Business Model and Why-Now

Why-now. Two tailwinds converge. First, regulatory pressure toward algorithmic transparency (the EU DSA and analogous momentum) is moving "let users see and control the algorithm" from a niche demand to an expectation. Second, the post-platform-collapse environment has produced genuine appetite for alternatives — but the alternatives on offer are either black boxes or RSS readers. The integration layer is missing, and the moment for it is open.

Revenue (explicitly non-advertising). Advertising is excluded because it corrupts the very thing being sold. The model is the open-protocol / premium-flagship pattern proven by mastodon.social, WordPress.com, and Element/Matrix: the protocol is free and anyone can self-host, and the business is the flagship hosted experience — the polished app, a hosted home where non-technical users publish without running a website, the curated default aggregators, and a starter library of high-quality published algorithms. The flagship's revenue also funds the crawler and index it runs — which answers "who pays for discovery." Adjacent lines: hosted index/comments, and enterprise/institutional deployments. For the public-good layer, endowment or grant funding from aligned partners — Mozilla, Wikimedia, the EFF — is the natural fit. The bar is sustainability, not venture-scale returns.

The protocol and reference implementations stay open. The commercial layer is the experience and the managed infrastructure — never the ranking logic, never user data, never ads.

Positioning sentence. What if the ranking of your feed was yours — designed by you, legible to you, and publishable as an expression of how you think the world's information should be weighted? That is the open web's answer to the For You page: not a better black box, but a transparent, personal, accountable one.


9. Risks and Open Questions

9.1 Index centralization (central risk)

Reader did not die of cost; it died because a single operator discontinued the one index everyone depended on, and centralization meant no fallback existed. Because the index stores pointers and metadata only, even a multi-million-item index runs on a modest VPS — the cost problem is largely dissolved. The real existential risk is centralization: that one index becomes load-bearing enough that its death is fatal. Mitigations: keep the reference index lightweight; federate many cheap nodes; treat any "canonical hub" as one node among many. Where commercial hosted indexes contribute to public-index upkeep, that contribution must be made socially sticky — a visible "supports the public index" certification — or "voluntary" resolves to "nobody." One index can't equal a hundred — and it doesn't have to. Google degraded its own search into an ad-choked, SEO-spam product and abandoned quality open-web discovery; in the decade since Reader died no one built the replacement. The bar is to index open-web content better than a search engine that has stopped trying, not to beat the Google that still cared. Open question: the governance structure that keeps the network multi-homed as it grows.

9.2 Adoption chicken-and-egg (the existential risk — strategy in §2)

Readers need content; publishers need readers; curators need both. A high-quality protocol with no network on it is a dead protocol. Mitigations: seed with publishers already motivated to escape platform lock-in; let users opt in to bridge their own Mastodon, Threads, and Bluesky content (and ingest RSS/Atom) so the index populates without anyone abandoning their current accounts (§2, §5.4, §9.7); make the publisher cost near-zero. Self-service bridging is the cheapest content-seeding lever the project has and the primary launch strategy, which is why it is stated up front in §2 rather than treated as a feature. Open question: which source network seeds the densest, most curatable initial pool — and which single curator-community is the first beachhead.

9.3 Revealed vs. stated preference on configuration

Users say they want algorithmic control; most don't configure anything. Mitigation: the publish/subscribe layer resolves this — most users never build an algorithm, they subscribe to a good one. Configuration is for curators; subscription is for everyone. Strong defaults ship regardless (REQ-STUDIO-08). The related hazard — that the addiction dial becomes a performative badge rather than a practice — is contained by REQ-STUDIO-06 (no default public display, no gamification).

9.4 Key custody (the real identity risk)

This — not how the ID is represented — is where the identity model is genuinely exposed, and the design's answer is to not put the cliff in front of most users. The default is a host-managed, recoverable account. The key is exportable to self-custody at any time — and self-custody is where the industry's unsolved problem lives: a lost self-held key is identity death, and a stolen one has no clean revocation (the PGP/DID limitation). That cost is borne only by users who deliberately choose portability, stated plainly at the moment of export. Mitigations for self-custody: documented backup/restore; host-anchoring as a rotation anchor; optional social recovery (a Shamir quorum of trusted contacts); a hardware-backed key option. Custody never gates the content, which lives on the author's own pages regardless. Open question: which self-custody recovery patterns ship first-class vs. documented-only.

9.5 Sybil and spam in the algorithm marketplace

Cheap identities enable spam algorithms and fake reputation. Mitigations (native web-of-trust): reputation weighted by host-anchoring and by subscription provenance from already-anchored identities; lineage/forking history as a trust signal; the feed-composition profile (REQ-STUDIO-09) as a spam-resistant quality signal that does not depend on self-description; reader-level muting. Explicitly rejected: issuer-based "verified human" credentials, which reintroduce a central authority. Open question: how much of the trust-graph computation belongs in the protocol vs. in clients.

9.6 Moderation in federated comments (hard problem)

Decentralized comments raise the standard federated-moderation difficulties. Approach: moderation is layered, not central — author-level allow/block by ID, reader-level muting, and curator-level exclusion. Open question: minimum viable shared blocklist/labeling mechanism without recreating central control.

9.7 Interoperability — talk to the networks you can't fix

The three destinations each fail structurally (§1.1), but a user need not abandon them to adopt Tentausando. A bridge is opt-in and self-service (§2, §5.4). "No cooperation required" means the platform need do nothing; the individual consents by joining. This is deliberately not a firehose scrape. Decision: opt-in bridges are an early-phase priority (§10); the core protocol does not depend on them. The walled-garden case is out of scope.


10. Roadmap (phased)

Phase 0 — Specification. Publish ASM schema v1.0, the Tentausando ID specification, and a reference ASM validator.

Phase 1 — Index. Ship the reference self-hostable index and crawler with the public query API.

Phase 2 — Reader + Bridges (the seeding phase). Ship the reader app: Tentausando ID generation/import, aggregator subscription, feed rendering. Ship opt-in, self-service bridges (Mastodon/Threads via ActivityPub, Bluesky via AT Protocol) plus RSS/Atom ingestion, so the index populates without anyone leaving their current accounts. Per §2 and §9.2, bridges are the launch's load-bearing adoption mechanism, not a later add-on — this phase is where the network either takes root or does not.

Phase 3 — Algo Studio (Tier 0). Ship the declarative ranking engine and the Studio GUI: addiction dial, topic weights, learning throttle (off/slow at first), source trust, "why am I seeing this?", and the feed-composition profile computation (REQ-STUDIO-09).

Phase 4 — Learning tiers. Integrate Metarank (Tier 1); integrate Gorse/LightFM (Tier 2) as an optional layer.

Phase 5 — Publish/Fork/Subscribe. Ship algorithm publishing, subscription, forking with lineage, the impact-profile display, and the marketplace surface.

Phase 6 — Comment federation (deferred; no earlier than Phase 4). Ship identity-anchored comments per §5.5 and the moderation hooks of §9.6, only after the core loop is proven. This layer MUST stay decentralized even at the cost of latency.


11. Open Decisions

  • Licensing. Permissive (Apache-2.0/MIT) vs. copyleft (AGPL-3.0). AGPL is attractive for the index to keep hosted forks open; permissive lowers client-integration friction. To be decided per-component.
  • Signature/keypair primitive. Ed25519 is the working assumption; confirm against the base-10 human-shareable representation.
  • Canonical hub governance. Foundation, federation-only, or partner-hosted. Ties directly to §9.1.
  • Reactions model. Whether reactions.xml ships in v1 or follows comments.
  • Feed-composition profile. Which metrics are normative (required of every published algorithm) vs. optional, and what the reference candidate pool is for computing them comparably across algorithms.

Appendix A — Comparison Matrix

Capability RSS/Atom Mastodon Threads Bluesky Tentausando
Who can remove you nobody your instance admin Meta Bluesky (in practice) nobody — you own the pages
Who controls your ranking nobody (no ranking) instance default Meta Bluesky app view (feeds emerging) you — own, fork, subscribe
Content scope any web page microblog posts microblog posts microblog posts any open-web page
Identity none instance-bound Meta / Instagram portable (atproto) self-sovereign, portable
Discovery none (post-Reader) instance-based Meta-controlled Bluesky app view federatable index
Algorithm choice none chronological custom feeds (new, copied) custom feeds (mature) publish · fork · subscribe + impact profile
Structured metadata minimal moderate moderate moderate rich (typed ASM)
Comments absent native, siloed native (Meta) native federated, signed
Talks to other networks no partial (AP) partial, gated (AP) no yes — opt-in (AP/atproto/RSS)
Monetization donations ads VC-backed ($100M+); model TBD no ads; hosted flagship

The first two rows are the whole argument: every social destination has an operator who can evict you and who controls the ranking of what you see; an open-web substrate has neither.


Appendix B — Glossary

  • ASM — Annotated Syndication Markup; the embeddable XML content descriptor.
  • Tentausando ID — a self-generated keypair whose public half, rendered as a base-10 integer, is a participant's portable identity.
  • tentausando — the number 10^1000; an evocation of vastness and the source of the product name (the identity primitive is a 256-bit Ed25519 keypair, ≈10⁷⁷ key space — see §5.2).
  • Index — the federatable metadata/pointer store providing discovery.
  • Aggregator — a curated lens over the index; itself an ASM node.
  • Bridge — an opt-in, self-service aggregator that maps a joining individual's own content from another network into ASM.
  • Algo Studio — the GUI for designing, publishing, forking, and subscribing to ranking algorithms.
  • Addiction Dial — the explicit, user-set control that scales engagement-correlated content features (length, recency, novelty, and virality measured as the open-web citation graph); independent of the Learning Throttle and requiring no behavioral tracking. Treated as a private instrument, not a public badge (REQ-STUDIO-06).
  • Learning Throttle — the control governing how much the ranking adapts to behavior (off / slow / active / forget).
  • Feed-composition profile — computed metrics (source concentration, diversity, measured addiction profile, recency skew) published with every algorithm, making an algorithm author accountable for the feed they shape (REQ-STUDIO-09).

Appendix C — Revision History

v0.10 (this revision) — structural re-sequence. Four moves, no architecture change: (1) new §0 ranking thesis as the opening, deferring machinery; (2) bridges promoted to §2 as the seeding strategy; (3) addiction-dial public-number theater demoted — REQ-STUDIO-06 makes dial-setting display opt-in and bans gamification; (4) author accountability added — REQ-STUDIO-09 requires a computed feed-composition profile per published algorithm. Prior history retained below.

v0.9 — §9.1 index-economics framing added (rebuild discovery on the ashes of big-tech decline).

v0.8 — White Paper Summary added as opening front matter (superseded by §0 in v0.10).

v0.7 — Onboarding made a hard requirement ("barely an inconvenience"); identity handle-first; bridge verification one-tap; zero-configuration first run.

v0.6 — Bridge signing fixed (authorship assertion + proof of control); identity custody model made explicit (host-managed default, exportable to self-custody); signing and index integrity hardened; virality redefined as the open-web citation graph; comments deferred and re-grounded as decentralized.

v0.5 — Bluesky facts corrected ($100M Series B, ~$123M total, 43M+ users); teardown balanced with a "what each does well" beat; failure modes named (Threads = walled garden in open clothes; Mastodon = feudal decentralization; Bluesky = centralized in practice).

v0.4 — "Why the existing networks fail" case added; Appendix A comparison matrix led by "who can remove you."

v0.3 — ASM repositioned as Atom-expressible; identity entropy stated honestly; key custody named the real identity risk; retrieval/reranking split made explicit.

v0.2 — Addiction Dial decoupled from Learning Throttle; index risk reframed from funding to centralization; native web-of-trust for Sybil resistance.


End of document — Tentausando PRD v0.10 (Draft, structural re-sequence). Red Anvil Creative.