A pack is a starting point rather than a ceiling. Reading one and publishing it back under your own name, with your own numbers, is the flow this surface is built for.
The frame
The frame fixes what a policy can be made of. Content that steps outside it is not served, and the Platform refuses to start rather than decide under it. A policy is made of three rule forms and reads a closed vocabulary of attributes.
Every rule carries a stable identifier and a text. The identifier is what a support conversation, your own reporting and an eventual regulator quote, so it never names a different rule in a later version. The text belongs to the rule rather than to the screen that renders it, and it is copied into every decision’s trace, which is what lets a refusal explain itself years later.
Identifiers are namespaced to whoever wrote the rule. Everything the Platform publishes carries
capcells:; everything you publish carries your own tenancy identifier. Content lifted from a pack keeps the Platform’s codes and is refused until you take authorship of them, the party that tuned the numbers is the author of what the rules now do.
The vocabulary
A policy reads only attributes in the vocabulary, each with a name, a unit and bounds. An application carrying anything else is refused naming it: a value the Platform will not read is one you believe entered the decision and did not. The vocabulary has two halves.
Attributes come in three kinds.
A derived or read attribute is the Platform’s answer, and an application that states one is refused naming it.
Four attributes are read rather than declared: the
rcc_* come from Círculo de Crédito’s consumer report, under the source you enable. There is no device signal, no e-mail, no postcode and no marketing channel in the Platform’s half. Every other attribute is a fact you declare about a client you already have, one of ours, or one of your own.Your attributes
A fact only you hold: whether the name on a shipment matched the name on the KYC file, a store’s repeat-customer flag, a velocity count, a payroll confirmation, is one you declare and then read like any other. Read the whole vocabulary atGET /v1/tenants/{tenant_id}/attributes; it answers the Platform’s half and yours, each marked.
You declare at the Console, as an administrator acting as a person: PUT /v1/tenants/{tenant_id}/attribute-declarations/{local} with the unit, the bounds, which absences a value may arrive in, how old a value may be, your rationale and the basis on which you hold that reading it is permissible. The attribute is available to your policies at once, spelled {tenant_id}:{local}.
A decision stating your attribute records it exactly as it records the Platform’s: with its name, its state, its value, and the points it earned.
The lexicon
The Platform publishes, atGET /v1/tenants/{tenant_id}/attribute-lexicon, the protected characteristics and sensitive-data categories it refuses a declaration by, sex, race, religion, nationality, disability, health, pregnancy, marital status, sexual orientation, genetic and biometric data, political and union membership, in English and Spanish. A declaration whose local name, rationale or basis contains one of these as a whole word is refused naming the word.
Value states
An attribute value is a state and, only where that state ispresent, a number.
The frame says, per attribute, which of the two absences it admits, and a scorecard entry must band every one it admits. An entry silent about
unavailable does not ignore that case: it would award whatever an unstated band awards, most often exactly when something has broken.
A derived attribute whose inputs permit no number answers not_applicable, never a number standing in for the absence. A ratio over an income of zero is not applicable; it is not zero, and it is not the largest value in the domain.
Content rules
The Platform checks its own content before it serves, and refuses to start rather than decide under a policy with a hole in it.
The last one is worth its own sentence. A knockout that fires on everything refuses every applicant; a knockout that can never fire is a control somebody believes is in force and is not. Both are the same defect, a rule whose truth does not depend on the applicant, and both are visible from the content alone.
Versions
Content is published as versions numbered consecutively from 1, per policy. A published version is immutable, is stored whole rather than as a difference against its predecessor, and stays readable forever: a decision references the version it was decided under, and that reference resolves for the life of the decision. Changed content is the next version. Nothing is edited in place, by you or by us. A number past the next one is refused. A number skipped resolves to nothing for the life of every decision that would name it, and publishing is append-only, so it can never be filled.The digest
Every version carries a digest: a value derived from a canonical rendering of everything that decides under it, the attributes it reads with their bounds and admitted states, every knockout with its bound, every scorecard entry with its bands and points, and every cutoff band with its outcome, rate and ceiling. A version number is a label somebody assigns; a digest is a fact about content, and only the second can be checked. Every decision records both.Adoption
Adoption is the recorded act by which you name, for one configuration, the version the applications naming it are decided under. Nothing is adopted by default or by silence.- A configuration you have adopted nothing for has every application naming it refused, naming that nothing is adopted there.
- The latest adoption for a configuration governs the applications naming it decided after.
- A decision already recorded keeps the version it names, whatever you adopt afterwards.
- An adoption may state
enforce_bar: true. Applications naming that configuration for a client a recorded refusal bars are then refused unrecorded rather than decided. See Moratorium and bar. - The adoptable set is the Platform’s packs together with your own confirmed versions. Adopting anything else, a version past the end, a version of your own that nobody has confirmed, another tenancy’s policy, a configuration you do not have, is refused naming it, and the adoption you already hold for that configuration still governs.
Authoring
You publish policy versions of your own at the Console, inside the frame above and over your whole vocabulary, the Platform’s attributes and your own. Three acts, and the platform stores only the last two.Validate
Post candidate content and read back every finding the publication would refuse on, or that it would publish and the digest it would publish under. Nothing is stored: no draft, no attempt, no partial state. Your working copy is yours.The findings are the whole list rather than the first thing wrong, in the version’s own order.
Publish
The version is written with the person who published it, and is immutable from that moment. Stating the digest validation answered is how you publish exactly what you validated; the Platform checks the claim and refuses a mismatch.Publishing the same content twice under one number is a retry and answers what is already published. Different content under a taken number is refused.
Confirm
A second person records that they stand behind it, which is the whole of what makes the version adoptable. Nothing reviews the content a second time and the Platform could not.On a sandbox Tenancy the publisher may confirm their own version. See one signature on a sandbox.
org:admin role and a person. An agent credential validates and signs nothing, on a sandbox tenancy exactly as on a live one.
A confirmation stands. There is no un-confirming: a tenancy that no longer wants a version governing adopts something else.
One signature on a sandbox
Nothing on a sandbox Tenancy is owed to anybody, so one administrator can put a policy into force there alone.
The mark exists so a sandbox Decision never reads as one a second person stood behind.
A sandbox confirmation reaches no live Tenancy. Versions belong to the Tenancy that published them. The same content published on your live Tenancy waits there for a second person.
These three are served at the Console door and nowhere else. The tenant API serves no route that publishes a policy, and never will: an API key proves a machine and no person, and what a policy does to an application is signed by named people.