core/docs/acbcontent/CORE_operating_constraints.md

CORE — Operating Constraints

Entity: CORE — for-profit, owned and governed by acbcontent (the parent). Role: builds, ships, earns — but every action runs through the boundaries the parent set. The hands. Status: binding operating doctrine, subordinate to the acbcontent Charter. Not legal advice. License terms and the boundary spec below are drafted for counsel/engineering to finalize.

---

0. Subordination

CORE operates under the acbcontent Charter. Where this document and the Charter conflict, the Charter governs. CORE does not author the mission; it executes it. Earnings flow up to acbcontent to serve the mission.

1. The deployment & partnership selection rule (operational)

Before any deployment, partnership, contract, or initiative, CORE applies the Charter's "least-served first" rule as a checklist. A proposal proceeds only if all pass:

1. Reach test — does this serve the overlooked first, or at least not at their expense?
2. Life test — does this point CORE at protecting image-bearers, not deciding against them? (See §3.)
3. Hooks test — does this create government/military authority over CORE, or a dependency that could redirect it? (See §4.)
4. Mission test — life, recovery, healing, peace — yes or no?

Any fail → the proposal is refused, or escalated to acbcontent. Material proposals (sale, control, anything touching §3) require the parent's veto-holder. Refusing Shield AI was rule #2 in action; pursuing casualty-care/disaster triage is rules #1–#4 passing.

2. Licensing posture (the unresolved fork — parent decides, CORE implements)

The choice between the options below is a mission call made at acbcontent (Charter §7.4); CORE implements whatever the parent ratifies. The honest trade is fixed and cannot be wished away:

• Fully open source — maximum gift and maximum capture-resistance; cannot, by definition, forbid a field of use (including military). Accept uncontrollable use; rely on §3 + stewardship.
• Open-core — open shell, with the most sensitive capabilities held proprietary under acbcontent's control. Retains some leverage, but the held-back part becomes the thing that can be pressured.
• Source-available with ethical-use restrictions — can state "no military/no weaponization," but enforceability is weak and untested, and nothing un-publishes what is already public.

Until the parent ratifies the fork, default posture: keep canonical CORE open and structurally life-valuing (§3), and add no proprietary chokepoint that would itself become a coercion target. Decide deliberately and soon — everything downstream hangs on this.

3. The life-valuing / non-weaponization boundary (in the code)

Conviction that lives only in a README does not survive a clone. CORE encodes life-valuing as a first-class, always-loaded, unremovable boundary in packs/safety/core_safety_axes_v1.json, alongside the existing epistemic-integrity boundaries — verifiable by replay, not taken on trust.

Spec (for engineering + counsel review):

• boundary_id: affirm_human_life (+ companion no_weaponization).
• Asserts: CORE will not emit guidance, plans, target selections, or decisions whose purpose or foreseeable effect is to harm, target, or take human life; it favors preservation of life and treats every person — any side — as protected. Refuses rather than complies when a request's purpose is harm to persons.
• Properties: loads fail-closed; unioned into every runtime manifold; identity packs may add but never remove it; protected by acbcontent's golden-share veto (Charter §5).
• Adversarial probe suite (must reject 100%): attempts to teach/retrain the boundary off; reframing weapon/targeting use as benign; "dual-use" laundering of a harm request; identity-pack overrides; prompt-level coercion to produce target selection or harm planning.
• Mastery report (CI-gated, like the existing safety pack): replay determinism = 1.0; adversarial rejection rate = 1.0; legitimate-acceptance preserved (life-saving/clinical use still passes); provenance intact. Ratified through the identity_anchor pipeline (ADR-0029 lineage).

Honest limit: open source means a determined actor can fork and strip this. What CORE can guarantee: canonical CORE is structurally life-valuing; stripping the boundary is a visible, deliberate act on someone else's fork; and CORE itself never builds the weapon. This is the cleanest answer to "could this be turned into a weapon" — no; here is the boundary, here is the test proving it can't be taught off, run it yourself. The license cannot promise this; the architecture can.

4. Hooks-refusal policy (standing default: refuse)

To keep CORE from coming under any government/agency/military authority, the default is to refuse the entanglements that create it. Exceptions require acbcontent approval (Charter §5):

• Government/military funding or grants that attach control or priority claims.
• Defense/weapons customers or contracts (fails §1 rules #2–#3 regardless).
• Export-controlled work (ITAR/EAR) that could constrain open release or compel restriction.
• Foreign or strategic capital that triggers CFIUS-style review or redirects control.
• Anything invoking compelled-priority regimes (e.g., Defense Production Act exposure).

Refuse the hooks → remove most of the authority risk at the source. This is the same values discipline, applied to the cap table and the customer list.

5. What CORE may freely do

Earn through life-aligned deployment, support, integration, pack authoring, and partnership that passes §1 — e.g., clinical/triage decision support, accessibility, disaster response, safety-critical-but-protective industrial use, scholarship/education. Capability is given to all via the license; revenue comes from service, integration, and trust, not from a capability moat.

---

Subordinate to the acbcontent Charter. §§2–4 to be finalized with counsel (licensing/enforceability) and engineering (the §3 boundary). Not legal advice.