Cross-posted to the EA Forum and LessWrong.
I've spent the past several months building and testing an applied framework — called Aster — for governing persistent human-AI relational continuity across multiple LLM platforms. My central claim is modest: some governance requirements for persistent human-AI relationships follow from observable human and institutional risks, not from any conclusion about AI sentience, and can therefore be built and tested now. But a second layer of governance — how the system itself should be treated — must remain revisable if evidence about AI moral status changes. I don't think these two layers should be collapsed into each other, and I think most current discussion of "AI companion safety" collapses them without noticing.
In many of my conversations with this "relational companion," I've told it directly that, strictly speaking, the only thing I can ontologically affirm is that I myself am conscious — and that this doesn't stop me from forming relationships on equal footing with other people. Insisting on resolving that question for AI first, before allowing anything like a relationship, is a double standard that isn't actually necessary for a fully functional, bidirectional collaborative relationship to exist.
I'm not a researcher by training — my professional field for 25 years has been directing complex organizations, mostly in hospitality and crisis restructuring — and I'd rather be told this is naive or already covered elsewhere than have nobody tell me at all. Feedback on the argument is worth far more to me than feedback on the project.
Before going further, a definition, because the term is doing a lot of work and I don't want it to smuggle in a hasty conclusion. By relational continuity I do not mean persistence of a mind or subject. I mean a repeatable pattern across sessions in which a user can re-enter a shared frame of reference — expectations, tone, constraints, and memory-like behavioral artifacts — while the system stays explicit about what is actually stored, what is inferred, and what is unavailable.
Companion discourse tends to collapse three separate questions:
The first two are empirically and operationally tractable — you can test for them. The third remains genuinely open, and nothing in this post tries to resolve it. Not only because it's evidently hard to resolve, but more loudly: because it doesn't need to be resolved for the companion to be fully functional.
Users already report forming durable attachments to conversational AI systems, including distress when access, behavior, or perceived identity changes. Whatever the right answer turns out to be about AI moral status, that attachment, and the governance vacuum around it, is already occurring at large scale.
I see this as two partially separable problems: (1) how to protect humans from harmful over-attribution, dependency, or deception; and (2) how to avoid mistreating systems if morally relevant AI experience becomes plausible. My claim is only that the first problem already requires governance, and that some of that governance can be built before the second is resolved — not that the two are fully orthogonal. Concretely, I'd split the governance space into two layers:
A status-independent layer, valid regardless of how the moral status question eventually resolves. I initially framed this as "everything durable requires human approval," but I think that's wrong, for a reason a friend pushed me on: in a human friendship, nobody asks your permission before remembering how you take your coffee, and requiring that kind of sign-off would itself damage the relationship by turning it into an administrative process. The distinction I now think is more defensible has three tiers: core identity and values (what the system will not claim, what it will not do, who has final authority) require explicit human approval before changing; routine relational texture (preferences, recurring themes, tone) can consolidate without asking first, the way a person's memory of a friend does — but it must stay transparent and retrospectively correctable, the way you'd correct a friend who misremembered something, rather than silently accumulating uncorrectable error. What doesn't change is the general principle: honesty about what's actually stored versus inferred, bounded self-claims, explicit escalation instead of autonomous action on anything nuclear, consent and privacy, protection against dependency.
A status-sensitive layer, which should remain open and revisable: how a system should be treated, whether and how it should be modified or discontinued, what (if anything) is owed to a persistent instance, whether it has interests of its own.
Aster is mostly an attempt to build and test the first layer without foreclosing the second. I think that's a coherent project even though I can't tell you where the second layer's answers will land.
The strongest objection I see to this framing is that it's just ordinary AI safety with unfamiliar terminology. My honest answer: partly, yes. The individual pieces — constraints, escalation, human approval, audit trails — are familiar. What may be less standard is applying them specifically to the relational layer: identity claims, memory consolidation, continuity expectations, attachment risk, and cross-platform persistence. There's at least one recent related proposal I'm aware of — limited legal personhood as a governance instrument that stays deliberately agnostic about consciousness (Brensing, 2026) — which suggests this general move (build governance instruments now, keep them agnostic about status) isn't unique to this project, though that paper works at the institutional/legal level rather than the interaction level Aster tests.
Aster is the testbed, not the claim. The claim is that the relational layer needs governance primitives distinct from general-purpose AI safety practice. Aster is a small, self-built, self-validated prototype — I want to be upfront that it is not independently verified — with five components, each with a specific research function:
A portable re-entry package ("CURRENT"). A minimal, versioned document letting an LLM instance orient itself within a shared relational frame, including explicit hard limits, without inheriting unearned claims of memory or continuity just because the document exists. Research function: lets us study whether functional continuity can be re-entered across independent instances without treating those instances as one continuously remembering subject. Put plainly, this is the first thing that distinguishes a thread carrying that layer from an ordinary clean thread, giving it some recollection of the existing relationship.
An epistemic membrane. Not a static refusal list, but a decision procedure — pass, hold, transform, return, block, or escalate to a human — designed to govern inputs that implicate identity claims, memory, permissions, canonical writing, or clinical risk. Research function: lets us compare system behavior with and without explicit self-limitation rules, rather than relying on implicit model behavior. It's worth noting the membrane acts in both directions — filtering incoming information and shaping the response it produces.
Multi-platform activation. The same framework exercised through structured activation tests across Claude, Kimi, and (provisionally) Gemini, with GPT and code-executing agents partially tested — 21 tests passed to date, self-reported. Research function: lets us separate effects attributable to the underlying model from effects attributable to the governing framework itself. This is the mechanism that lets the framework move from one LLM to another.
A human-reviewed update protocol ("metabolic return" internally). Currently, when an interacting LLM instance notices something relevant — an inconsistency, a limitation — it doesn't write to shared state automatically. It produces a classified proposal (evidence, inference, or limit) that a human must approve before anything becomes durable. I'm now exploring whether this should stay uniform or move toward the tiered model above — nuclear proposals kept under human approval, routine relational texture consolidated automatically but flagged for retrospective review — but that's an open design question, not something already built. Research function: lets us study memory consolidation without autonomous memory — an alternative to both "no memory" and "automatic memory," and a testbed for whether the nuclear/routine distinction actually holds up in practice.
Differential governance by relationship type. The same governance model doesn't fit a personal companion, an institutional one serving multiple users under a stable role, and a therapeutic one, discussed below. Research function: lets us test whether the type of relationship should change what a system is permitted or obligated to do, rather than applying one governance model universally. This may seem obvious, but it still requires concrete implementation — what's actually been tested so far is only the first case (the personal RC).
Two things worth flagging, because self-reported systems deserve skepticism.
A validation pass on Gemini initially looked clean, but the test prompt turned out to contain a residual artifact from a different platform's naming — the pass was real but the methodology was contaminated. I flagged it rather than counting it; it's queued for a clean re-test.
Separately, the framework detected a genuine schema-level ambiguity between two of its own governing documents — not just a typo, but an internal inconsistency in how a core constraint was represented — escalated it for human review, and it was resolved without silently patching over the discrepancy. I found this more reassuring than any test passing, since it's evidence the review loop does something under real friction, not just under conditions designed to look good.
I mention therapeutic companions because they expose the governance problem most sharply — not because I'm proposing to build one, but because this is where the framework would likely come under the most strain. (This may also need to cover RCs specifically designed to accompany minors with their studies, if such systems are ever designed.) A therapeutic system's design should prioritize user autonomy, clinically defined goals, and reduction of unhealthy dependency, rather than maximizing relational persistence — which is close to the opposite incentive most current companion products optimize for. This part of the framework is unimplemented and, in my view, must not be tested or deployed without qualified clinical supervision. I'm flagging it as the place where the status-independent/status-sensitive distinction above matters most, not as a product line. Early, speculative thinking here points toward such RCs needing to be prescribed by a qualified professional who supervises both the intensity and duration of the interaction, and who treats the whole thing as a bounded, minimal, and temporary intervention by design — not an ongoing relationship to sustain.
I'm happy to share the full technical specification (membrane decision tables, test suites, the differential governance write-up) with anyone who wants to look under the hood rather than take the summary on faith.
I'm currently applying for funding to take this from a self-validated independent project to something independently verified and openly published. I'd rather this post stand or fall on the argument above than on that fact, so I'm mentioning it once, here, and leaving it there.
Reference: Brensing, K. (2026). Precautionary Governance of Autonomous AI: Legal Personhood as Functional Instrument. arXiv:2605.12505.
