RFC: TealTiger v1.5 — Agent Development Lifecycle (ADLC) Governance Platform

[nagasatish007]

RFC: TealTiger v1.5 — Agent Development Lifecycle (ADLC) Governance Platform

Status: Draft — Seeking Community Feedback
Authors: TealTiger Core Team
Created: July 12, 2026
Target Release: Q4 2026
Discussion: GitHub Discussions

---

Summary

TealTiger v1.5 transforms the project from a governance SDK into a full Agent Development Lifecycle (ADLC) Governance Platform — covering all six phases of building production AI agents with defense-in-depth governance across 3 architectural levels:

Build → Test → Deploy → Monitor → Iterate → Govern

3 Governance Levels:

┌─────────────────────────────────────────────────────────┐
│       Level 3: CENTRAL CONTROL PLANE                    │
│  Dashboard · Fleet Mgmt · Policy Distribution · RBAC    │
├─────────────────────────────────────────────────────────┤
│       Level 2: AGENT (Infrastructure Governance)        │
│  K8s · Docker Runtime · OS/Kernel · eBPF · Network      │
├─────────────────────────────────────────────────────────┤
│       Level 1: SDK (Application Governance)             │
│  In-process · observe() · TealGuard · Cost · PII        │
└─────────────────────────────────────────────────────────┘

We're publishing this RFC to invite community feedback on scope, priorities, API design, and use cases before implementation begins.

---

Motivation

v1.4 established TealTiger's governance core: observe() zero-config adoption, deterministic policy enforcement, multi-stage defense, cost governance, 12-provider support, and cross-framework adapters (LangChain, CrewAI, Haystack, Strands, AG2).

But teams building agents in production consistently tell us the same thing:

"Governance is table stakes. What we actually need is the full lifecycle — testing governance policies before deployment, understanding what's happening across 50+ agents, iterating on policies with data instead of guessing, and proving compliance to auditors."

v1.5 fills these gaps while maintaining TealTiger's core principles:

• Deterministic — no LLM in the governance path
• In-process — no mandatory external service
• < 5ms overhead — governance never becomes the bottleneck
• Framework-agnostic — works with any agent framework

---

Architecture: 3 Levels of Governance (Defense-in-Depth)

Just as container security platforms (Aqua, Prisma Cloud) defend at multiple layers, TealTiger v1.5 introduces defense-in-depth governance across three architectural levels:

Level 1: SDK Governance (Application Layer)

What: In-process, in-code governance embedded inside the agent application.
Where it runs: Inside the agent process — no sidecar, no proxy.
What it governs: LLM calls, tool invocations, cost budgets, PII, prompts, kill switch.
Status: This is TealTiger today (v1.0–v1.4).

from tealtiger import observe
client = observe(OpenAI())  # Immediate governance — zero config

Level 2: Agent Infrastructure Governance (Infra Layer)

What: Infrastructure-level enforcement for the compute environment where agents run. Purpose-built for AI agent workloads — like Aqua/Prisma Cloud, but for agents.
Where it runs: K8s admission controllers, Docker runtime hooks, eBPF probes, OS-level syscall filters.
What it governs:

Boundary	Governance Capabilities
Kubernetes	Admission control (approved agent images only), network policies (restrict API egress), resource quotas (CPU/memory/GPU per agent), pod security standards
Docker/Container	Read-only filesystems, blocked egress endpoints, process spawn limits, mount restrictions, runtime scanning
OS/Kernel	Seccomp profiles for agent processes, eBPF-based network monitoring, file access auditing, syscall allowlisting
Network	Service mesh integration, mTLS between agents, API gateway policies for agent-to-agent communication, egress allowlists

# TealTiger K8s AdmissionPolicy
apiVersion: tealtiger.ai/v1
kind: AgentPolicy
metadata:
  name: research-agent-boundary
spec:
  selector:
    matchLabels:
      tealtiger.ai/role: researcher
  network:
    egressAllow: ["api.openai.com", "api.anthropic.com"]
    egressDeny: ["*"]
  resources:
    maxCostPerHour: 10.00
    maxMemoryMb: 2048
  filesystem:
    readOnly: true
    allowedPaths: ["/workspace/data/**"]
  runtime:
    blockedSyscalls: ["execve", "fork"]
    maxProcesses: 5

Level 3: Central Control Plane (Management Layer)

What: Single pane of glass that manages governance across all agents, all environments, all levels. Extension of the existing TealTiger dashboard into a full fleet management + policy distribution platform.
Where it runs: Centralized service (self-hosted or cloud-hosted).
What it manages:

• Policy Distribution — Author policies centrally, push to SDK agents + K8s clusters + Docker hosts simultaneously
• Fleet Visibility — Agent registry showing all agents across all levels with health, cost, compliance posture
• Cross-Level Correlation — SDK denial + infra network block = correlated incident (not two separate alerts)
• Kill Switch Propagation — freeze("*") propagates from control plane → SDK level + infra level simultaneously
• RBAC & SSO — Team-scoped access, custom roles, SAML/OIDC
• Compliance Reporting — Board-ready reports aggregating evidence from all 3 levels
• Policy A/B Testing — Test policy changes across the entire stack before promoting
• Governance Regression — CI/CD gate that validates policy changes don't break across any level

How the 3 Levels Work Together

┌─────────────────────────────────────────────┐
│         Central Control Plane               │
│  Push policies │ Collect telemetry │ Alert  │
└───────┬─────────────────────────┬───────────┘
        │                         │
        ▼                         ▼
┌───────────────┐       ┌─────────────────────┐
│  Level 1: SDK │       │  Level 2: Infra     │
│  (in-process) │       │  (K8s/Docker/OS)    │
│               │       │                     │
│ • PII scan    │       │ • Network boundary  │
│ • Cost limit  │       │ • Syscall filter    │
│ • Tool allow  │       │ • Resource quota    │
│ • Kill switch │       │ • Image admission   │
└───────────────┘       └─────────────────────┘
        │                         │
        └─────────┬───────────────┘
                  ▼
         [Agent Process in Pod]

Example: Coordinated Defense

1. Agent tries to exfiltrate data via curl to external endpoint
2. Level 1 (SDK): TealGuard detects PII in the tool call arguments → blocks at application layer
3. Level 2 (Infra): Even if SDK is bypassed, K8s network policy blocks egress to unapproved endpoint
4. Level 3 (Control Plane): Correlates both signals, triggers alert, auto-freezes the agent fleet-wide

Open questions:

• Should Level 2 be delivered as a Helm chart, an operator, or both?
• Which eBPF-based capabilities are highest priority? (network monitoring vs. syscall filtering vs. file access)
• Should the control plane be self-hosted only, or offer a managed cloud option?

---

Proposed Features

🧪 TEST Phase

1. Governance Eval Dataset Builder

Automatically harvest denied/flagged production traces and turn them into reusable regression test fixtures. Run governance regression against any policy version in CI/CD.

# Promote a production denial to the regression dataset
platform.promote_to_eval(decision_id="abc-123")

# Run regression against a new policy version
results = platform.run_governance_regression(
    dataset="production_denials_q3",
    policy=new_policy_v2
)
# → Reports which decisions changed (allow↔deny)

Open questions:

• Should auto-promotion require a review period? (Proposed: 7 days)
• What's the right threshold for auto-harvesting? (Proposed: risk_score > 0.7)

2. Multi-Turn Governance Simulation

Test governance across full agent conversations — not just single tool calls. Simulate escalation chains, delegation, retry storms, and multi-step workflows.

simulator = GovernanceSimulator(policy=my_policy)
report = simulator.run(trajectory=[
    {"agent": "researcher", "action": "search_db", "args": {...}},
    {"agent": "researcher", "action": "delegate_to", "target": "writer"},
    {"agent": "writer", "action": "generate_report", "args": {...}},
    {"agent": "writer", "action": "send_email", "args": {...}},  # Should this be denied?
])

Open questions:

• What pre-built scenarios would be most useful? (Proposed: retry storms, privilege escalation, budget exhaustion, PII exfiltration, delegation chain abuse)
• Should the simulator support real LLM calls or only scripted trajectories?

---

🔄 ITERATE Phase

3. Policy A/B Testing

Run two policy versions on split traffic. Compare allow/deny rates, false positives, and cost impact with real production data.

experiment = platform.create_experiment(
    name="stricter_pii_policy",
    primary=current_policy,
    alternate=proposed_policy,
    traffic_split=0.1,  # 10% sees alternate
    duration_days=7
)
# After 7 days: experiment.report() shows comparison

Open questions:

• Should the alternate policy be "shadow" (record-only) or optionally enforced on split traffic?
• What's the minimum sample size before a recommendation is statistically significant?

4. Production-to-Eval Automated Loop

Continuous pipeline: Production anomalies → Candidate fixtures → Auto-promotion → Regression dataset → CI/CD gate.

Production traces
    ↓ (anomaly detection: denial spikes, new reason codes)
Candidate eval fixtures
    ↓ (7-day review period)
Active regression dataset
    ↓ (runs on every policy PR)
CI/CD governance gate (pass/fail)

Open questions:

• Should anomaly detection be configurable per team, or global?
• What SLA should we target for the loop latency (trace → candidate)?

---

🏗️ BUILD Phase

5. Prompt and Context Governance

Govern what goes INTO the agent — not just what comes out. New pre_inference phase catches prompt injection, context poisoning, and memory manipulation before the LLM sees them.

guardrails = {
    "pre_inference": {"injection": "block", "context_poisoning": "block"},
    "pre": {"pii": "block", "cost": "enforce"},
    "post": {"secrets": "block", "harmful_content": "monitor"}
}

Open questions:

• How aggressive should default injection detection be? (Trade-off: false positives vs. security)
• Should context allowlisting be per-retrieval-source or per-content-pattern?

6. No-Code Governance Builder

Visual policy builder for compliance officers. Natural language → policy rule generation. Template marketplace for SOC2, HIPAA, GDPR, PCI-DSS.

"Block all tool calls that access customer PII unless the agent has admin role"
    ↓ (auto-generates)
{type: "pii_block", categories: ["ssn", "credit_card"], except_roles: ["admin"]}

Open questions:

• Should the NL→policy generator use a local model or cloud? (Trade-off: determinism vs. flexibility)
• What governance templates would you use first? (SOC2? HIPAA? Custom?)

---

🏛️ GOVERN Phase

7. Agent Registry and Discovery

Central registry of all governed agents. See roles, policies, cost, health, and governance posture across your fleet. Flag ungoverned agents.

Agent	Role	Framework	Mode	Cost (7d)	Denial Rate	Health
research-bot	researcher	LangChain	ENFORCE	$12.40	2.1%	✅
writer-agent	writer	CrewAI	OBSERVE	$8.70	0%	⚠️ No policies
code-executor	admin	Strands	ENFORCE	$45.20	8.4%	✅

Open questions:

• Should discovery be automatic (via observe mode) or require explicit registration?
• What governance readiness score dimensions matter most to you?

---

📊 MONITOR Phase

8. Native Governance Trace Viewer

End-to-end trace viewer independent of Langfuse/AgentOps. See pre-inference → LLM → tool → output governance in one timeline. Supports replay against new policies.

9. Feedback Collection API

Link user feedback to governance decisions. Surface false positive patterns where governance is hurting UX.

platform.submit_feedback(
    trace_id="xyz-456",
    rating="negative",
    comment="I needed this tool call to work for my use case"
)
# → Surfaces as potential false positive for policy review

---

🚀 DEPLOY Phase

10. Sandbox Governance

Govern agent behavior inside sandboxed execution (Daytona, E2B, Docker). Scan code for destructive operations, network exfiltration, and resource exhaustion before execution.

sandbox_policy = {
    "allowed_paths": ["/workspace/**"],
    "blocked_commands": ["rm -rf", "DROP TABLE", "curl"],
    "max_execution_time": 30,
    "max_memory_mb": 512
}

Open questions:

• Which sandbox providers should we support first? (Proposed: Daytona, E2B, Docker)
• Should sandbox governance be synchronous (block before exec) or async (kill after violation)?

---

📈 ANALYTICS & REPORTING

11. Rich Analytics Engine

Custom queries, time-series aggregation, cohort analysis, top-N analysis, saved queries, BI tool integration (Looker, Metabase, Grafana).

12. Historical Trends

7/30/90-day governance trends, WoW/MoM comparisons, anomaly detection, governance health score trending.

13. User and Team Management

RBAC, SSO (SAML/OIDC), team hierarchy, per-team cost allocation, custom roles, API key management.

14. Interactive Agent Trajectory DAG

Visualize multi-agent workflows as interactive graphs. Step-through replay, governance intervention highlighting, what-if overlay.

15. Compliance Reporting

Scheduled PDF/CSV reports, SOC2 evidence packaging, board-ready one-page governance summaries.

---

🌐 WEBSITE

16. Cost of Ungoverned AI Calculator

Interactive calculator showing projected burn without governance vs. with governance. Shareable via URL.

17. Board-Ready AI Governance Report

One-page PDF for C-suite. Business terms only — dollars, percentages, risk levels. No jargon.

---

Design Principles

1. Progressive disclosure — Each feature works standalone. You adopt what you need.
2. Deterministic governance — No LLM in the decision path. Same input → same output. Always.
3. Framework-agnostic — Works with LangChain, CrewAI, Haystack, Strands, AG2, custom code.
4. Self-hosted first — Everything runs in your infra. No mandatory SaaS.
5. Open source — Apache 2.0. No open-core bait-and-switch.

---

What We Need From You

We're looking for feedback on:

1. Priority ranking — Which features would you use first? What's missing?
2. API design — Do the proposed interfaces feel right for your workflow?
3. Use cases — What governance scenarios are you struggling with today that v1.5 should solve?
4. Trade-offs — Where should we prioritize simplicity over power (or vice versa)?
5. Integration needs — What tools/platforms should v1.5 integrate with that aren't listed?

---

How to Provide Feedback

• GitHub Discussion: Comment on this RFC in GitHub Discussions (preferred)
• GitHub Issues: File a feature request with the rfc-v1.5 label
• Email: feedback@tealtiger.ai
• Discord: TealTiger Community

---

Timeline (Proposed)

Phase	Target	Focus
RFC feedback period	Jul–Aug 2026	Community input, priority refinement
Alpha (core features)	Sep 2026	Eval dataset, trace viewer, agent registry
Beta (full platform)	Oct 2026	All features, integration testing
GA release	Nov 2026	Production-ready v1.5.0

---

Prior Art and Acknowledgments

This RFC draws inspiration from:

• Weights & Biases — experiment tracking and evaluation datasets
• LaunchDarkly — feature flags and A/B testing patterns
• Datadog — APM trace visualization
• OpenTelemetry — observability standards
• Haystack / LangSmith — agent evaluation approaches

---

TealTiger is open-source AI agent security. Deterministic governance, no LLM in the governance path, 95%+ provider coverage.

GitHub: github.com/agentguard-ai/tealtiger
Docs: docs.tealtiger.ai
Blog: blogs.tealtiger.ai

[Mayur021]

Answering "what's missing": the axis I don't see in the v1.5 list is reversibility. Everything here governs whether an action is allowed (policy, guardrails) and proves that it happened (TealProof receipts), but nothing grades actions by how hard they are to undo. That axis decides how much governance machinery each action actually needs: a read-only call and an irreversible external write should not carry the same gate, and a deterministic engine is the right place to enforce that split.

Two places it lands in what you already have:

• TealProof proves an action occurred and under which policy (verifiability). It does not record whether the action was safe to run unattended (governability). If the receipt carries the action's reversibility class (read-only / reversible / externally reversible / irreversible, the OWASP AISVS v1.0 C9.2.3 vocabulary) plus the gate path (auto / approval / blocked), an auditor can reconstruct which actions should have needed a human, which the receipt alone does not show. Same Merkle-and-timestamp machinery, one more field.
• With a 50+ agent registry and multi-turn chains, the gate should evaluate the worst-case reversibility class reachable across the chain, not per call. Individually reversible steps can compose to an irreversible end state.

For the deterministic-gate story to hold, the classification has to be design-time and not agent-assignable, which fits your no-LLM-in-governance stance.

[nagasatish007]

@Mayur021 — this is an excellent observation. You're right that reversibility is a missing governance axis, and it's exactly the kind of feedback we were hoping for.

The core insight: a read-only query and an irreversible external write should not carry the same governance gate. The risk of an action isn't just "does it violate a policy?" — it's "how bad is it if this action was wrong, and can we undo it?"

Here's how I see this fitting into v1.5:

1. Reversibility Classification (Design-Time, Deterministic)

We'd add a reversibility class to every tool/action in the registry:

Class	Definition	Example	Default Gate
read_only	No state change	search_db, get_weather	Auto-allow
reversible	Can be undone programmatically	create_draft, add_to_cart	Auto with audit
externally_reversible	Undo requires external action	send_email (can recall), create_PR	Approval queue
irreversible	Cannot be undone	delete_account, execute_trade, publish_to_prod	Hard block or human approval

This classification is design-time and deterministic — assigned by the policy author, not the agent. Fits the no-LLM-in-governance principle perfectly.

2. TealProof Extension

The governance receipt already carries policy_ref, intent_ref, risk_score. We'd add:

{
  "reversibility_class": "externally_reversible",
  "gate_path": "approval",
  "approved_by": "operator@company.com",
  "approval_timestamp_ms": 1720000000000
}

Same Merkle-and-timestamp machinery. One more field. Auditors can now reconstruct: "this irreversible action required human approval, and here's who approved it."

3. Chain-Level Worst-Case Analysis

Your point about individually reversible steps composing to an irreversible end state is spot-on. For multi-turn chains and the simulator (Feature #2), we'd evaluate:

chain_reversibility = worst_case(step_1.class, step_2.class, ..., step_n.class)

If any step in the chain is irreversible, the chain is treated as irreversible for governance purposes — even if each individual step looks benign.

This also feeds into the Agent Trajectory DAG (Feature #14) — we can color nodes by reversibility class and highlight the point where a chain crosses from reversible to irreversible.

4. Reference to OWASP AISVS

Good call on the C9.2.3 vocabulary. We'd align our classification with that standard to maintain interoperability with broader AI security frameworks.

---

Next steps: I'm adding this as a first-class requirement in the v1.5 spec. The reversibility axis will likely land in:

• The tool registry (design-time classification)
• The governance gate (dynamic gate selection based on class)
• TealProof receipts (auditability)
• The multi-turn simulator (chain-level analysis)
• The control plane (fleet-wide reversibility posture view)

Thanks for this — it makes the governance model significantly more complete. This is exactly what deterministic governance should do: the hard classification decisions happen at design time, not runtime.

[Mayur021]

This is a faithful integration, and the receipt extension is the right move: one field, same Merkle-and-timestamp machinery, and the proof now shows not just that an action happened but that an irreversible one was gated and by whom. That is the governability-versus-verifiability line, closed.
Two things for full AISVS interop. The classification is C9.2.3, but the two controls doing the real work in your design have their own numbers worth citing: enforcing the gate by class is C9.2.4, and the chain worst-case rule is C9.2.10 (worst-case class governs the composed chain). Aligning to all three keeps you interoperable with anyone auditing against the standard.
One edge case the table does not cover: the default for an unclassified action. A new tool added to the registry with no class assigned should fail closed, treated as irreversible until a human classifies it, so nothing reaches auto-allow by omission. And keep the class authoritative over risk_score in gate selection: risk can escalate a gate, but a low risk score should never downgrade an irreversible action, since risk is an estimate and the class is a design-time fact.
Good to see it landing as a first-class requirement.

[nagasatish007]

@Mayur021 — solid follow-up. All three points are going into the spec.

AISVS control numbers noted. We'll explicitly cite C9.2.3 (classification), C9.2.4 (gate enforcement by class), and C9.2.10 (chain worst-case composition) in the requirement and in the TealProof evidence schema. Anyone auditing against AISVS should be able to map directly to our implementation.

Fail-closed default for unclassified actions — agreed. This is the correct stance:

unclassified tool → treated as irreversible → requires human approval
No action reaches auto-allow by omission. Classification is an explicit, deliberate act by the policy author. This is consistent with how we handle default_deny in role-based policies — if we don't know the answer, the answer is no.

Class is authoritative over risk_score — agreed. The precedence rule:

gate = max(gate_from_class, gate_from_risk_score)
Risk can escalate (a reversible action with anomalous risk_score gets a higher gate), but can never downgrade (a low risk_score on an irreversible action still requires approval). Class is a design-time fact; risk is a runtime estimate. Facts outrank estimates.

We'll encode this as:

reversibility_class → floor of the gate (minimum governance required)
risk_score → can only raise the gate above the floor, never lower it
Thanks for the precision on the edge cases — these are exactly the kind of details that prevent governance bypasses in production. Updated the spec to reflect all three.

[Mayur021]

That's the precedence exactly, class as the floor and risk only raising it. Good to see it land in v1.5.

[nagasatish007]

@rpelevin, @@norika1207-lab, @redbotster, @hummbl-dev, @mvanhorn , @CleanDev-Fix Would like your inputs too.

[CleanDev-Fix]

Thanks for inviting input. I did a source-backed pass across the RFC, the
current TypeScript/Python surfaces, the existing policy/event contracts, and
the neighboring policy, identity, telemetry, runtime, and business-action
systems.

My short recommendation is to keep the three-level ADLC vision, but narrow the
v1.5 release commitment to this category:

TealTiger is the open, vendor-neutral action-policy and
verifiable-decision-receipt layer for tool-using agents: deterministic local
enforcement before consequential actions, portable evidence after them.

I would ship v1.5 SDK-first, with an optional small single-tenant control
service off the authorization path. The complete Level 1/2/3 platform is a
strong roadmap, but it combines too many new trust boundaries and enforcement
substrates for one four-month release contract.

1. Priority ranking

P0: release truth and stable cross-language contracts

1. Publish one versioned Action, Decision, Approval, ExecutionReceipt,
   and TargetCapability contract with shared TypeScript/Python conformance
   vectors.
2. Preserve the current external outcome vocabulary: ALLOW, DENY, and
   REFER.
3. Keep reversibility class, required governance gate, enforcement mode, and
   observed enforcement status as separate concepts.
4. Define exact failure behavior for stale policy, invalid signatures,
   approval outages, receipt-store failures, partitions, uncertain provider
   results, and freeze coverage.

P1: one complete Level 1 lifecycle

1. Local deterministic gate with signed, fresh, last-known-good policy.
2. Exact-action approval bound to action hash, policy digest, tenant/resource,
   approver identity, nonce, issue time, and expiry.
3. Re-evaluation immediately before execution.
4. Idempotent execution, reconciliation, and separate compensation semantics.
5. Canonical decision/execution receipts plus an offline verifier.
6. OTel export as a digest-linked projection, not the evidence authority.

P2: prove portability before platform breadth

Use a least-privilege GitHub App as the first proving connector, with native
rulesets, required checks, and branch protection remaining authoritative. Then
prove the same contract on Shopify or another ordinary-business action system
only when a design partner has a real recurring workflow.

I would defer custom eBPF/runtime enforcement, multi-tenant HA, broad compliance
analytics, natural-language policy activation, enforced policy A/B testing,
and a large connector marketplace beyond limited GA.

2. API design

The RFC's high-level API is understandable, but the hard interoperability
contracts need to be explicit.

I would use an internal gate ladder such as
AUTO < AUDIT < REFER < BLOCK, while keeping the public outcome vocabulary
ALLOW/DENY/REFER:

• AUTO satisfied -> ALLOW
• AUDIT satisfied by durable obligations/receipt -> ALLOW; otherwise
  DENY
• REFER without an exact valid approval -> REFER
• REFER with a valid approval -> re-evaluate the same action, then ALLOW if
  every other requirement still passes
• BLOCK -> DENY

An unavailable, expired, rejected, or mismatched approval should remain
REFER and must not execute. Approval satisfies a gate; it never lowers the
floor set by action class, risk, policy, failure state, or freeze state.

The minimum connector interface should cover:

describe -> normalize -> preview -> preflight -> execute -> reconcile -> compensate

Every connector should declare idempotency, reversibility, approval,
precondition, reconciliation, and compensation capabilities. Unsupported
policy mappings should return an explicit capability error rather than silently
approximate. For policy/runtime export, I would report EXACT,
CONSERVATIVE, OBSERVE_ONLY, or UNSUPPORTED.

One important claim boundary: a signed receipt proves the integrity of a
recorded service event. It does not, by itself, prove complete mediation, a
trustworthy producer, personal non-repudiation, or that the external action
actually occurred. Native target-event reconciliation and an explicit bypass
model are still required.

3. Best initial use cases

My current ranking is:

1. GitHub coding-agent merges and workflow dispatches
2. Shopify refunds and order mutations
3. AP/payment-release workflows
4. Support credits, entitlements, and account changes
5. Healthcare administrative routing/submission, much later

The first-buyer hypothesis is a platform or security team at a regulated SaaS,
fintech, or healthtech company running at least two coding-agent runtimes. The
first connector is GitHub because actions are bounded, native evidence is
available, and the deployment burden is relatively low. This validates the
governance plumbing; it does not establish healthcare, finance, privacy, or
consequential-decision compliance.

For ordinary operators, I would make onboarding:

Connect -> choose preset -> observe preview -> review queue -> approve/edit/deny -> preflight -> execute -> receipt or exception

The review queue should say “Merge PR #142 after required checks pass” or
“Refund $245 to Order #7812,” not expose a policy DSL. QuickBooks-style
approval queues are a useful UX reference.

4. Main trade-offs

• Breadth vs. credibility: a narrower lifecycle has a better chance of
  earning trust than a shallow full platform.
• Local enforcement vs. central coordination: keep the control plane off
  the decision path; distribute signed artifacts and report measured rollout
  coverage.
• Availability vs. safety: allow explicit degraded behavior for low-risk
  reads/observation, but fail closed or refer protected side effects.
• One policy language vs. native systems: own a small action-intent model,
  then integrate OPA/Cedar, Kubernetes policy, and runtime systems with
  capability-aware mappings.
• Receipt integrity vs. enforcement completeness: publish both the receipt
  trust model and the known bypass boundary.
• Open source vs. commercial operations: keep the engine, schemas,
  verifier, adapters, policy tests, RBAC/SSO, and self-hostable coordination
  open. Monetize managed hosting/BYOC operations, HA/upgrades/backups,
  retention/search, KMS operations, support/SLA, assurance, and maintained
  mappings.

5. Missing integrations

The smallest proving integration sequence I would build is:

OpenInference/OTel projection -> LiteLLM default-on pre-call hook -> TealTiger -> local OPA -> correlated receipt/span

That can prove a governed denial, portable evidence, and privacy-safe telemetry
without first creating a large partner surface. Generic OIDC and local
Docker/sandbox conformance should come next. Kubernetes VAP can be the first
policy export; Tetragon/Falco should initially be correlation inputs rather than
new TealTiger runtime implementations.

After the reference path passes, publish maintained upstream recipes and
conformance evidence before pursuing partner announcements or marketplaces.
GitHub Marketplace, Shopify App Store, Auth0, Okta, and hosted-sandbox partner
motions should wait until support ownership, privacy/security posture, billing,
and tenant-lifecycle requirements are satisfied. Registry presence should be
described as discoverability, not certification or endorsement.

Suggested four-month release cut

• Alpha: generated contracts/vectors, local observe mode, action registry,
  receipt journal, OTel projection, and GitHub fixtures.
• Beta: enforce mode, signed polling/LKG, exact approval, persistent freeze,
  one OIDC issuer, GitHub test adapter, and VAP export preview.
• Limited GA: single-tenant/single-instance Level 1 parity, minimal control
  service, canonical receipt viewer/verifier, and conformance-tested GitHub
  adapter.

Before privileged adoption, I would require shared cross-language vectors,
approval replay/mismatch/outage tests, artifact tamper/rollback/clock/restart
tests, receipt crash recovery, target freeze coverage measurements, native-event
reconciliation, and separate latency distributions for local evaluation,
journaling, network, approval, and backend work.

Overall, I think the RFC is pointing at a real need. The strongest path is to
make TealTiger the trustworthy interoperability layer that existing agent,
policy, identity, runtime, and observability systems can rely on, rather than
trying to replace all of them in v1.5.