ΣigmaClava

Governance

Nothing ungoverned.

Intelligence in our work is always named, bounded, and answerable to a human. This page states what that means, what it rules out, and how it is enforced here.

The standard

This is a house standard, not a policy position on the field. It governs the systems SigmaClava builds and runs, and it is written to be checkable rather than reassuring.

The three requirements are conjunctive. A system that satisfies two of them is not partly governed; it is ungoverned, and each pair fails in its own specific way.

The three requirements of governed intelligence Three overlapping regions labelled Named, Bounded and Answerable. Only where all three overlap is the system governed. Each pair that lacks the third is labelled with its failure: a system that is bounded and answerable but not named cannot be reasoned about; named and answerable but not bounded cannot be trusted; named and bounded but not answerable has no one to ask. Named IT HAS AN IDENTITY AND A SCOPE Bounded ITS LIMITS ARE STATED Answerable A NAMED PERSON IS ACCOUNTABLE CANNOT BE SWITCHED OFF ON PURPOSE CANNOT BE REASONED ABOUT CANNOT BE TRUSTED Governed ALL THREE, OR NONE
Figure 1 Only the intersection counts. Each pair that lacks the third requirement is named with the failure it produces — which is how we decide what to fix rather than what to argue about.

The three requirements

  1. I

    Named

    It has an identity and a stated scope.

    A system that has not been named cannot be reasoned about. It has no edges, so every conversation about it is a conversation about something slightly different, and no one can say whether a given behaviour was in scope.

    Naming is cheap and it is the precondition for everything else. A named system has a stated purpose, a stated scope, and a boundary at which it stops. A product may contain several named systems; a brand is not a name in this sense.

  2. II

    Bounded

    Its limits are stated, inspectable, and settable.

    A bound is not a preference and not a filter applied after the fact. It is an object in the system: a person can point at it, read it in plain language, change it, and be confident about what happens at the edge.

    The test we hold ourselves to is that someone who lives with a system can state what it will not do, without reading documentation, and be right. Where they cannot, the defect is in the system.

  3. III

    Answerable

    A named person is accountable for what it does.

    Answerability is a property of an organisation, not of software. It means there is a specific person — not a team, not a committee, not a policy — who is accountable for a system’s behaviour and who has the authority to change or stop it.

    A system answerable to everyone is answerable to no one. Where we cannot name the person, we treat the system as ungoverned regardless of how carefully it was built.

A closed, surveyed boundary with tick marks around its edge. Inside, points sit on a regular grid; outside, they scatter without order.
Plate I The edge is drawn, and it has ticks you can count. Inside it the field is ordered and answerable; outside it is not that the work is worse, but that no one can say what it will do.

What this rules out

A standard that never costs anything is decoration. These are the things it has actually ruled out for us, stated plainly so that a prospective collaborator can find out cheaply whether we are a fit.

  • We do not build systems that optimise for attention

    Engagement as an objective produces designs that are adversarial to the person using them. This is not a close call and we do not take the work.

  • We do not build systems that require a diagnosis to behave well

    If a behaviour is better, it is the default. Charging a person a disclosure to receive it is a design failure we are not willing to ship.

  • We do not deploy a system into a household that the household cannot switch off

    The ability to end the arrangement, completely and without penalty, is a precondition rather than a feature.

  • We do not present a persona as a relationship

    A system may have a manner. It may not imply reciprocity it does not have, or a memory of the person that it is not actually keeping.

  • We do not let a commission set a finding

    Commercial work is delivered through OccultOpes and stays out of the research record. A client can commission a system; a client cannot commission a result.

How it is enforced here

The same standard applies to the house’s own infrastructure, including the systems clients touch. These are properties of what is running, not intentions.

Named roles, not ambient access
Every capability in the client portal is a named permission held by a named role. There is no implicit access, and the one wildcard role is seeded onto a single administrator and cannot be granted through the API.
An audit trail that is not optional
State-changing actions in the portal are recorded with the actor, the action, and the time. The record is readable by the house, and it is written whether or not anyone is looking.
Secrets are stored as digests, never as secrets
Passwords are scrypt-hashed with a per-user salt; session tokens are held only as SHA-256 digests. A copy of the database does not yield a way in.
Correspondence survives delivery failure
Inquiries persist to the database before any delivery is attempted, so an outage in a mail provider cannot silently lose something a person wrote to us.
Ending a session ends it everywhere
A password change or reset terminates every existing session for that account. Revocation that leaves live sessions behind is not revocation.

Security reports are welcome and are handled under the policy published at /.well-known/security.txt.

Related

How the work is actually run → Governed intelligence, defined → The five principles →