Public Claims Correction Package

Basis: autonomyops-gap-closure-workplan-v1_2.md (canon), implementation state from project memory, public materials from repo README + docs.

Current gate assessment: Approaching Gate B (design partner ready). Gate C (GA) not yet achieved. Gate D (public production claim) requires 30-day soak + chaos tests and has not started.

1. Executive Risk Summary

Top 10 credibility risks, highest impact first.

  1. Release artifact language implies shippable software
    README references Stage 1 release artifacts (adk_<version>_<os>_<arch>.tar.gz, images, SHA256SUMS) in terms that can imply published release readiness. No Gate D validation evidence exists.

  2. HA Control Plane claims without soak/chaos evidence
    Replication/election/fencing are implemented, but the workplan requires soak + chaos evidence for validated HA positioning.

  3. Container image references without multi-arch validation
    Image paths can imply published/validated multi-arch delivery, while multi-arch remains roadmap.

  4. OS Reconstruction implied as available
    Code paths exist, but hardware-gated validation is required before production-facing claims.

  5. Contested-connectivity relay implication
    Local-network validation exists; contested-connectivity (sat/cellular) validation is pending.

  6. Fleet Rollouts presented as fully operator-ready
    Core domain/evaluator are implemented; full operator surface and Gate C/D behavior are not complete.

  7. evict_on_relay documented as implemented behavior
    Checklist notes behavior gap in current code path.

  8. License remains TBD
    Missing definitive license creates legal and partner adoption risk.

  9. RBAC/queryable audit implied by adjacent docs
    Full enforcement and retention/query posture are later-gate items.

  10. Unqualified “validated/deterministic” language spread
    Deterministic claims are safe only where evidence is specific and bounded by scope.

2. Claims Correction Table

#

Original Claim

Status

Why It’s Risky or Safe

Bucket

Required Evidence to Upgrade

Corrected Claim

1

Release artifacts listed as Stage 1 output

Misleading / overclaim

Implies shipped/near-ship release

A

Gate B closure + signed/published artifacts

Planned artifact format; not yet published

2

Container image reference implies ready distribution

Needs downgrade

Multi-arch not validated/published

A -> B (x86_64), E (multi-arch)

Published x86_64 first; Gate E for multi-arch

Container image format in development

3

“HA Control Plane” (unqualified)

Safe with qualifier

Implementation exists, production proof not complete

B

Soak + failover + chaos evidence

HA architecture implemented; production validation planned

4

PG replication + election + fencing

Safe as written

Matches current implemented architecture

B

Soak evidence for production claims

Keep as-is with validation qualifier

5

OS Reconstruction in present-tense availability

Needs downgrade

Hardware-gated validation pending

E

Device-matrix validation complete

In active development; hardware validation pending

6

evict_on_relay behavior implied active

Misleading / overclaim

Known implementation gap

A

Implement + tests

Flag parsed, behavior not yet implemented

7

Deterministic relay behavior

Safe as written

Bounded deterministic scheduler semantics implemented

B

Expand external validation scope

Deterministic local-network relay semantics implemented

8

Contested-connectivity relay implied validated

Needs downgrade

Only local-network validation complete

C -> E

Sat/cellular hardware validation

Local-network validated; contested beta/roadmap

9

Fleet Rollouts implied fully operator-ready

Needs downgrade

Core implemented; full operational posture pending

B -> C/D

Gate C/D workflow + soak evidence

Rollout domain/evaluator implemented; operator workflow in development

10

Fail-closed policy evaluation

Safe as written

Implemented and tested

B

-

Keep as-is

11

Offline-first local decisions

Safe as written

Implemented with local authority/cache/WAL behavior

B

-

Keep as-is

12

cosign + BLAKE3 + Ed25519 + semver verify pipeline

Safe as written

Implemented and tested

B

-

Keep as-is

13

Atomic crash-safe mTLS cert rotation

Safe as written

Implemented with atomic swap semantics and tests

B

-

Keep as-is

14

RBAC implied available

Needs downgrade

Full RBAC is later-gate

C/D

Basic then full enforcement evidence

RBAC planned for GA milestones

15

Queryable audit implied available

Needs downgrade

Partial surfaces exist; unified retention/query posture pending

C/D

Unified audit + retention evidence

Audit foundations present; full queryable audit planned

16

Comprehensive observability implied

Needs downgrade

OTel bridge exists; full posture is later-gate

C

Full observability foundations complete

OTel bridge implemented; comprehensive observability planned

17

License TBD

Not claimable

Legal ambiguity for usage/partnering

B prerequisite

Choose/publish license

License selection pending before partner engagement

18

Evidence-backed behavior

Safe with qualifier

Harness exists; HIL remains advisory in places

B

Required-gate promotion evidence

Evidence-backed with explicit advisory/required split

19

Multi-architecture implied current

Hardware-gated

Not validated as shipped capability

E

Aarch64/riscv64 validated artifacts

x86_64 current; multi-arch in development

20

Native riscv64 hardware CI implied current

Hardware-gated

Current posture is QEMU-validation only

E

Native HW CI in place

riscv64 QEMU-validated; native CI roadmap

3. Corrected Public Copy

Homepage Version

AutonomyOps ADK is a governance runtime and capability kit for autonomous systems operating offline and in connectivity-constrained environments.

  • Policy-gated execution with fail-closed OPA/Rego evaluation.

  • Edge-authoritative local decision model; control plane remains advisory.

  • Cryptographic release verification pipeline.

  • Deterministic relay semantics (local-network validated).

  • WAL-backed telemetry durability.

Fleet Rollouts, Control-plane HA, and Edge Relay are in active development toward design partner milestones. Production validation (including soak and chaos testing) is planned for GA milestones.

Docs / README Version

Implemented now

  • Fail-closed policy evaluation

  • Offline-first edge authority model

  • Cryptographic verification pipeline

  • Deterministic relay scheduler semantics (local-network)

  • WAL telemetry buffering/export

  • mTLS cert rotation (atomic crash-safe path)

In active development / roadmap

  • Full rollout operator surface and higher-gate recovery flows

  • Production-validated HA failover posture

  • Multi-arch container validation

  • Native riscv64 hardware CI

  • Hardware-validated OS reconstruction

  • Full RBAC + queryable unified audit + extended observability

Design Partner / Sales Version

ADK is positioned for design partner engagements requiring deterministic policy enforcement, local authority under disconnection, and verifiable release activation. Current capability focus is nucleus development with evidence-oriented milestone progression, not public production-readiness claims.

Investor-Safe Version

AutonomyOps is building the governance runtime layer for autonomous systems that must operate in offline/contested environments. Nucleus capabilities are substantially implemented and are being validated toward design partner and GA gates using explicit evidence milestones.

LinkedIn / Short-Form Version

We are building the governance/runtime layer for autonomous edge systems: local policy enforcement, deterministic behavior, and cryptographic release verification. Fleet Rollouts, Control-plane HA, and Edge Relay are in active development with milestone-gated validation.

4. Red Flag Phrases to Ban

Ban for now

Replace with

production-ready

in active development / targeted for GA

highly available

HA architecture in development

battle-tested

integration-tested / validation in progress

enterprise-ready

enterprise-oriented roadmap

resilient / fault-tolerant

deterministic recovery semantics (scoped)

validated failover

failover tested in integration; soak planned

zero-downtime

failover target X (planned/validated if proven)

multi-architecture

x86_64 current, multi-arch roadmap

hardware-validated

hardware validation planned / in progress

compliant

no compliance claim

5. Claims Upgrade Map

  • Now (A/B edge): policy enforcement, local authority, verification pipeline, deterministic relay semantics (scoped), WAL durability, active-development positioning.

  • After Gate B: basic operator workflows and design-partner-safe positioning.

  • After Gate C: production foundations (stuck handling, recovery workflows, promotion gates, audit/RBAC foundations, observability foundations).

  • After Gate D: public production-readiness claims (soak + chaos + reliability evidence).

  • Gate E only: hardware-gated claims (OS reconstruction breadth, contested-connectivity validation, native riscv64 CI, full multi-arch validation).

6. Forward Claims Policy

  1. Only designated maintainers publish external product claims.

  2. Every production-sounding claim must cite gate evidence.

  3. Roadmap language must be labeled as planned/targeted, never present-tense implemented.

  4. Hardware-gated features must carry explicit conditional wording until Gate E evidence exists.

  5. Validation targets are not achieved evidence.

  6. “Production-ready” language is prohibited before Gate D closure.