Gravity Standard

06 · Development Permits

Say it. Do it. Prove it.

A permit is an x509 certificate that says, in effect, "this application may run this stage in this environment until this date." The pipeline verifies it and proceeds with no one pressing an approval button. The governance behind the certificate is where the control lives.

Three permits in sequence. The build permit needs identity and intent. The test permit, say it, needs a defined threat model. Between test and production, do it: the stated controls are implemented and exercised. The production permit, prove it, needs evidence that each top threat is prevented. BUILD PERMIT Begin identity and intentthreat model begun TEST PERMIT Say it threat model defined,owned and current Do it controls built PRODUCTION Prove it evidence for eachtop threat BUILDTEST ENVIRONMENTSEXERCISED IN TESTPRODUCTION You can start with no threat model. You can't get a test permit without one, or a production permit without proof.

How a permit is used

The certificate replaces the approval email.

A governance body outside the application teams issues permits. The team presents its permit to the pipeline, which checks it and moves forward. Where a pipeline once waited on several approval emails, a valid permit stands it up on its own.

An expired, mismatched or invalid permit fails closed.

The pipeline runs eight checks on a permit. A test permit deploying to the test environment passes all eight and deploys with no human approval. The same permit used to deploy to production fails the environment check, and the pipeline stops. X509 PERMIT app: lendingstage: testenv: testversion: ^1.4expires: 2027-04-30 DEPLOY TO TEST PRODUCTION 1 · CHAIN AND VALIDITY 2 · NOT A CA, SIGNING KEY 3 · APPLICATION ID 4 · STAGE 5 · ENVIRONMENT 6 · VERSION CONSTRAINT 7 · REQUIRED CONTROLS 8 · KEY POSSESSION, DENY LIST DEPLOYno human approval step permit covers test only FAIL CLOSEDnothing deploys set-membership checks on OIDs, so the validator stays small

The stages

What each permit asks of the team.

PermitPrincipleAuthorizesRequires
BuildBeginBuilding the applicationA registered application ID, named owners, a repository, the stated purpose and data classes, the expected controls, infrastructure as code, and a decision log
TestSay itTest pipelines and test environmentsA defined, owned threat model, and the standards in place
ProductionProve itDeploying to and running in productionFor each top threat, an automated test or recorded exercise showing the control working, with a date and result. Runbooks rehearsed, dashboards live, alarms tested

Proving prevention

The standard demonstrations.

Each top threat links to evidence. These are the ones every application should expect to show where they apply.

ThreatEvidence
One tenant reads another's dataA cross-tenant query returns zero rows
A handler skips its authorization checkAVP denies the action, and RLS still returns nothing if the check is removed
Injection through user inputHostile input is stored or rejected as data, through generated, parameterized queries
A stolen database snapshotPersonal data is ciphertext without the KMS key, and a context mismatch is denied
Bulk data extractionExhausting the KMS token bucket raises the alarm
Deploying with a bad permitA pipeline run fails closed on an expired or mismatched permit

Trust and validity

The expiry date is the control.

Your organization is the root

Permits come from a CA the adopting organization owns, dedicated to permits and separate from any CA issuing TLS or workforce certificates. Pipelines trust only that CA.

Long-lived, then reviewed

A permit spans real development and testing cycles. Its end brings governance back to look at what changed. Something valid six months ago isn't automatically approved today.

No revocation infrastructure

The validity period replaces CRLs and OCSP. The pipeline proves possession of the permit's private key, and an optional deny list covers a key known to be compromised.