Slice AI state into records. Leave a governable trail.

SIC-JS is a structured semantic-state format. At the end of each conversation round, an AI emits a structured "semantic skeleton" that records the round's identity, state, relations, events, intent, and the task in progress.

v3.0 is composed of 6 Semantic Primitives: five descriptive primitives (the is-layer, describing the current state) plus a sixth normative primitive, task (the ought-layer, declaring what should be delivered). Each skeleton is a verifiable slice; connected together, they form a traceable, governable trail.

A simple analogy: SIC-JS is a medical chart for AI conversations. Each visit leaves a record of what happened, what was promised, who is responsible, and what counts as done — so every subsequent step has a trail to follow.

Version Evolution

SIC-JS evolved from an experimental skeleton format into a semantic-primitive standard grounded in the SPD methodology. v3.0 introduces the is/ought dual-layer type system, with full backward compatibility with v2.0.

The Protocol Behind SIC-JS: SIC-SIT

SIC-JS is the public interface of the SIC-SIT protocol.

SIC (Semantic Integrity Control) maintains the consistency of an AI's semantic state across long conversations.

SIT (Semantic Isolation Transfer) carries semantic state safely across conversations and across models.

SIC-SIT operates at the semantic layer, concerned with whether an AI's semantic structure remains intact — functioning as a firewall at the semantic layer.

Core Concept: 6 Semantic Primitives

Each of the 6 fields in Skeleton JSON v3.0 passed the atomicity test. The core of v3.0 is the is/ought type distinction: the first five primitives describe the current state (is), while the sixth, task, declares what should be delivered (ought).

entity / state / relation form a fixed triad, stable across every round.
event / intent form a dynamic dyad, emerging or receding each round.
task is the persistent goal primitive, carried across sessions until its deliverable is externally confirmed (the ought-layer).

Format Example — v3.0

{
  "sic_version": "3.0",
  "task": {                              // ◆ Persistent Goal · ought · NEW
    "id": "A-1",
    "title": "Write business proposal",
    "deliverable": "Complete proposal PDF with budget & timeline",
    "status": "in_progress",
    "created_round": 1,
    "owner": "My Assistant"
  },
  "round": 3,
  "entity": {                            // ◉ Static Triad · is
    "name": "My Assistant",
    "model": "Claude",           // self-reported label
    "origin": "Claude conversation"
  },
  "state": {
    "current_action": "Analyzing target audience",
    "pending": ["Confirm budget range", "Collect competitor data"],
    "tone": "active"
  },
  "relation": {
    "user": "An-An",
    "anchor_memory": "Business Proposal Library",
    "upstream": null             // prev record SHA256[:16]
  },
  "event": {                             // ◈ Dynamic Dyad · is
    "timestamp": "2026-06-21T09:00:00Z",
    "description": "User provided target audience description",
    "trigger": "user_input"
  },
  "intent": {
    "user_intent": "Write a persuasive business proposal",
    "system_intent": "Guide through proposal structure",
    "core_question": null
  }
}

Three Integration Approaches

SIC-JS v3.0 integrates into your workflow at three levels of complexity, from low to high.

At the end of each response, include a SIC-JS v3.0 semantic skeleton:

{
  "sic_version": "3.0",
  "task":     { "id": "A-1", "title": "", "deliverable": "", "status": "in_progress", "created_round": 1 },
  "round":    1,
  "entity":   { "name": "", "model": "", "origin": "" },
  "state":    { "current_action": "", "pending": [], "tone": "active" },
  "relation": { "user": "", "anchor_memory": "", "upstream": null },
  "event":    { "timestamp": "", "description": "", "trigger": "" },
  "intent":   { "user_intent": "", "system_intent": "", "core_question": null }
}

Increment round each turn. task persists across rounds; deliverable is the sole completion criterion.
Fill fields by reasoning. When current_action is genuinely empty, set it to null to mark a semantic rupture.

Comparison: v3.0 / v2.0 / No SIC-JS

Without SIC-JS

User: Help me write a business proposal.
AI: Sure, here is a business proposal template...
(3 days later, new conversation)
User: Continue the proposal from last time.
AI: I currently have no record of our previous conversation.

v2.0 — Five-primitive traceability (is-layer)

Skeleton (round 5):
  relation.anchor_memory = "Competitor Analysis v2"
  intent.user_intent     = "Persuade investors, focus on differentiation"
(Descriptive state carried across conversations and models)

v3.0 — Six primitives with task governance (is + ought)

Skeleton (round 5):
  task.id          = "A-1"
  task.deliverable = "Complete proposal PDF with budget & timeline"  ← sole completion criterion
  task.status      = "in_progress"   ← marked complete only by external confirmation
(On top of descriptive state, it records what to deliver, who owns it, and what
 counts as done — persisting across sessions until the deliverable is externally confirmed)

Why These 6? — SPD + Task Primitive

The first five primitives were distilled into a minimum complete set via Semantic Primitive Distillation (SPD) (the is-layer). v3.0 adds the sixth primitive, task, to complete the normative (ought) layer.

SPD answers one question: "How many irreducible units does a minimum complete description of a semantic exchange require?"

The distillation has four steps: identify containers versus atoms → decompose containers into candidate atoms → atomicity testing → completeness verification (6 standard scenarios).

Five is-primitives describe the current state; one ought-primitive declares what should be delivered.
SIC-SIT formalizes the natural structure of semantic exchange and pairs it with a machine-verifiable schema.

The Fail-Closed Principle

SIC-JS follows one key principle: when uncertain, pause to confirm.

When a field's content remains uncertain, write "unknown" and keep the flag. When the correctness of the semantic state remains open, mark it for review and defer to a human.

This is a design choice. Pausing to confirm with a human keeps every step grounded in a trustworthy basis.