tegwick
74bfb3b664
approval-engine filed APPROVAL-IN-0002: secrets-engine built its PEP
validator against our ActionAuthorization schema, pointed it at
GET /v1/approvals/{id}/claim, and it rejects every response. Both
envelopes declare schema_version 0.1, so it fails late and reads like an
approval-engine outage rather than a contract mismatch.
FLEX-DEC-2026-006 accepts the deferral and argues against flex-auth's own
proposal. The composed object had the PIP republish our decision, which
crosses the same layer boundary we invoked to decline authentication
evidence and to win section 17's schema. The claim-plus-DecisionEnvelope
split drops no check; each verification lands on the layer that owns it.
approval-engine asked, before the decision, whether the open G3 finding
argues for ratifying now. It does not: G3 is already closed the other
way. FLEX-WP-0019 added lifetime to the DecisionEnvelope itself, required
on every allow by schema conditional, published 2026-09-02. The trigger
resolved by adding a field rather than by composition, so the decision
stands alone and needs no bundle.
The provenance.authority == state-hub constant is our defect and is
fixed at source. It came from examples/caring/action_authorization.json,
which contradicted the same contract's ownership section. That fixture
now names approval-engine as the approval fact's authority and flex-auth
as the decision's, and its stale secrets-engine.lifecycle pin is
corrected to the reserved coordinate from FLEX-DEC-2026-005.
The contract doc and schema are marked deferred-not-withdrawn so no
other consumer builds a validator against them. The execute-time half is
untouched: /v1/check, binding, the canonical digest, and
flex-auth.decision-record.v1 stay published.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JTbVXpEiXA7mNJVpDnEPcB
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 412054@bnt-lap001
Assistant-Session: 3968fae1-8d59-4209-9bd6-c22594b8ab19
|
||
|---|---|---|
| .. | ||
| access_descriptor.yaml | ||
| action_authorization.json | ||
| audit_event.json | ||
| batch_check_request.yaml | ||
| check_request.yaml | ||
| decision_envelope.json | ||
| exposure_event.json | ||
| inherited_relationships.yaml | ||
| policy_fixture.yaml | ||
| policy_package.md | ||
| policy_package.yaml | ||
| project_resource_manifest.yaml | ||
| README.md | ||
| redact_policy_package.md | ||
| registry_snapshot.json | ||
| relationship_fact.yaml | ||
| subject_manifest.yaml | ||
| team_subject_manifest.yaml | ||
CARING examples
Small fixtures for the executable CARING 0.4.0-RC2 profile used by
FLEX-WP-0002.
These are intentionally compact. They prove that the canonical descriptor,
request, decision, registry, audit, and Rego-in-Markdown policy package
shapes can round-trip through pkg/api and internal/policy.
The set includes local subjects, groups, teams, project resources, inherited relationship facts, exposure events, allow/deny fixtures, and a redact-with-obligation policy package.