ConcertedEngineeringRead the article

Proposed minimum
standard.

Download the complete standard (Markdown) · Integration and agent controls

Model 0.3.1-draft.1 · bundle SHA-256 003b50c9d7f852a15f84d91f517430045203cff3402f790089b304f15e506947

Operational metric definitions · One record, three document views

CE-CTRL-01 Status: experimental proposal · Updated October 20, 2026 · OpenKedge

CE-CTRL-01 This is a proposed governance and traceability layer for Agile, DevOps, continuous delivery, and specification-driven development. It does not establish comparative effectiveness, certification, security, or legal compliance. Existing delivery practices remain useful. An implementation must provide actual enforcement and verification; storing these fields in YAML is insufficient.

Normative meaning

CE-CTRL-01 MUST and MUST NOT identify hard requirements for claiming alignment with this proposed profile. SHOULD identifies a recommendation whose omission needs a recorded rationale. Pilot benefit, lower cost, and faster delivery are hypotheses, not conformance requirements. This is an early design profile, not a ratified industry standard or an interoperable executable schema.

Canonical source and derived publications

CE-CTRL-01 The canonical model bundle is authored in the OpenKedge repository, with model version 0.3.1-draft.1 and contract schema 0.2. Its manifest binds this profile, the pilot protocol, implementation guide, metric dictionary, experimental reference files/archive and illustrative records by content digest. The essay explains the bundle; the companion site publishes derived views of a pinned snapshot. English definitions are normative for this proposal; translations are explanatory views.

CE-CTRL-01 model_version identifies the editorial bundle; schema_version identifies record semantics. The two are distinct. The manifest includes SHA-256 digests of document bytes and of each example record's canonical JSON payload; the digest and signature fields are excluded when calculating a record's own digest. A content hash detects drift, not authenticity or correctness. The publication scripts generate the public manifest and companion snapshot; both builds check their local hashes. Before release, run the cross-repository synchronization check. A local snapshot check cannot establish that an upstream draft is the latest.

Records and required fields

CE-CTRL-01 The compatibility download filename retains v0.1; the current content is spec 0.3.1-draft.1 with record semantics 0.2. Consumers MUST explicitly approve this migration and preserve older definition versions.

CE-CTRL-01 Every record MUST have schema_version, kind, id, immutable revision and digest, an accountable owner, status, and created_at in UTC. A reference MUST contain a record ID, exact revision, and content digest; a branch name or latest is insufficient. Hashing and canonical serialization MUST be declared by the implementation profile. Owners MUST resolve to authenticated principals or groups with a documented escalation owner.

Record / Required semantics in schema 0.2
RecordRequired semantics in schema 0.2
CE-CTRL-01 IntentContractInitiative ID; product/technical owners; evidence/access rules; problem and observable behavior; non-goals; value hypothesis/horizon; acceptance; classified invariants; safety/privacy/residency/compatibility constraints; metric definition versions and sources; assumptions; linked decisions and supersession.
CE-CTRL-01 ExecutionContractIntent reference; agent/human identities; delegation; repositories/branches/paths/APIs/tools; egress; data and credential scopes; allowed/denied mutations; compute/token/time/financial budgets; isolation; dependencies; protected enforcement/logging; recovery, stop/escalation and expiry.
CE-CTRL-01 EvidenceContractApplicable contract/claim references; protected exact-manifest binding; versioned checks, environment and data/generator; expected result/tolerance; assurance classes; owner/signer; reproducibility, freshness, flake/retry policy, blind spots, exception rules and production signals. It specifies requirements, not observed results.
CE-CTRL-01 EvidenceBundleExact contract and claim references; source/build/artifact/harness/input/environment; observed per-check result versus expectation/tolerance; assurance and authenticated identity; retry/limitations/exception references; reproducibility; issuance/expiry and signed attestations.
CE-CTRL-01 AdmissionRecordExact artifact, bundle, policy, target and authority; decision/time/expiry; exception references; rollout and recovery; actual deployment ID.
CE-CTRL-01 DecisionRecordContext, decision, alternatives/tradeoffs, rationale, decision/approval owners, reversibility, affected contracts/systems, review date and explicit supersession. Status is proposed/accepted/superseded/retired.
CE-CTRL-01 ExceptionRecordRequester, independent approver, exact control and artifact/environment, reason, finite expiry, compensating controls, monitoring/audit, revocation, retrospective and remediation owner.

CE-CTRL-01 Each invariant MUST declare severity (advisory, release-blocking or existential), oracle, owner, frequency, applicability, scoped confidence and failure consequence. Existential or explicitly non-waivable safety requirements MUST NOT be waived. Hard release conditions MUST remain distinct from aspirational outcomes. Unknown observation results remain inconclusive.

Proportionate change profiles

CE-CTRL-01 Risk and reversibility determine the profile, never line count alone. The named Engineering owner proposes the tier; human owners confirm T2/T3; T0/T1 use named delegated engineers within independently approved eligibility rules. A one-line authorization or data-loss change may require the highest tier. Teams MUST record profile, owner, outcome horizon, and contract-work budget before execution.

Tier / Eligibility / required records / Effort and approval
TierEligibility / required recordsEffort and approval
[E0] CE-PILOT-01 T0 — Routine low impactReversible, no runtime/security/data/API/dependency behavior change; never classify by diff size alone. Intent: Parent accepted intent/ticket plus exact references. Execution: Inherited approved repository policy. Evidence: Protected standard checks and current bindings. ADR: Only if a significant decision changes.E0 default: no additional bespoke form; actual effort is measured, never assumed zero. Human-confirmed eligibility under an approved routine policy
[E0] CE-PILOT-01 T1 — Bounded reversibleSingle service, recoverable in one deploy, no material data/API/auth boundary change. Intent: Problem, behavior/invariants, outcome window, risk/tier and owner; inherit exact references. Execution: Accepted service profile plus narrow scope delta. Evidence: Default checks plus independent targeted oracle. ADR: Only if a significant decision changes.E0 default: 15 minutes active authoring; two weekly overruns trigger simplification review. Named engineer within preapproved delegation; no standing meeting
[E0] CE-PILOT-01 T2 — Material coordinated changeCustomer-visible behavior, multiple services, schema/API effects, or changed important assumptions. Intent: Full record plus customer announcement and FAQ. Execution: Explicit permissions, limits, rollback and owner. Evidence: Independent owner-approved oracles, diverse methods and rollout stops. ADR: For new or changed significant decisions.E0 default: 2 hours authoring, excluding assurance work; re-register locally. Human tier confirmation and affected owners
[E0] CE-PILOT-01 T3 — High consequenceIrreversible migration/deletion, removed public API, security boundary or hard-to-recover effect. Intent: Full record, customer announcement/FAQ and narrative risk memo. Execution: T2 plus demonstrated recovery or explicit irreversible-effect constraints. Evidence: Independent cross-team expert review, sandbox fault exercise and approved risk controls. ADR: Principal-reviewed decision record for the significant decision.Assurance-driven; no time target overrides a required check. Human tier confirmation, Principal Engineer and independent risk/admission owners

CE-CTRL-01 These are risk profiles, not exemptions from hard admission invariants. An inherited profile MUST resolve to an accepted immutable revision and digest. A changed inherited control invalidates affected evidence. Record every override explicitly; unknown or conflicting overrides block admission. Existing records may be shared by many changes. Each accepted change still needs exact governing references, build/evidence receipts and an admission record.

CE-CTRL-01 For a one-line expiry comparison fix, the minimum Intent delta states the reproduction, elapsed_seconds >= ttl_seconds, the approved TTL, unchanged token-format/key/permission invariants, and the monitoring criterion. The Execution delta permits only the expiry module and regression tests, denies production credentials and protected-policy edits, and inherits approved sandbox/budget/recovery settings. The Evidence delta requires the independently owned oracle at ages 0, TTL−1, TTL, and TTL+1, existing security checks, and the approved artifact-bound admission profile. Placeholders in examples MUST be replaced by real accepted references before production; the demonstration is not a conforming release bundle.

Authorship, maintenance, and artifact cost

CE-CTRL-01 Product and Engineering author and maintain Intent semantics; Engineering and Platform maintain Execution scope and inherited control profiles; independent Verification owns Evidence requirements and protected oracles; Operations owns admission/recovery. The same people may contribute across records only while required authority separation is preserved. Human owners approve agent-proposed edits. Views are regenerated from accepted records rather than maintained as separate authoritative documents.

CE-CTRL-01 MUST record active authoring, review, reconciliation, amendment, and view-maintenance person-minutes by record revision, change ID, owner, and tier. Report initial vs upkeep hours and failed attempts. Contract upkeep is a subset of coordination time and total labor, not an extra cost added twice. Each pilot sets its own time budget and stop threshold from observed baseline work; this proposal claims no universal authoring-time estimate. The metric dictionary defines hours, cost share and total cost per verified outcome.

Contracts, code, and enforcement

CE-CTRL-01 Contracts SHOULD live alongside the service when access and ownership permit. A commit can include code plus contract deltas; a separate append-only state store is also valid. In either layout, a protected release manifest MUST pin the full source commit and all governing record IDs, revisions, and digests. A store-backed design MUST capture one consistent snapshot/transaction identifier. Candidate records may reference content digests before commit; the builder's later receipt binds them to the final commit, avoiding self-referential commit hashes.

CE-CTRL-01 An implemented admission gate MUST resolve the manifest, validate schema/owner/policy approvals, recompute record digests, compare evidence bindings and freshness, verify build provenance, and deny release on mismatch. Operations MUST verify the deployed artifact digest against the admitted digest. The companion's publication checks validate document snapshots only; no production enforcement engine is supplied or claimed by this website.

Versioning and compatibility

CE-CTRL-01 Records MUST be immutable after acceptance; changes create a new revision and preserve the old one. The profile uses major.minor schema versions: a major change alters required semantics or removes fields; a minor change adds optional fields without weakening invariants. Each 0.x minor version MAY break compatibility and MUST be explicitly approved by consumers. Admission MUST reject unsupported versions and unknown required semantics. Optional extensions MUST be namespaced and MUST NOT override required fields. Conversion between profiles MUST be recorded, reviewed, and revalidated; compatible parsing alone does not make old evidence applicable.

Hard admission invariants

Freshness and change propagation

CE-CTRL-01 The EvidenceContract MUST specify a finite maximum age per check and a monitoring/recheck cadence for long-running deployments. Admission MUST reject evidence after the earlier of its signed expiry and the policy's maximum age. Dependency advisories, revoked identities, and changed production assumptions MUST trigger reassessment even before expiry.

CE-CTRL-01 Changes to intent, source, dependencies, build inputs, execution scope, verification policy, harness, test data, target configuration, or trusted identities MUST invalidate affected evidence. The default is to invalidate the whole bundle. Selective reuse requires an independently approved dependency map showing why a result is unaffected; record the mapping and decision. Cosmetic changes may be classified as nonmaterial only by a protected canonicalization rule. Deployed workloads MUST have an owner who can pause, reverify, or roll back when evidence becomes invalid.

Independence and correlated failures

CE-CTRL-01 Separate permissions provide separation of duties; they do not establish statistical independence. The threat model MUST record shared model families, prompts, context, assumptions, data, infrastructure, and administrative dependencies. It MUST name mitigations or record residual risk accepted by an independent risk owner before admission.

CE-CTRL-01 Required assurance MUST include an acceptance oracle or invariant reviewed by a human owner independent of generation, independently owned acceptance tests, and adversarial/negative tests proportionate to risk, plus production observability and recovery. At least one required verification method MUST be independent of the generating model's judgments: for example a human-authored regression oracle with property/mutation testing or risk-appropriate statistical certification. A different model/vendor MAY supplement these controls; it MUST NOT be the only claimed source of verification diversity. Teams SHOULD combine requirements review, property-based or metamorphic tests, fuzzing, fault injection, static analysis, and formal methods where suitable. Model diversity alone is insufficient. The generator MUST NOT be able to weaken the tests or the policy that judges its output. Verification-policy changes require approval by a named independent policy owner and a separate risk owner, with a versioned audit record; existing evidence MUST be reassessed.

Conflicts, waivers, and emergencies

CE-CTRL-01 Product owns customer intent, Engineering owns permitted implementation, Verification owns required evidence, and Operations owns production admission and recovery. Cross-contract conflicts MUST block normal admission until the affected owners agree on a revision. Verification MUST record the blocking requirement and failed/missing evidence. If the Intent owner disputes it, the named escalation owner convenes Product, Engineering, Verification and Operations; a policy or intent change requires the affected owners and independent policy/risk approvals. The release remains blocked until fresh evidence satisfies the accepted revision or an explicitly permitted, independently approved waiver is recorded. A named escalation owner resolves priority disputes but MUST NOT silently waive another owner's hard constraint. Applicable legal and safety requirements remain binding.

CE-CTRL-01 A waiver MUST identify its requester, exact rule and artifact/environment scope, rationale, residual risk, compensating controls, independent approver, expiry, and follow-up owner. Self-approval and changes to historical records MUST NOT be waived. Waivers MUST NOT grant standing permission to alter verification policy. Expired waivers MUST block further promotion. Hard legal or safety constraints identified as non-waivable in the IntentContract MUST NOT be overridden.

CE-CTRL-01 [E0] An emergency path MUST be configured before an incident. It MUST use authenticated break-glass authority outside the generator, restricted deployment scope, a rollback plan, and append-only recording before action. Any unavailable check MUST appear as an explicit emergency exception, never as a passing result. The incident owner MUST schedule independent review within 48 hours, revoke temporary access, and complete missing checks before further normal promotion. Record a missed review deadline as an unresolved exception and block expansion.

Agent state, delegation, and untrusted content

CE-CTRL-01 When agents are used, the implementation MUST treat retrieved documents, tickets, tool replies, logs and agent memory as data rather than authority. Only authenticated approved records may change permissions or verification policy. Untrusted text MUST NOT supply admission policy, signing keys or release credentials. Protected parsers MUST reject unsupported fields/semantics; prompt instructions alone are not an authorization boundary.

CE-CTRL-01 Execution profiles MUST define memory provenance, accepted record versions, expiry, checkpoints and resume/revalidation rules. Agents MUST reload current permissions on resume and before consequential effects; remembered grants do not survive expiry or material invalidation. Child agents MUST have explicit narrower delegations and an aggregate parent resource budget. The parent cannot amplify authority by spawning contributors or approve their releases.

CE-CTRL-01 Concurrent effects MUST have explicit ownership and target-state preconditions, using compare-and-swap, leases or equivalent implemented controls where races matter. Long-running plans MUST stop at expired grants, budgets or changed assumptions until current policy/owners authorize renewal. Agent-authored evidence remains an untrusted claim until independently controlled verification produces an authenticated receipt for the exact run, harness, inputs and artifact.

CE-CTRL-01 The implementation guide defines negative probes for injection, stale memory, delegation, racing changes, forged evidence and long-horizon tasks. The accompanying reference checker demonstrates only structured envelope/signature/binding checks. It does not implement or prove sandbox, memory, concurrency, prompt-injection, signing-service or production-admission security.

Organizational authority and applicability

CE-CTRL-01 Before a pilot, teams MUST name independent Verification and Operations/admission owners, deputies, protected policy/key ownership, escalation and risk owners, and a practical response target for blocks. A deadline or manager's ticket status cannot override an unmet hard invariant. Review capacity and authority MUST exist in the implemented workflow; nominally separate role names are insufficient. Track review latency, substantive safety outcomes, exceptions and contract upkeep together, without rewarding release volume, rubber-stamping or denial counts.

CE-CTRL-01 [E0] A lightweight/discovery-only experiment may be appropriate for exploratory research, uncertain product hypotheses or small teams, but absent hard controls MUST remain explicit gaps rather than a full-conformance claim. A research question may have an hours/days window and a negative/inconclusive result; no universal 90-day value claim is required. Preserve history while revising uncertain intent. Avoid adding ceremony where existing controls already work. The concert metaphor creates no mandatory roles, meetings or documents beyond the stated semantics.

Audit and implementation acceptance

CE-CTRL-01 The implementation profile MUST define retention, access control, clock source, signer/key rotation, and append-only storage for accepted records, policy changes, waivers, and admission decisions. Test replay, tampering, stale evidence, unauthorized policy edits, denied mutations, source/artifact substitution, and emergency revocation before the first production change. Link each negative test to its observed enforcement result.

CE-CTRL-01 Publish which requirements are implemented, deferred, or unsupported. A deferred MUST is an explicit gap, not full conformance. No tool, sandbox type, language, or model is mandatory; controls must satisfy the stated semantics. Measure whether maintaining them improves total coordination cost and safe customer outcomes before expansion.

Publication and adoption governance

CE-CTRL-01 The governance reference defines the evidence ladder, canonical responsibilities, tiers, decision rights, maturity ladder, review templates and pending field work. Every published metric MUST have an owner, operational formula, counter-metric and anti-gaming rule. Metrics MUST NOT be used for individual performance evaluation. The original specification package is CC BY 4.0; original reference software is MIT under its included license. See the package notice for scope and third-party exclusions.

CE-CTRL-01 Normative changes MUST record problem, alternatives, decision, consequences and supersession in a versioned ADR. The current draft includes ADR-0004 and an explicit compatibility policy. An independently reviewed accepted-state snapshot MUST invalidate affected open candidates when governing references change; semantic coverage and approved selective reuse require protected review. An invariant without an enforcing check link is a drift defect. A local structural helper does not establish that production enforcement is installed.

CE-CTRL-01 Independent owners MUST approve acceptance oracles before generation where feasible, protect policy/tests from generator writes and audit protected changes through another authorized reviewer. Configuration-specific seeded-defect calibration MUST record clean controls, defect classes, catch/miss counts, false positives and limitations. An unmet registered floor suspends that verifier configuration until remediation. This measures sampled effectiveness, not statistical independence. T3 requires independent expert review and a realistic recovery/fault exercise; applicable irreversible constraints cannot be called rollback.

Formal lifecycle and authority model

CE-CTRL-01 The formal control reference specifies every transition, its actor, inputs, guards, result/evidence, failure, timeout and escalation. Required timeout values MUST be finite and registered before execution. Expected revisions MUST reject stale concurrent requests. A failed or expired operation MUST preserve accepted history and produce a recorded escalation rather than automatic approval. Superseding live work MUST hand responsibility to an operational owner.

CE-CTRL-01 Assurance classes A0–A3 are separate from publication evidence E0–E3/X. Risk tiers MUST meet the canonical assurance profile. Identity, policy/test write access, credentials, runner, test data and admission control MUST be independently assessed. The generator may mutate its candidate within scope but MUST NOT reach protected control/signing/admission/production through uncontrolled direct, delegated, build, dependency, symlink, credential or administrative paths.

CE-CTRL-01 The accepted state MUST support immutable identities, append-only revisions/events, current/superseded records, evidence expiry, affected-dependency invalidation, bidirectional links and access-controlled projections. Orphaned implementation/check/decision/requirement references MUST be reported. Hash integrity requires an independently protected checkpoint; local graph/link correctness does not supply authenticated storage or complete service discovery.

CE-CTRL-01 Exceptions MUST match protected policy, exact artifact/environment and a finite registered maximum TTL. Self-approval/history mutation/non-waivable safety cannot be waived. Promotion MUST stop at expired exceptions or overdue required review. Production integrations MUST enforce automatic credential expiration/revocation, audit and owner follow-up; the demonstrator only reports required work.

CE-CTRL-01 The claims and correction register identifies current assertions and material changes. Archived draft bytes remain historical evidence, not current endorsement. Operational completeness requires independent implementation from this specification without creator interpretation and observed real control enforcement; no such validation is asserted here.

Purposeful projections and ownership

CE-PROJ-01 Teams MUST distinguish divergent translation (contradictory or missing shared meaning) from purposeful projection (different representations for different decisions). Keep useful briefs, design documents, test plans and runbooks. Their source is the language-agnostic content model; YAML/JSON are serialization choices. A generated or verified view MUST identify its audience, one accountable projection owner, exact source IDs/revisions/digests, output identity and staleness rule in a projection registry. A test plan expands the Evidence policy and links its applicable Intent invariants; it is not an independently accepted set of requirements.

CE-PROJ-01 Source changes MUST identify affected projections and checks, notify their owners through the integrated system and flag stale source links, uncovered invariants and dead checks. These links cannot prove semantic equivalence. Each contract MUST have one directly accountable owner: intent/product, execution/engineering or independent verification, with deputies and technical approvals as needed. Authenticated edits from a document, form or code interface are proposals until schema and semantic review accept a new immutable revision. The current examples are read-only views; no editable dashboard or notification service is supplied.

Learning artifacts and release readiness

CE-ADOPT-01 A minimal IntentSeed may record the customer problem, accountable owner, invariant and outcome measure in an existing document. It is explicitly a learning artifact, not an accepted schema 0.2 contract. Presence-only CI checks MAY support literacy but MUST NOT be represented as verification or production admission. Missing hard requirements MUST block consequential execution. Teams MAY progressively author records or inherit independently approved profiles, while all applicable release controls, baseline collection and existing human approval remain in force.

Contract revision and impact protocol

CE-PROJ-01 Version meaning is separate from record-schema and methodology versions. Teams adopting normal MAJOR.MINOR.PATCH contract revisions MUST explicitly migrate legacy revision identifiers and declare their compatibility policy. This applies the communication idea of Semantic Versioning to contract changes; it is not a claim that SemVer alone defines safe evidence reuse.

Change class / Minimum action
Change classMinimum action
CE-PROJ-01 MAJORAny invariant addition, removal or redefinition, or material authority/safety/data/budget/required-check change: invalidate all evidence for the affected initiative, notify affected owners, collect required-role acknowledgments and reverify.
CE-PROJ-01 MINORIndependently reviewed compatible scope or acceptance refinement: declare the full affected dependency closure, invalidate its evidence and reverify. Unknown or ambiguous impact escalates to MAJOR.
CE-PROJ-01 PATCHPresentation-only correction outside normative semantics. Prefer a separately versioned annotation without changing accepted bytes. A new accepted record still requires exact rebinding or protected re-attestation; old signatures MUST NOT silently cover new revisions.

CE-PROJ-01 A version bump MUST NOT bypass exact artifact/contract/harness bindings or the existing invalidation model. The change class is reviewed by protected owners, not trusted because the generator selected it. Record re-verification effort and register a churn investigation trigger over a local review window. Frequent MAJOR changes are a diagnostic signal, not a quota or reason to defer necessary safety corrections. The experimental comparator inspects conservative field classes and supplied reviews; it does not establish semantic compatibility or mutate a production evidence store.

CE-ILL-01 · illustration

Documents derived from one record

[E0] Synthetic example. Select an Intent revision: every view below renders the same record and digest. This demonstrates document projection, not production enforcement or test results.

Change this revision and prior evidence must be reassessed.

PRD view

intent/token-expiry@r1
sha256:08b8d0beb64fae6c028e8b944c7c361713724e47260851089e7c04c52c99a7c6

Synthetic reproduction: an access token remains usable at its expiry boundary.

A token is expired when elapsed_seconds >= ttl_seconds.

  • No change to token format, signing keys, or authorization scopes.

Executive summary

intent/token-expiry@r1
sha256:08b8d0beb64fae6c028e8b944c7c361713724e47260851089e7c04c52c99a7c6

TTL: 30 seconds

7 days of follow-up

No attributable boundary-expiry regression in the declared monitoring window.

Test-plan view

intent/token-expiry@r1
sha256:08b8d0beb64fae6c028e8b944c7c361713724e47260851089e7c04c52c99a7c6

The checks below are required assertions, not passing results.

  • 0s → Valid
  • 29s → Valid
  • 30s → Expired
  • 31s → Expired

Projection ownership and lineage

Useful representations answer different questions. These compact Intent-only views are read-only illustrations, not conforming schema 0.2 records or an accepted Evidence policy. A real test plan also references that policy. Owners below are duties to assign, not pilot appointments.

  • Product · Intent owner: Selected compact Intent revision. Re-render when selected ID/revision/digest changes.
  • Leadership · Outcome owner: Selected compact Intent revision. Re-render when selected ID/revision/digest changes.
  • Verification · Verification owner: Selected compact Intent revision; draft assertions only. Re-render when invariant or acceptance cases change; accepted test plans also need Evidence policy.
Full registry fields and local drift checks
Source record · r1
{
  "schema_version": "0.1",
  "kind": "IntentContract",
  "id": "intent/token-expiry",
  "revision": "r1",
  "status": "illustrative",
  "owner": "product-and-engineering",
  "created_at": "2026-10-20T00:00:00Z",
  "problem": "Synthetic reproduction: an access token remains usable at its expiry boundary.",
  "behavior": "A token is expired when elapsed_seconds >= ttl_seconds.",
  "ttl_seconds": 30,
  "acceptance_cases": [
    {
      "age_seconds": 0,
      "expired": false
    },
    {
      "age_seconds": 29,
      "expired": false
    },
    {
      "age_seconds": 30,
      "expired": true
    },
    {
      "age_seconds": 31,
      "expired": true
    }
  ],
  "invariants": [
    "No change to token format, signing keys, or authorization scopes."
  ],
  "change_tier": "lightweight",
  "observation": {
    "horizon_days": 7,
    "criterion": "No attributable boundary-expiry regression in the declared monitoring window."
  },
  "decision_ref": "Reuse the accepted token-expiry policy; create an ADR only if that decision changes.",
  "digest": "sha256:08b8d0beb64fae6c028e8b944c7c361713724e47260851089e7c04c52c99a7c6"
}

Tool choice and commercial relationship

OpenKedge publishes this proposal and develops KedgeFlow, a related execution-control protocol and reference implementation. The author is OpenKedge’s founder and has a commercial interest in this problem. No OpenKedge product, paid engagement, specific model or vendor is required. Product existence and self-citations do not establish conformance or organizational benefits; evaluate implemented controls and independent evidence.

Plan a controlled pilot