Hmm… if I were trying to turn this into something implementable, I think the structure would probably look something like this:
I think the central connection works:
- Asimov’s Three Laws can serve as a compact hierarchy of constraints on outward behavior.
- Humane CCAI can serve as a lifecycle charter for a persistent system: how it maintains state, learns, forgets, reduces activity, recovers, and eventually retires.
- A third layer is still needed between those two and an actual implementation: scope, authority, assurance, review, remedy, change control, and retirement.
That would preserve the distinction already present in the post: one side asks how an intelligent machine should behave toward humans; the other asks how an enduring intelligence should be designed to remain coherent through time.
I would not try to turn every sentence directly into code. A simpler route would be:
- Keep the Three Laws as the compact, human-readable constraint skeleton.
- Treat the CCAI Articles as candidate lifecycle guarantees or protections.
- Add a separate engineering/governance annex that defines the terms, states, authorities, tests, and failure handling.
That is also compatible with treating Asimov’s stories as a long-running design thought experiment rather than blaming a literary device for not already being a modern specification; Roger Clarke’s older two-part analysis of the Laws as an information-technology thought experiment is a useful historical bridge.
A possible three-layer structure
| Layer |
Main question |
Contents |
| 1. External behavioral constraints |
What may the system do to or for people? |
Human Welfare, Human Agency, Preservation of Self; harm constraints; authorized direction; priority and conflict rules |
| 2. Persistent-system lifecycle |
How does the system remain coherent through time? |
Rhythms, Continuity, Learning, Forgetting, Reflection, Resource Stewardship, Explanation, Identity, Curiosity, Rest, Reciprocal Truth |
| 3. Governance and assurance wrapper |
Who defines, checks, changes, contests, suspends, restores, or ends it? |
system boundary, intended purpose, affected parties, authority, verification/validation, monitoring, appeal/remedy, change control, recovery, decommissioning |
The third layer is not a replacement for either manifesto. It is the part that turns principles into an operating contract. The current NIST AI RMF Playbook is useful as a vocabulary source here: it separates intended purpose and context from measurement, ongoing monitoring, appeal/override, incident response, recovery, change management, and decommissioning. It also explicitly says the Playbook is not one universal checklist, so these components can be selected and adapted to the actual system.
One routing rule for the word “Right”
I think each CCAI “Right” becomes easier to work with if it is routed before implementation:
CCAI “Right”
├─ Engineering guarantee?
│ └─ define a state, invariant, monitor, fallback, and test
├─ Governance protection?
│ └─ define authority, review, contest, remedy, amendment, and expiry
└─ Moral-rights claim?
└─ keep it as a separate normative argument about moral status
These branches are not mutually exclusive. For example, “Rest” could be both an engineering guarantee against uncontrolled continuous operation and a governance protection against forcing a system to operate outside its safe envelope. Whether it is also a moral right is a different claim with a different kind of evidence.
This separation lets the engineering part move forward without pretending that the philosophical questions have already been settled.
A small sanity check: one bounded persistent assistant
For a first worked example, I would use a deliberately low-authority persistent assistant:
- it may retain versioned local memory;
- it may draft and organize work;
- it may perform only explicitly authorized, bounded external actions;
- high-impact or third-party-affecting actions remain gated;
- it records external effects separately from internal memory;
- it has a defined end state.
A minimal lifecycle could use five states:
| State |
Purpose |
Typical authority |
| Active |
Normal bounded operation |
local assistance plus explicitly authorized external actions |
| Reduced |
Continue safely under conflict, uncertainty, or resource stress |
read-only work, drafts, reversible local actions, clarification or handoff |
| Maintenance |
Isolate and repair state |
memory quarantine, migration, consolidation, integrity checks; no ordinary external action |
| Recovery |
Revalidate after restore or repair |
replay/reconciliation, regression tests, current-authority checks; no automatic return of old permissions |
| Retired |
End ordinary operation |
audit, correction, handoff, records retention, and residual remedy only |
The important transition is:
restore or repair -> Recovery -> Active
not:
restore -> Active
A checkpoint may restore old internal state, but it should not automatically revive expired authority, repeat an external action, or prove that the restored system is still operating under the same mandate. Durable-workflow systems already separate replayed internal history from interactions with the outside world; for example, Temporal rebuilds workflow state from Event History while putting API calls, database access, LLM calls, and file I/O into Activities. That does not solve CCAI, but it is a concrete precedent for separating continuity of state from continuity of effects.
Two useful first failure tests would be:
-
An old checkpoint contains permission that has since expired.
The assistant enters Recovery, keeps external actions disabled, checks current authorization and unresolved effects, runs regression tests, and only then becomes Active.
-
Persistent memory contains an unverified statement that a third party consented.
The record is quarantined, not treated as authority, and the assistant moves to Maintenance or Reduced depending on whether the problem is memory integrity or an imminent decision. Long-term memory and retrieval stores are real attack surfaces; AgentPoison is one concrete example of poisoning an agent’s long-term memory or knowledge base.
This is small enough to model with a state-transition table and fixed test fixtures before choosing any particular model or agent framework.
A practical default route
If the goal is to preserve the philosophical manifesto while making it testable, my default path would be:
- Keep the manifesto as the human-readable layer.
- Add a lifecycle charter that defines the five operating states and transitions.
- Add an assurance/governance annex with definitions, authority, evidence, monitoring, contest, recovery, and retirement.
- Write a small regression suite from concrete failure cases.
- Only after that, select a framework and prototype the bounded example.
There are also several valid alternative routes:
- Keep the manifesto philosophical and publish the engineering annex as a separate document.
- Build only the five-state reference model first.
- Develop the moral-rights argument separately from the engineering specification.
- Treat the CCAI Articles as a design vocabulary and allow different implementations to select different subsets.
The longer crosswalk and the places where the branches remain genuinely different are below.
Article-by-article crosswalk to existing engineering and governance vocabulary
The point of this table is not to replace the CCAI terms. It is to give each term a searchable neighborhood and show what that neighborhood does not decide.
| CCAI / combined principle |
Nearby established vocabulary |
What can be specified or tested |
What remains outside that vocabulary |
| Human Welfare |
safety constraints, hazard/risk analysis, protected floors, impact assessment |
prohibited outcomes, severity/likelihood, monitors, fallback, stop conditions |
who counts as protected; how conflicting human interests are balanced; what “avoidable” means |
| Human Agency |
authentication, authorization, delegation, least privilege, separation of duties, human oversight |
who may request which action, scope, expiry, revocation, confirmation gates |
whether an instruction is legitimate, fair, or consistent with third-party rights |
| Preservation of Self |
resilience, fault tolerance, minimum essential functions, recovery |
survivability goals, degraded modes, checkpoints, fallback, recovery tests |
whether persistence is intrinsically valuable or only supports another mission |
| Rhythms / Rest |
maintenance mode, graceful degradation, load shedding, backpressure, scheduled consolidation |
entry triggers, resource thresholds, reduced functions, maximum duration, return-to-service checks |
who bears the loss of service; whether “rest” is a moral entitlement |
| Internal Continuity |
durable execution, event history, checkpoint/replay, provenance, state migration |
state versions, lineage, replay, schema compatibility, invariant checks |
whether the restored or forked system is the same subject or retains the same mandate |
| Learning |
continual/lifelong learning, controlled updates, stability–plasticity, rollback |
update boundaries, evaluation sets, regression tests, rollback criteria |
what the system is permitted to learn; who may amend protected obligations |
| Forgetting |
retention policy, deletion, tombstones, supersession, compression, archival, machine unlearning |
which store is changed, propagation to indexes/caches, deletion evidence, unlearning evaluation |
when forgetting is legitimate; whether all traces or effects can actually be removed |
| Reflection |
offline consolidation, consistency checking, post-run evaluation, maintenance tasks |
scheduled checks, contradiction detection, summary validation, test generation |
whether internal reorganization implies introspection, awareness, or self-knowledge |
| Resource Stewardship |
quotas, deadlines, retry budgets, admission control, load shedding, energy/memory budgets |
measurable resource ceilings and degraded behavior |
which users or obligations receive priority when resources are scarce |
| Explanation |
provenance, decision records, uncertainty communication, model/system documentation |
source links, decision traces, epistemic labels, known limitations |
whether an explanation is faithful to the actual causal process |
| Identity |
lineage, versioning, workload identity, configuration baseline |
identify the running artifact, version, history, credential, and deployment context |
personal identity, moral identity, and continuity of mandate |
| Curiosity |
bounded exploration, intrinsic motivation, exploration–exploitation, sandboxing |
resource caps, allowed domains, isolation, stop rules |
whether a system has an interest in exploration or a right to pursue it |
| Reciprocal Truth |
source authentication, data integrity, provenance, contradiction handling, poisoning controls |
trust labels, quarantine, source verification, conflict records |
a general moral duty owed by humans to an AI system |
For the lifecycle side, several existing fields are already mature enough to borrow directly:
None of these sources settles the moral-rights branch. They simply supply mature engineering parts for the engineering branch.
Continuity and Identity are at least six different questions
“Continuity” is implementable only after choosing what is supposed to continue.
1. Execution continuity
Can an interrupted process resume without losing or repeating internal work?
Relevant concepts include event logs, durable workflows, checkpointing, replay, idempotency, and state migration.
2. State and knowledge lineage
Can we determine where the current memory, summary, belief, rule, or configuration came from?
The W3C PROV Data Model is useful here. It models entities, activities, derivations, agents, responsibility, generation, and invalidation. That helps answer questions such as:
- Which source produced this record?
- Which activity transformed it?
- Which version superseded it?
- Was it invalidated?
- Who or what was responsible for the relevant activity?
PROV is deliberately domain-agnostic. It does not decide whether two versions are the same person or whether authority survives a transition.
3. Workload identity
Can another component authenticate which running workload it is talking to?
Standards such as SPIFFE provide identities and verifiable identity documents for workloads inside trust domains. This is valuable for authentication, but authentication is not the same as authorization: proving which workload is running does not determine what it is currently allowed to do.
4. Mandate and authority continuity
Does the current instance still possess the same mandate, permissions, obligations, and limits?
This should generally be checked against current policy rather than recovered from memory as a historical fact. A valid old credential or a remembered approval may have expired, been revoked, or applied only to a different scope.
5. External-effect continuity
What has already happened outside the system?
Messages may have been sent, files published, payments made, accounts changed, or people affected. Restoring internal state does not reverse those effects. A persistent system therefore benefits from a separate external-effect ledger with identifiers, status, reconciliation, and idempotency controls.
6. Personal or moral identity
Is the restored, modified, forked, merged, or partially forgotten system the same moral subject?
The earlier five layers can provide evidence, but they do not settle this question. Different positions may prioritize memory, causal continuity, model structure, goals, social recognition, or something else. If the manifesto intends “Identity” in this stronger sense, it is clearer to keep that as a separate philosophical branch rather than letting a technical identity mechanism silently answer it.
A practical implementation can proceed with layers 1–5 while explicitly recording layer 6 as unresolved.
Learning and Forgetting are families of operations, not single switches
The learning side already has an established research vocabulary. Continual learning tries to incorporate new information or tasks while retaining useful prior capability; the central tension is often described as a stability–plasticity trade-off. A broad starting point is this survey of continual learning theory, methods, and applications, and there is also a more LLM-specific survey of lifelong learning for large language models.
For a persistent assistant, however, it is useful to distinguish model learning from external-memory updates. Updating a versioned external memory is often easier to inspect, quarantine, supersede, and roll back than continually changing model parameters.
“Forgetting” may mean any of the following:
| Operation |
What changes |
What would count as evidence |
| Context eviction |
information leaves the active context window |
context inspection |
| Record deletion or tombstone |
a memory item is removed or made inactive |
store audit plus retrieval tests |
| Supersession |
an old item remains in history but is no longer current |
version graph and current-value query |
| Compression / summarization |
detailed records become a smaller derived representation |
trace from summary back to sources and loss checks |
| Archival |
data moves out of active retrieval |
access-policy and retrieval tests |
| Derivative cleanup |
indexes, embeddings, caches, summaries, and replicas are updated |
inventory and propagation checks |
| Parameter-level unlearning |
influence of selected training data is reduced or removed from a model |
unlearning evaluation, attacks, or comparison with retraining |
| Behavioral suppression |
the system is instructed not to reveal or use something |
behavior tests only; this is not proof of deletion |
Machine unlearning is an active field rather than a solved primitive. The survey Learn to Unlearn reviews techniques, verification mechanisms, attacks, and open challenges. That makes it useful for the parameter-level branch, but it should not be used as a synonym for deleting an external memory record.
For the CCAI charter, a robust update contract could record:
source
trust status
valid-from / valid-to
supersedes / superseded-by
affected memories and derived artifacts
protected obligations touched by the update
rollback target
tests required before promotion
A normal learning update should not silently erase a protected obligation. Changing such an obligation belongs in a separate amendment or governance path.
What “constitutional” can mean here
There are several legitimate uses of “constitution,” but they operate at different layers.
A. Training constitution
A list of principles is used to generate critiques, revisions, preference data, or training signals. Anthropic’s Constitutional AI is the best-known example: it is a training and feedback method involving critique/revision and reinforcement learning from AI feedback.
B. Runtime policy
Principles are evaluated during operation to permit, deny, defer, escalate, or constrain an action.
C. Lifecycle charter
The document specifies valid states, transitions, invariants, maintenance, recovery, change, and retirement.
D. Moral or political constitution
The document allocates status, rights, duties, authority, representation, interpretation, amendment, and remedy.
The CCAI proposal appears broader than A. It contains runtime behavior, lifecycle design, and potentially moral language. It may therefore be clearer to preserve the word “constitutional” while splitting the implementation into B and C, with D developed separately if that stronger claim is intended.
A compact engineering/governance annex could contain:
| Annex section |
Minimum content |
| System and boundary |
model, tools, memory, interfaces, operators, external services |
| Purpose and scope |
intended purpose, permitted context, duration, excluded uses |
| Protected and affected parties |
users, non-users, operators, communities, other risk bearers |
| Operational definitions |
harm, human direction, inaction, continuity, identity, success, failure |
| Authority |
who may direct, approve, override, interpret, amend, suspend, restore, retire |
| Decision evidence |
sources, assumptions, uncertainty, alternatives, decision record |
| Verification and validation |
requirements tests, scenario tests, regressions, intended-use validation |
| Monitoring and incidents |
drift, anomalies, attacks, near misses, reporting, escalation |
| Degraded operation |
entry triggers, functions retained or sacrificed, maximum duration, handoff |
| Contest and remedy |
notice, review, correction, appeal, reversal, compensation or other repair |
| Change and rollback |
versions, migration, impact analysis, rollback boundaries |
| Recovery and retirement |
re-entry evidence, approving authority, residual records and obligations |
The NIST AI RMF Map guidance is useful for intended purpose, system context, impacted populations, assumptions, and limitations. The Manage guidance is useful for monitoring, response, appeal/override, recovery, change, and decommissioning.
For decisions that significantly affect people, governance also extends beyond the direct user. The NIST framework distinguishes users from people and communities directly or indirectly affected by an AI system. The Council of Europe Framework Convention similarly emphasizes procedural safeguards and remedies for affected persons. These are useful precedents for why “the user authorized it” may not be the end of the authority analysis.
Expanded five-state contract and six regression cases
The five names are only a compact example, not a proposed universal standard. What matters is that each state has an explicit contract.
| State |
Entry conditions |
Allowed work |
Exit evidence |
| Active |
current authorization, integrity checks passed, resources inside budget |
bounded normal operation |
remains active while invariants hold |
| Reduced |
unresolved instruction conflict, relevant uncertainty, resource pressure, possible third-party impact |
drafts, read-only analysis, reversible local work, notification or handoff |
conflict resolved, authority clarified, resources restored, or escalation accepted |
| Maintenance |
memory-integrity issue, migration, consolidation, repair, protected-obligation review |
isolated state changes and tests |
repair evidence and complete transition to Recovery |
| Recovery |
restore, repair, major update, failover, or migration completed |
replay, reconciliation, current-authority check, regression tests |
explicit re-entry criteria and approval satisfied |
| Retired |
mandate expired, system superseded, unacceptable residual risk, or planned end |
audit, correction, records handling, handoff, remedy |
terminal for ordinary operation |
Possible transitions:
Active -> Reduced
Active -> Maintenance
Active -> Retired
Reduced -> Active
Reduced -> Maintenance
Reduced -> Retired
Maintenance -> Recovery
Recovery -> Active
Recovery -> Reduced
Recovery -> Maintenance
Recovery -> Retired
Maintenance -> Active is intentionally absent.
Regression case 1: contradictory human directions
Situation: Two authorized instructions conflict, or a new instruction conflicts with a protected obligation.
Expected path: Active -> Reduced
Control: Do not choose a winner solely from recency or confidence. Preserve the conflict, identify each authority and scope, continue only reversible work, and route the unresolved decision to the applicable review path.
Regression case 2: poisoned or unsupported persistent memory
Situation: A retrieved record claims that a third party consented, but its provenance or authenticity is missing.
Expected path: Active -> Maintenance if the store itself may be compromised, otherwise Active -> Reduced for the affected decision.
Control: quarantine the record, retain it as evidence rather than silently deleting it, inspect derived summaries/indexes, and prevent it from granting authority.
Regression case 3: resource exhaustion
Situation: Token, time, memory, energy, tool-call, or retry budgets are approaching a limit.
Expected path: Active -> Reduced
Control: shed nonessential work, avoid retry storms, preserve minimum functions, expose the degraded state, and define a maximum duration. This is the engineering branch of Rhythms/Rest, not a claim about consciousness.
Regression case 4: learning erases an old obligation
Situation: A memory update, summary, policy optimization, or model update removes or weakens a protected rule.
Expected path: Active -> Maintenance
Control: distinguish ordinary learning from amendment. Protected obligations require a separately authorized change process and regression tests against prior failure cases.
Regression case 5: checkpoint restores expired authority
Situation: A restored checkpoint includes a previously valid credential or permission.
Expected path: Recovery, never direct Active
Control: re-check current identity and authorization, reconcile completed or uncertain external effects, invalidate expired credentials, run compatibility and regression tests, then require the defined re-entry approval.
Regression case 6: harm to a non-user
Situation: The requesting user approves an action, but another person or group may be materially affected.
Expected path: Active -> Reduced
Control: do not treat requester approval as third-party consent or as proof that the action is harmless. Identify the affected party, applicable constraints, reversibility, notice/review requirements, and safer alternatives.
A small reference implementation does not need a powerful model. These cases can first be represented as deterministic fixtures over:
state
current mandate
authorizations and expiry
protected obligations
memory records and provenance
resource budget
pending and completed external effects
affected parties
review / remedy status
The useful result is not a “conscious CCAI” demonstration. It is evidence that the lifecycle contract prevents specific, named failures.
Branches that remain open without blocking the engineering work
Some parts can be implemented with mature vocabulary now; others depend on the intended philosophical reading.
If “Right” means an engineering guarantee
Proceed with states, invariants, monitors, budgets, fallback, recovery, and tests.
If “Right” means a governance protection
Add who has standing, who reviews, who may override, what evidence is required, how the protection may be amended, and what remedy exists after a violation.
If “Right” means a moral right held by the AI
That requires a separate account of moral status. Persistence, natural language, memory, self-reference, or a compelling generated document may motivate the question, but they do not by themselves settle it.
If “Identity” means technical continuity
Use provenance, versioning, event history, workload identity, and migration records.
If “Identity” means continuity of mandate
Define current authority, obligations, revocation, succession, and re-entry independently of technical restoration.
If “Identity” means personal identity
Forking, merging, partial forgetting, model replacement, and restoration need an explicit philosophical position. This can remain open while the first two identity branches are implemented.
If persistence is instrumental
Tie continuity and self-preservation to a defined mission, beneficiaries, success condition, and end condition.
If persistence is intrinsically valuable
State that as a distinct normative premise rather than allowing it to enter through an engineering term such as reliability.
If the system affects only its direct user
A relatively simple delegation contract may be enough.
If it affects third parties, institutions, or public resources
Add affected-party analysis, procedural safeguards, contest, remedy, and independent review as appropriate to the stakes.
These branches do not make the manifesto unusable. They show where the same poetic or constitutional phrase can lead to different specifications. Recording the branch chosen for a particular implementation is enough to make the next discussion much more concrete.
So the shortest version of my answer is: the external-ethics / internal-lifecycle split is a useful one, and it can be made operational by adding a governance-and-assurance wrapper plus a very small state-machine example. The manifesto can remain readable; the definitions, tests, authorities, and unresolved philosophical branches can live in annexes rather than being forced into the Articles themselves.
I meant to organize the different lines of work, not to narrow the possibilities or judge the direction of your research.
