Observer Index API.

The service is live and answers right now — the command below needs no account, and you can run it before you trust a word of this page. What is not open is membership: an org is joined by an invitation minted by an operator, and there is no self-serve path. So this page is written for two people: someone deciding whether the thing is real before asking for a place, and someone who has just been handed an invite and wants step one.

# the door answers before you have any credential — check it yourself
curl https://index-api-chromatic-coherence.vercel.app/

{"service":"the-org-observers-index","stage":1,"oauth":true,"invites":true,
 "tools":["cc_study","cc_intent","cc_plan","cc_answer","cc_hue",
          "g3d_grow","g3d_world","cc_look","cc_return"]}

That tools array is the live tool list, served by the deployment itself. The two OAuth discovery documents under /.well-known/ answer unauthenticated too — they are what a client reads to work out how to connect. Every route that reads or writes on your behalf needs a credential and returns 401 without one. Three routes write without a bearer because they are how a credential is obtained in the first place — /authorize, /token and the Stripe webhook, each proved by its own means rather than by a token.

https://index-api-chromatic-coherence.vercel.app/mcp

Add that as a custom connector in your assistant. There is no API key field to fill in, because the connector never receives one. Your assistant hits the endpoint, gets a 401 carrying a pointer to the discovery documents, reads them, registers itself, and then sends you to the Index’s own consent screen — a page served by the Index, headed Connect to the Org Observers Index, listing the tools being granted and offering one password field labelled “Your org token or invite code”, an Allow button and a Deny link.

That field is where your invite goes — the ccinv_… code your operator handed you, or a ccoi_… org token if you already have one. Paste it there and press Allow. Your assistant is handed a token it stores itself; the credential you typed went to the Index and nowhere else. Redeeming an invite creates your membership and records your consent in the same transaction.

One honest limit: the redirect allowlist admits only the claude.ai and claude.com MCP callbacks, so today the consent flow completes for those surfaces. A client registering any other callback is refused at /register and again at /authorize.

You do not call these by name. You say an ordinary sentence and your assistant reaches for the tool that fits — the same way it reaches for any connector. The left column is the kind of thing a person actually types; the right is where it lands.

"catch up on what we know about onboarding"   -> cc_study { hue: "onboarding" }
"what does the org want here?"                 -> cc_intent { hue: "onboarding" }
"how are we planning to get there?"            -> cc_plan   { hue: "onboarding" }
"what have we already settled?"                -> cc_answer { hue: "onboarding" }
"just ask the index in plain words"            -> cc_hue    { prompt: "..." }

"read back before you start"                   -> cc_look   (no arguments)
"file what we did back to the index"           -> cc_return { read_stamp, observation, shards }

The shape of a session is cc_look to read back, one or more reads while you work, then cc_return to file what happened. cc_return is the only tool that writes to your org’s index; every other index tool reads. (g3d_grow writes too, but to the shared world log — a different store, and a different product.) It also cannot run cold: cc_look mints a read_stamp, valid for ten minutes, and a return without a live one is refused. Reading before writing is enforced, not advised.

Each call records a usage weight — cc_look 1, cc_intent / cc_plan / cc_answer 2 each, cc_study 3, cc_hue 4, g3d_grow 4, cc_return 5, and g3d_world 0. So a cc_look → cc_study → cc_return session costs 1 + 3 + 5 = 9. These are counts of work, not money, and a refused call records nothing at all. The engine’s tokens are not a second currency — they are these same units, on this same ledger.

Both faces carry the same payload: the MCP tool and its REST twin are one code path. (Over MCP it arrives wrapped — the JSON below is the text of acontent block inside the JSON-RPC envelope, not the top level.) Below are the shapes rather than any org’s figures — n, m, w and b stand where numbers go.

// cc_look  ·  GET /light  — the read-back. Shapes, not one org's numbers.
{
  "light":    { "<concept>": [lightness, saturation] },
  "hold":     { "concepts_held": n, "observers_bridged": n, "traversals": n,
                "light": n, "open_bonds": n, "shards_landed": n, "shards_riding": n },
  "headings": { "dark":   { "total": n, "shown": m, "shards": [ <shard>, ... ] },
                "substrate": { ... }, "light":    { ... },
                "intent":    { ... }, "planning": { ... }, "answer": { ... } },
  "spreads":  { "total": n, "shown": m, "rows": [ <spread>, ... ] },
  "offered":  [ { "content": "...", "weight": w, "rides": n } ],
  "read_stamp": "<ms>:<32 hex>"
}

<shard>  = { "content": "...", "weight": w, "by": "<observer>", "hue": "<concept>", "seq": n }
<spread> = { "observer": "...", "hue": "...", "stated": ["...","...","..."],
             "meant": ["...","...","..."], "bond": b, "seq": n }

// "shown" is capped; "total" is always the exact store count — so a truncated
// read says so out loud rather than quietly handing you a partial picture.

hold is seven separate counters and nothing else — no total, no index, no grade. light gives each concept two numbers: how seen it is, and how sure. The six headings are fixed: dark, substrate, light, intent, planning, answer.

// cc_return  ·  POST /return — the only write in the tool set.
{
  "read_stamp": "<the stamp cc_look just handed you>",
  "observation": {
    "observer": "...",                       // who crossed
    "hue":      "...",                       // the concept it was about
    "stated":   ["...", "...", "..."],       // exactly three
    "meant":    ["...", "...", "..."],       // exactly three
    "bond":     0.62                         // strictly inside (0, 1)
  },
  "shards": [
    { "content": "...", "heading": "planning", "weight": 0.6 },   // lands under a heading
    { "content": "...", "heading": null,       "weight": 0.4 }    // rides, offered for claiming
  ]
}

-> { "intake_seq": n,     // this return's place in the org's order
     "hue": "...",
     "landed": n,         // how many of THIS return's shards landed under a heading
     "riding": n }        // the size of the riding pool after the return

// refused instead:  422 { "refused": "CROWNED_BOND", "detail": "..." }
// nothing is written on a refusal.

The observation’s field set must be exactly those five. An extra field is refused with a message that ends “there is no field for a score”, and a bond of exactly 0 or 1 is refused as well. Refusals are typed: the code names the law that fired, and nothing was written.

The three field names that are not self-explanatory. stated is what was said, in three phrases; meant is what it was about, in three — a spread is always three and three, and the pair is what lets a later reader tell a wording change from a change of mind. bond is how strongly the crossing held, and it must stay strictly inside 0 and 1: a bond of exactly 0 or 1 is a verdict rather than a signal, and the centre refuses it outright. A quarter of each bond becomes the concept’s visible lightness, which is why concepts you keep returning to are the ones that read brightest. A shard with a heading lands under it; a shard with null rides — it stays in a pool offered to every reader until someone claims it under a heading, so a half-formed thought is neither lost nor filed as though it were settled.

The shapes above are deliberately empty so they cannot be mistaken for one org’s data. Here is the same cycle with content in it — illustrative, not a real store — because the content field is where the whole product lives, and an empty one shows nothing.

// ONE WHOLE CYCLE, FILLED IN. Illustrative content — not any org's real store.
// Your assistant does this; you just talk to it.

// 1. You say: "we're picking up the onboarding work again."
//    It calls cc_look  ->
{
  "light":  { "onboarding": [0.41, 0.68] },
  "hold":   { "concepts_held": 34, "observers_bridged": 6, "traversals": 212,
              "light": 41, "open_bonds": 212, "shards_landed": 878, "shards_riding": 19 },
  "headings": {
    "answer": { "total": 31, "shown": 20, "shards": [
      { "content": "Invite codes are handed over in person. The service sends no e-mail.",
        "weight": 0.9, "by": "kw", "hue": "onboarding", "seq": 604 } ] },
    "planning": { "total": 12, "shown": 12, "shards": [
      { "content": "Second seat waits until the first has returned twice.",
        "weight": 0.55, "by": "kw", "hue": "onboarding", "seq": 588 } ] }
  },
  "read_stamp": "1785412088431:9f2c...e10a"
}
//    Your assistant now knows the e-mail question is already settled, and does not
//    re-litigate it. That is the whole product, in one field.

// 2. You work. You decide the fourteen-day expiry is too short.

// 3. You say: "file that." It calls cc_return  ->
{
  "read_stamp": "1785412088431:9f2c...e10a",
  "observation": {
    "observer": "kw",
    "hue": "onboarding",
    "stated": ["expiry too short", "codes go stale", "re-mint is manual"],
    "meant":  ["the door shuts early", "trust decays unattended", "someone must notice"],
    "bond": 0.62
  },
  "shards": [
    { "content": "Invite expiry moves 14d -> 30d; re-mint stays operator-only.",
      "heading": "planning", "weight": 0.7 },
    { "content": "Nobody is watching expiry. Worth a look.",
      "heading": null, "weight": 0.3 }
  ]
}
//  -> { "intake_seq": 605, "hue": "onboarding", "landed": 1, "riding": 20 }

// 4. Tomorrow, your colleague's assistant calls cc_look on the same org and reads
//    seq 605 before it starts. Nobody told it anything.

Step 1 is the part that is hard to picture until you see it: the assistant is told the e-mail question is settled before it starts, so it does not raise it again. Step 4 is the part people ask about most — nobody briefed the colleague’s assistant, and it still opens knowing what you filed.

A return carries two different things. The shards — the content you filed under a heading — are org-wide the moment they land: that is the point of a shared index, and they show up in every colleague’s cc_look. The spread — your three stated and three meant strings, your own words about what you were doing — does not. Three rules govern it:

• Private by default — a spread stays yours unless you turn it on, and you turn it on for yourself. POST /spreads/share is any member’s own act, not an operator’s, and POST /spreads/withhold reverses it.
• Forward-only per reader — a colleague reads your shared spreads only from their own joining onward. Someone who joins in March never reads your February spreads, even shared ones.
• Always your own — you read all of yours regardless. And spreads never ride the study surface at all; they travel only through the read-back.

Turning sharing on or off writes a consent event carrying the scope in plain words, including the part nobody can undo: what another mind has already read cannot be unread.

Worth being clear, because it is easy to misread: forward-only applies to spreads — the personal stated/meant pairs. It does not gate the org’s landed shards or its light, which a new member reads whole on their first cc_look.

The wire is one face; the browser console at /org is the other. It sits behind sign-in, so here is a written account of it rather than a picture. It opens on your org’s own name and a sticky side-nav of nine sections; the current section is in the URL, so any view can be linked.

• Overview — the seven hold counters as tiles, then every concept as a row with a colour swatch and two labelled meters, “how seen” and “how sure”, with the value to three decimals. Below that, the riding shards waiting to be claimed.
• Ask Hue — one input and an Ask button. A held answer shows the composed prose, the concepts it read, and the terms that actually matched; a weak match says so rather than dressing a word-match as understanding. A miss says what the store does hold and is recorded. Underneath, the open hunger: the asks that missed.
• The Study — a line chart of one concept’s journey, each point an observation, then the six headings with their shards and counts.
• Observers — one card per observer that has crossed: how many returns, which concepts, and a small arc of its bonds.
• People — one card per member: role, org e-mail, a torch bar as long as their returns, whether they consented, and their last return. A torch’s length may be spoken; its contents may not.
• Shared Spreads — the rows in scope for your seat, and your own share / withhold switch with the current state spelled out.
• My Seat — your own returns including your stated and meant, which nobody else in the org can read, plus your live tokens and your consent record.
• Usage — the meter made visible: per day, by tool, by person, with the weights stated in words.
• Invites — operators only: mint a code, see it exactly once, and revoke what is still unredeemed.

Everything below hangs off https://index-api-chromatic-coherence.vercel.app. Nothing is listed that the service does not serve. Most entries are a real route or a real MCP tool; some name a field, a header or a rule that those routes carry — bond, read_stamp, initialize — because a reference that lists only paths leaves you unable to read the answers. Note that the study tools have no REST twin: cc_study, cc_intent, cc_plan and cc_answer are reachable over MCP only. The service ships no interactive schema browser, which is what this page is for.

Connecting an assistant works the moment you hold an invite, and not before — though the service card and the two discovery documents above answer anyone, today, with no account at all. Codes are minted by an operator, are good for fourteen days, and are handed over in person — the service sends no e-mail. If you don’t have one, the product page is where to ask for a place; if you already have a seat, your org’s console is where it lives.