net-kingdom/canon/standards/posture-feedback_v0.1.md
tegwick cfc9e7d0cb
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
feat(posture): add deterministic feedback proposals
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02929-244b-7391-b933-c04010e8eedb
2026-08-23 13:16:34 +02:00

109 lines
4.2 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
id: netkingdom-posture-feedback-v0.1
type: standard
title: "NetKingdom Posture Feedback v0.1"
domain: netkingdom
status: proposed
version: "0.1"
owner: net-kingdom
created: "2026-08-23"
updated: "2026-08-23"
last_reviewed: "2026-08-23"
review_interval: 3m
scope: self-optimizing-security
schema:
- canon/schemas/posture-feedback-report_v0.1.schema.json
validator:
- tools/posture-feedback/posture_feedback.py
related:
- canon/standards/tenancy-posture_v0.1.md
- canon/standards/security-zones_v0.1.md
---
# NetKingdom Posture Feedback v0.1
## 1. Purpose
This contract is the first bounded C6 feedback mechanism. It turns explicit
posture review dates, evidence freshness, implemented-but-unevidenced controls,
and declared gaps into deterministic remediation **proposals**.
It does not modify a posture level, policy, declaration, workplan, State Hub,
or runtime. Human or separately governed automation decides whether a proposal
becomes work.
## 2. Deterministic time
Evaluation requires an explicit RFC 3339 `as_of` timestamp. Wall-clock time is
never read implicitly. A date-only `review_due` remains current through that
calendar date in UTC and becomes overdue on the following UTC date.
A non-negative horizon in days identifies items due soon. Changing the horizon
changes the report digest and is therefore visible.
## 3. Owner resolution
The evaluator routes only from authoritative declaration fields:
- posture review, gaps, and implemented controls: `responsible_repo`;
- evidence replacement: `evidence_freshness.<level>.responsible_repo`;
- security-zone review: `zones.responsible_party`.
If the relevant field is absent, owner resolution is `unknown`. The evaluator
must not infer ownership from the service name, repository path, Git remote,
previous work, or another policy subject.
## 4. Finding classes
| Finding | Trigger | Severity |
| --- | --- | --- |
| `posture-review-overdue` | `as_of` is after `tenancy.review_due` | high |
| `posture-review-due-soon` | review is within the horizon | medium |
| `zone-review-overdue` | `as_of` is after `zones.review_due` | high |
| `zone-review-due-soon` | zone review is within the horizon | medium |
| `evidence-freshness-unknown` | a current adversarial level has no complete freshness entry | high |
| `evidence-expired` | `as_of` is after `valid_until` | high |
| `evidence-due-soon` | evidence expires within the horizon | medium |
| `implemented-not-evidenced` | an `implemented` level is above `current` | medium |
| `declared-gap` | a non-empty `tenancy.gap` entry exists | low |
The review horizon does not generate a due-soon finding for an item already
overdue or expired. Exact equality with a timestamp is still valid; expiry is
strictly `as_of > valid_until`.
Current adversarial levels are `E2`, `R4`, and `V2``V4`. This vocabulary comes
from Tenancy Posture §13. Mechanical evidence is evaluated for expiry only when
its declaration explicitly supplies `valid_until`.
## 5. Proposal and safety boundary
Every finding receives a stable id derived from its source declaration,
service, finding class, control, and due value. It contains the authoritative
owner or `unknown`, current evidence state, reason, and recommended action.
For declarations under the workspace containing this repository, the source is
normalized to `<repo>/<path>` so absolute checkout locations do not perturb the
identity. This source normalization identifies an input only; it is never an
ownership inference.
Every report declares:
```yaml
automation:
mode: proposal-only
external_write_permitted: false
policy_mutation_permitted: false
declaration_mutation_permitted: false
```
Expired or unknown evidence does not silently inherit freshness and does not
silently downgrade a level. It makes the uncertainty visible for governed
review. Consumers that use the report as an admission gate may fail closed on
high findings, but that is a separate owner decision.
## 6. Exit behavior
The CLI emits a report conforming to
`posture-feedback-report_v0.1.schema.json`. `--fail-on high` exits non-zero when
at least one high-severity finding exists; `medium` includes medium and high;
`low` includes every finding; `none` reports without a finding-based failure.
Invalid declarations always exit non-zero.