Society, culture, and law

From versioned culture content to law versions: cultural signals supply evidence, and institutions decide the outcome.

This page covers two optional domain extensions that work as one pipeline. canwu-culture, the culture system SDK, turns authored culture content into population-level social signals. canwu-law, the legal institutionalization extension (experimental), lets authorized institutions turn those signals into versioned law through a procedure. Read this page if your game models ideas, norms, or movements that can end up in law.

canwu-culture builds on the public API and on canwu-society, the social diffusion simulation module; canwu-law builds on the public API only. Culture, legal meaning, and period content all stay outside the simulation core.

One rule connects the two halves: culture produces evidence, and law changes only through an authorized institutional procedure. Popular support can open or strengthen a legal proceeding; only the procedure can enact a statute.

Ownership and layering

Rendering diagram…

View diagram source

flowchart TB
  Content["Reference content pack<br/>CultureDefinition"] --> Culture["canwu-culture<br/>validate and compile"]
  Info["Information and correspondence<br/>extensions"] -- "exposure batches" --> Culture
  Culture --> Society["canwu-society<br/>sparse social runtime"]
  Culture -- "emits" --> Signals["CulturalSignalBatch<br/>next-boundary ingress"]
  Signals --> Law["canwu-law<br/>proposal, procedure, LawVersion"]
  Law --> Downstream["Downstream readers<br/>elections, administration,<br/>justice, enforcement"]

canwu-culture is the authoring and compilation layer above canwu-society. It takes a CultureDefinition, checks it against its budgets, and compiles an immutable execution plan bound to a content hash.
canwu-society is the runtime. It holds sparse population distributions, social influence edges, organization topology, institutional inputs, and actor-relative projections.
canwu-law sits downstream of cultural signals. It owns jurisdictions, legal institutions, procedures, proposals, enacted rules, effective times, amendment, repeal, expiry, and legal interpretation.
Downstream code, such as election, administration, justice, or enforcement logic in your application, reads enacted law at its own boundaries.

Dependencies point one way. Information and correspondence feed culture, culture emits generic signals, and law consumes them. canwu-law depends only on canwu-api: it receives culture signals as ingress and has no compile-time dependency on canwu-culture. canwu-core, canwu-sim, and canwu-api know nothing about legal meaning. Extensions exchange bounded batches through canonical ingress that the next boundary admits. They do not call each other synchronously and do not write each other’s state.

Culture authoring contract

Build a CultureDefinition with CultureDefinition::builder(id), or deserialize one with serde, for example from JSON produced by a content tool. CultureDefinitionBuilder::build and compile_culture run the same validation, so hand-built and generated content follow identical rules. A definition that exceeds any limit in its CultureBudgets is rejected before settlement starts. The budgets cap the number of each component, fan-out, signals per batch, evidence per signal, tombstones, text length, persisted state size, and memory.

Definition components

Component	Type	What it declares
Target	`CultureTargetDefinition`	An idea, norm, movement, practice, school, or affiliation, with an optional parent target, a neutral disposition profile, and metadata
Cohort	`CultureCohortDefinition`	An aggregate population with a territory, an integer headcount, and application-defined classifications such as language, occupation, or status
Channel	`ChannelSpec`	An exposure path for one target from a source cohort to a target cohort: reach, trust, interpretation fidelity, delay in boundaries, and capacity
Transition	`TransitionSpec`	A move between two disposition profiles for one target and its affected cohorts, with a base rate per million and weights
Institution binding	`InstitutionBinding`	An institution entity whose decisions affect one target and a set of cohorts
Effect binding	`CulturalEffectBinding`	A signal to emit for other extensions: signal kind, scope, cadence in boundaries, persistence class, and whether evidence is required

A definition also carries its budgets and one RetirementPolicy, which sets how many quiet boundaries pass before a target goes dormant and before it may retire.

A disposition profile places a cohort on seven dimensions: awareness, assent, practice, public alignment, organizational tie, mobilization, and visibility (DispositionProfile in canwu-society). Institutions act on cohorts through canwu-society policy pressure (PolicyPressure), which covers support, legal access, surveillance, censorship, coercion, material penalty, disruption, and migration pressure. No policy field sets private assent directly.

The definition has no free-form trait or value map per population bucket. Express traits and affinities through transition weights and channel settings, so the runtime stays bounded and works per cohort.

Compiled plan and hot path

compile_culture turns a definition into a CompiledCulturePlan. The plan holds dense numeric keys (TargetKey, CohortKey, and so on), canonically sorted rule tables, reverse indexes by target, compact channel, transition, effect, and institution tables, the budgets, the retirement policy, and a content hash. Per-target lifecycle indexes live in the separate CultureState.

A compiled plan is fixed for one scenario and run revision. Changing the definition or the compiled order produces a new plan with a new content hash.

Incremental settlement and scale

Culture settlement works from a dirty set: the (cohort, target) pairs that something touched since the last settlement. An admitted exposure, a policy change, an organization change, or a reactivation marks the affected pairs. A settlement boundary then:

consumes admitted signals in canonical order;
evaluates the dirty pairs and their bounded dependents;
updates aggregate counters incrementally;
refreshes projections only for observers who can see a changed pair;
emits bounded effect batches for the next consumer boundary.

With Delta dirty pairs, B population buckets per pair, E_delta affected edges, and V_delta affected observer entries, the intended steady-state cost is about O(Delta * B + E_delta + V_delta). Full rebuilds are for definition changes, migration, and explicit maintenance.

Culture lifecycle

Every target has a generation number and one of three states from CultureLifecycle: Active, Dormant, or Retired.

Rendering diagram…

View diagram source

flowchart LR
  Active["Active"] -- "quiet window passes:<br/>no engaged population, no admitted work" --> Dormant["Dormant"]
  Dormant -- "admitted work<br/>(same generation)" --> Active
  Dormant -- "retention passes and<br/>no live dependency" --> Retired["Retired"]
  Retired -- "explicit reactivation<br/>(new generation)" --> Active

Active and dormant

An Active target has an engaged population, active propagation, institutional or policy inputs, or a scheduled reactivation. Its distributions, rules, and projections take part in ordinary settlement.

A target becomes Dormant after the configured quiet window passes with no engaged population and no admitted work. Engaged headcount differs from the distribution total: cohorts that are only in the neutral profile do not keep a target active. Dormancy removes the target from the culture hot and dirty indexes. After the society lifecycle is synchronized, the target’s compiled transition rules also stop running. Existing society distributions and a compact reactivation descriptor remain. New admitted work makes the target active again in the same generation.

Retirement and atomic synchronization

A dormant target may retire after its retention period, once all signals admitted for the boundary are applied and nothing live still needs its current generation: no transition, organization, institution, policy, effect batch, admitted input, or scheduled continuation.

Retirement writes a compact RetiredTargetTombstone: the target ID and generation, the last active time, the retirement time, the reason, the policy hash, an optional successor, and the evidence references that replay and audit need. It frees only society state for that target that can be rebuilt. Historical domain-record versions, events, actor knowledge, and archived evidence stay queryable.

With the host-driven CulturePlugin, the host calls settle_culture_society_boundary. It prepares a bounded runtime delta and stages society changes only when a lifecycle transition happens. If a live dependency outside culture exists, retirement fails before any caller-owned state changes. The host saves the culture record, the society state, and the typed lifecycle transition in the same boundary. synchronize_society_lifecycle scans the full state and is meant for load repair and explicit maintenance checkpoints.

Retirement leaves other extensions’ live organizations, policies, influence edges, rules, and bindings in place. Exposure for a retired generation is rejected until an explicit reactivation command or ingress is admitted. Reactivation cites the old tombstone, starts a new generation, and initializes only the active relationships it needs; history is kept as it was, and former cohorts do not come back automatically.

In-engine settlement with the culture boundary plugin

A run can let the engine settle the culture lifecycle. It registers the culture boundary plugin, CultureBoundaryPlugin, beside the society plugin in place of CulturePlugin. A run uses one flow or the other:

	Host-driven flow	In-engine flow
Plugin	`CulturePlugin`	`CultureBoundaryPlugin`
Who settles the lifecycle	The host calls `settle_culture_society_boundary`	The Monthly phase-7 system `culture_lifecycle_settle_v1`
Who writes society state	The host, in the same boundary	The society plugin, from queued `society_lifecycle_delta_v1` packets

A run that registers CultureBoundaryPlugin must not also call settle_culture_society_boundary. The in-engine flow works like this:

The scenario installs the culture definition record built with culture_definition_record, the culture state record, and a society state prepared with install_into_society. Boundary handlers are plain function pointers, so the plugin recompiles the definition record each month instead of holding a compiled plan.
Information or correspondence providers submit resolved exposure as public culture_exposure_v1 ingress. Each exposure signal batch (CultureExposureSignalBatch) names the target ID and generation, the cohort scope, the interpretation fidelity, the evidence, and the earliest boundary it may be settled in. An event-driven phase-12 intake system queues admitted batches. A batch for a different generation is rejected with the culture_exposure_rejected_v1 event.
The Monthly phase-7 system culture_lifecycle_settle_v1 consumes the queue and the accepted institutional decisions on culture alignments. It derives engagement and live dependencies from the society snapshot, calls settle_culture_society_boundary on that snapshot, and saves canwu.culture:state. A target that an institution has decided on counts as a live dependency, so it neither goes dormant nor retires.
For each target that changed state, the plugin schedules one internal society_lifecycle_delta_v1 packet. The society plugin queues it in phase 12 and applies it at its next Daily settlement, so it stays the only writer of canwu.society:state. If society refuses a delta, the refusal is recorded and the delta is not forced. At each later Monthly settlement, the plugin compares society state with the committed culture lifecycle and re-sends any delta that is still missing; society applies deltas idempotently.
Each due compiled effect becomes a cultural_signal_batch_v1 ingress addressed to the culture plugin itself. Consumers such as the law plugin admit it at the next boundary and check which plugin produced it.

A rejected lifecycle step emits culture_lifecycle_rejected_v1 and leaves culture state unchanged. Each settled transition emits culture_lifecycle_transition_v1. All phase-7 systems read the same boundary snapshot, so a culture step reaches society state up to two boundaries later.

From cultural signal to law

Information and correspondence first resolve whether an actor had access to a message and how it was interpreted. They may then emit a bounded CultureExposureSignalBatch, the payload of culture_exposure_v1. Culture settlement updates the disposition dimensions and emits a bounded CulturalSignalBatch. Each CulturalSignal in it carries the effect ID, target ID and generation, signal kind, persistence class, scope, strength, emission time, and evidence. For law, a batch is evidence only.

Rendering diagram…

View diagram source

flowchart TB
  Signal["CulturalSignalBatch<br/>evidence only"] --> Proposal["LegalProposal<br/>proceeding opens or advances"]
  Proposal --> Ticket["DecisionTicket<br/>for each seat holder"]
  Ticket --> Choice["Controller selects an option<br/>DecisionAttempt / DecisionTrace"]
  Choice --> Intent["Accepted command<br/>records a pending legal intent"]
  Intent --> Commit["Later law boundary revalidates<br/>and commits the shard bundle"]
  Commit --> Version["LawVersion"]
  Version --> Readers["Downstream readers<br/>and feedback evidence"]

The law plugin processes only proposals and jurisdictions that are dirty or due:

Reverse indexes map each signal kind and scope to the affected jurisdictions and open proposals. Unrelated law is not scanned.
Typed LegalMutation values arrive as legal_mutation ingress, and holder context arrives as legal_actor_context ingress. The plugin checks:
- plan and version bindings: the compiled-plan binding, the exact directory and shard versions, and the host-owned expected_versions;
- the cited culture generation;
- the signal provider (plugin, packet_type) declared in the legal definition, and the boundary in which the kernel committed the provider’s packet;
- spoofed signals: it ignores a signal kind that the caller merely claims, and a packet that the host injects into the provider’s namespace does not count as evidence;
- publicity: a publicity event must match the provider’s retained payload in the exact proposal, occurrence time, medium, and scope.
When a proceeding needs votes, the plugin writes a DecisionTicketDraft to an outbox for each seat holder. The host moves drafts into the decision system in three persisted steps: prepare_pending_decision_enqueues, then enqueue_pending_decisions, then acknowledge_enqueued_decisions, which queues a legal_outbox_enqueued acknowledgement. The acknowledgement is accepted only when the controller registration and ticket opening were both Accepted and still match the saved draft.
An authorized controller selects one of the existing options. The accepted submit_pending_intent command can only record a bounded pending legal intent; it does not write law.
A later law-plugin boundary rechecks competence, procedure, revision and effective-time guards, clause and evidence limits, and the culture generation. It then commits the legal shard bundle atomically. Downstream code reads the result at its own boundaries.

If a seat’s controller does not exist, canwu-law creates a default Human controller. A host may instead register the same stable controller ID in advance with a Utility, Rule, Random, External, or Llm policy. The law plugin keeps that policy when its authority, seat, permission profile, and command subject match the compiled plan exactly. A Random policy decides through an operation-keyed boundary draw. An External or Llm policy returns one existing option ID through the strict selector DTO. No policy can change the legal options or the authority.

A consumer that cannot accept a batch records a rejection or defers it, leaving culture and law state untouched.

Legal records and procedure

A LegalDefinition declares legal orders, jurisdictions, institutions, procedures, clauses, source profiles, signal providers, applicability profiles, predicates, forums, and precedence profiles. compile_law turns it into a hashed, budgeted plan.

LegalJurisdictionDefinition gives a jurisdiction a stable ID, metadata, and typed relations to other jurisdictions: delegation, territorial containment, supremacy, appeal, treaty membership, or overlap.
LegalInstitutionDefinition binds an institution to an optional organization entity, its jurisdictions, its authority seats (each with an optional holder and a permission profile), its procedures, and its competences.

Jurisdictions and institutions are part of the compiled legal plan. They are not new core entity kinds, and the host cannot edit them as separate records. Compilation requires every procedure seat to resolve to exactly one institution that declares both the procedure and the seat. The seat’s holder, permission profile, and a collision-free, length-prefixed controller ID are frozen into the plan. Missing or ambiguous authority fails compilation, before the run starts.

Weighted, unit-block, and consultation stages

A procedure is a list of stages (ProcedureStageDefinition). A deciding stage can weigh seats and count unit blocks, and a procedure can include an advisory consultation stage.

Vote weight. seat_weights gives a seat an integer weight; a seat without an entry weighs 1, so an empty map counts every seat equally. quorum is compared with the summed weight of seats that cast any ballot, abstentions included. threshold is the share of For weight among For plus Against weight, in thousandths, that the stage needs. Vetoes are seat powers and are never weighted.
Unit blocks. block_of_seat puts every seat of a stage into exactly one unit block, and block_threshold, from 1 to the number of blocks, sets how many blocks must take the For position. A block takes the weighted-majority position of its seats. A block whose weights are evenly split, or whose seats cast no For or Against ballot, takes no position. A stage with blocks passes only when its weighted seat rule holds and enough blocks are For.
Tie-breaks. When as many blocks are For as Against, the procedure’s deterministic_tie_break applies; only procedures with a blocked stage read it. status-quo adds no block, so the tied stage passes only if block_threshold is already met, and otherwise waits for more ballots or its deadline. casting-seat:<seat> adds one For block when that seat’s own ballot in the stage is For. The casting seat must sit in every blocked stage, and each block threshold must exceed half the blocks, so a tie cannot pass without it. Stages without blocks have no tie-break; use a threshold of 501 when an even split must fail.
Consultation. A Consultation stage (ProcedureStageKind::Consultation) is advisory. Its seats receive tickets whose context carries "advisory": true. Their ballots are kept as participation records but never count toward completion, veto, or adoption. The stage needs a positive deadline and no quorum, threshold, weights, or blocks, and it cannot be the last stage of a procedure. It completes at the first law-plugin boundary after its deadline, expires unanswered seat work, and opens the next stage; zero ballots is a valid result. A procedure that still lacks its capacity reservation at that deadline expires instead.

The compiler checks these rules before the run starts. Unused fields are left out of the JSON, so existing plans keep their encoding and content hash. When a stage stops accepting ballots (it passed, completed, or its procedure closed), its pending and enqueued seat work expires. A seat response that arrives afterwards is recorded as a rejected outcome, and the law boundary still succeeds. The budget check before settlement also counts ticket work emitted at the exact deadline minute.

Proposals, sources, and law versions

A LegalProposal is a versioned proceeding input that has not been enacted. It records the proposal ID, sponsor, legal order, jurisdictions, subjects, clause operations, source and procedure profiles, deadline, effective time, the LawOperation, the target rule, cultural dependencies, claimed competence, defects, validity, origin, and evidence. Its status is one of draft, submitted, deliberating, adopted, rejected, expired, or withdrawn. Kernel authorization proves who submitted a command; it does not make an act valid in the world when the institution lacked legal power. A proposal may cite a culture target generation as evidence, and that citation gives the target no power over the proposal.

Institutional competence is deny-by-default across legal order, jurisdiction, subject matter, source mode, operation, procedure, forum, and adjudicative power. Each source profile also declares its authority basis (procedural institution or evidence claim), origin and publicity policies, the compiled publicity signal provider, evidence bounds, claimant rules, and whether retrospective effect is allowed. Promulgated sources always go through a procedure. Agreed sources require an exact instrument kind, at least two parties, and ratification evidence. A publicity event is admitted only in the boundary where its provider ingress actually occurs; a planned future publication does not count as one.

An accepted proposal creates one immutable LegalSourceVersion, the stable LegalRule, and one immutable LawVersion.

The source keeps the proposal and its ruling, agreement, or reception origin. Its mode is Promulgated, Adjudicated, Accreted, Agreed, or Received.
The rule tracks its latest claim separately from its operative version. A Purported or Contested change is therefore visible while the earlier valid version still governs.
Publication is a separate immutable LegalPublicityEvent bound to the proposal, time, medium, scope, and evidence. Under a ValidityCondition policy, adoption fails without it. Under an EffectivenessCondition policy, the proposal may be adopted first, but the new version stays inert and absent from historical reads until publication, which must happen no later than the effective time. Late publication appends the event and updates the proposal lifecycle and the derived rule state; the create-only source and law version are not rewritten. Retroactive effect needs both profile permission and an explicit retrospective date.

A LawVersion records the rule ID, a monotonic legal ordinal, the operation, the applicability profile, jurisdictions, adoption and effective times, source and origin, predecessor versions, normative effects, evidence, and cultural dependencies. Every compiled clause declares its normative modality, such as duty, prohibition, liberty, claim right, or power, instead of deriving it from display text. Rights and eligibility rules name holders, duty bearers, subject matter, conditions, standing, forum, and remedy profile. Amendment and repeal are new legal commands that append new versions. Enacted law stays in force when its culture target retires.

Applicability queries

An applicability query asks which law governs a situation. It runs over one legal order and one compiled applicability profile, within a work budget:

It filters by time, territory, persons, subject matter, and jurisdiction; applies compiled condition and exception predicates and precedence; and returns the governing versions, displaced claims, conflicts, and a trace. The result is an ApplicabilityOutcome: Applicable, NotApplicable, Displaced, Contested, or Indeterminate.
A missing predicate fact gives Indeterminate. A false condition or a true exception gives NotApplicable. Unresolved validity gives Contested, together with the earlier operative version and the rival claim.
Every fact cites its evidence. An actor-relative query binds a KnowledgeReadCut and one holder record per fact. query_applicability_with_host checks the holder, the complete cut, the compiled knowledge schema, the JSON boolean pointer, the asserted value, and the evidence. The detached API rejects actor-relative queries.
Succession does not inherit a predecessor’s legal order by default. Reception uses the longest matching rule prefix within the succession’s personal and territorial scope, then applies the received rule’s own subject-matter scope. Continue exposes the predecessor directly; Transform and Review need an explicit Receive operation bound to the exact succession and predecessor, and Transform also binds one compiled target clause.
Jurisdiction reachability uses adjacency compiled once per relation kind and direction. One total work budget covers graph edges, rules, historical versions, predicate visits, and conflict fan-out, and a per-record budget is checked before the query traverses proposals, cases, rulings, or conflicts.
A resolved conflict stores its total, governing, and displaced version sets with a typed basis, jurisdiction, recorded time, effective interval, and rationale. All active resolutions are merged at once; if one version ends up both governing and displaced, the result stays Contested and does not depend on conflict IDs. Cases, findings, and rulings are also limited by the compiled forum, proof, standing, remedy, precedent, interval, issue, and adjudicative-competence rules.

Effect persistence semantics

Each culture effect binding has a persistence class (EffectPersistence). Law interprets the classes as follows. When a law version depends on culture, it records the dependency as CulturalDependencyKind::AdoptionEvidence or CulturalDependencyKind::LiveLevel.

Culture effect	Legal interpretation
`Pulse`	Opens or updates a proposal opportunity; no durable law exists yet.
`Level`	Supplies current support or legitimacy pressure. When it ends, it may prompt a review; repeal remains a separate legal operation.
`Commitment`	Once a legal command accepts it, it is the provenance of a durable `LawVersion`. Retiring the culture target does not retract it.
`Evidence`	Historical citation only; it cannot open or change a proceeding by itself.

When a legal rule depends on a live cultural level, the law extension records that dependency (LiveLevel) and owns the rule for review, expiry, or renewal. Culture only reports that the level ended. A live-level dependency that is operative, or scheduled to become operative, blocks the target’s retirement. A commitment accepted into law (AdoptionEvidence) does not keep a culture target active, so the target may retire while the law stays in force. The law keeps a compact, Merkle-bound receipt of the adoption evidence; the retired target’s propagation indexes and old payloads leave the hot path. Repeal and expiry always need an explicit legal operation.

Retirement is explicit, bounded maintenance. The law plugin keeps culture-dependency records keyed by target and registers as a dependency resolver for the canwu.culture namespace. To retire a target, the culture owner and every registered resolver each submit a proposal limited to their own records. The kernel checks the complete set against one persistent domain root and commits all participants or none. Missing proposals, writes to another owner’s records, stale versions, and budget overflow fail before any culture or legal state changes. Ordinary legal settlement never scans the full legal history to prove that retirement is safe.

Authority, visibility, and replay

Legal commands follow Canwu’s ordinary authority chain, shown in the diagram above: legal facts open a DecisionTicket, a controller selects an option, the choice is recorded as a DecisionAttempt and DecisionTrace, the command enters through canonical ingress, and the law plugin validates authority and procedure before a LawVersion commits.

The command subject must be the subject frozen in the proposal; separate compiled competence decides legal power in the world. The command’s CommandContext carries the validated decision_controller_id, the request ID, the expected revision and time, and a CommandAuthority with the decision origin, seat, permission profile, and command subject. An external service or model may recommend an option. It cannot create authority or submit a raw law payload that skips the ticket.

Public enacted law may be exposed through a domain projection. Private drafts, dissent, and actor-specific knowledge go through ViewerContext and the holder’s ledger, with no fallback to ground truth. Culture and legal records implement DomainRecordType with strict schemas, typed references, explicit mutation policies, and retained version bodies where evidence needs exact historical meaning.

Snapshot format 8 saves legal state as separately versioned plan, directory, order and jurisdiction shard, coordinator, culture-dependency, and archive-head records. Loading admits only the declared working set and rebuilds derived indexes, authenticated archive roots, and hot projections before exposing state. Exact replay consumes the recorded mutation, signal, decision, command, acknowledgement, and wake ingress plus boundary evidence; it never reruns a human, service, or model policy. A fork copies validated state and continues with new causal inputs. A failed boundary restores indexes, tombstones, counters, evidence, and random positions together.

Full history and derived-index validation runs on cold load or restore. Live boundaries check the immutable plan and budget bindings and local mutation guards, without rescanning the legal history for each mutation. The latest live disputed claim keeps its identity evidence until a replacement supersedes it.

Bounded work and conformance

The legal plan compiles numeric IDs for jurisdictions, institutions, proposals, clauses, and procedure profiles; reverse indexes by signal kind and scope; dirty proposal and jurisdiction sets; per-procedure limits for clauses, evidence, options, fan-out, and pending continuations; and a plan hash and budget manifest. With P_delta dirty proposals, C_delta affected clauses, and V_delta observer entries, the intended steady-state cost is about O(P_delta + C_delta + V_delta). Deadline and effective-time wakes use ordered indexes, and both deleted and inserted applicability rows count against the mutation budget. Retired targets and historical law catalogs do not raise the cost of settling active proposals.

That cost covers work inside one shard; cold legal history does not add to the cost of an ordinary boundary. The 2026-08-30 release probe records the measurements.

Archiving moves historical payloads out of live state; current law is unchanged. If the archive provider is missing, queries report that history is unavailable. The host completes each archive with finalize_legal_archive_retention. Garbage-collection, paging, and recovery details are in the legal storage proposal.

Conformance evidence for an implementation should show that:

cultural signals cannot change legal records directly;
only an authorized, controller-bound command can enact, amend, or repeal law;
stale proposal, ticket, and law revisions become safe, persisted rejections;
a commitment accepted into law survives culture retirement;
an unresolved live-level dependency blocks culture retirement, and so does one that becomes operative in the future;
expired procedures expire their unresolved pending and enqueued outbox work;
a stage that stops accepting ballots expires its seat work, and a late seat response becomes a rejected outcome;
with the culture boundary plugin, the society plugin stays the only society writer and the run replays exactly;
proposals, law, evidence, archives, snapshots, forks, and exact replay stay consistent;
unrelated targets, observers, and retired catalog entries do not change keyed results or declared work budgets.

Modeling examples

A women’s suffrage content pack might emit public-alignment, organizational-capacity, and legitimacy-pressure signals. A competent assembly selects a voting-eligibility option through a DecisionTicket. The accepted command records an intent, a later legal boundary commits it as a voting-eligibility rule with a deterministic effective date, and the election code reads the law. The content pack must define “adult women” in its historical context: citizenship, race, property, marital status, colonial status, and registration rules can combine into overlapping exclusions. If the culture target later retires, new propagation stops, and the enacted rule and its enforcement history remain.

An Enlightenment and human-rights content pack should likewise avoid a single line in which European ideas turn into modern rights on their own. It can model plural intellectual roots, translation, print, education, and association as separate transmission networks, alongside countermobilization by religious, dynastic, local, and incumbent interests. Those signals can change public alignment, organizational capacity, legitimacy pressure, and decision evidence. Different legal orders can still adopt only part of a claim, reinterpret it, delay its publication, enforce it selectively, or reject it.

Society, culture, and law

Ownership and layering

Culture authoring contract

Definition components

Compiled plan and hot path

Incremental settlement and scale

Culture lifecycle

Active and dormant

Retirement and atomic synchronization

In-engine settlement with the culture boundary plugin

From cultural signal to law

Legal records and procedure

Weighted, unit-block, and consultation stages

Proposals, sources, and law versions

Applicability queries

Effect persistence semantics

Authority, visibility, and replay

Bounded work and conformance

Modeling examples

Further reading