DEV Community: Temitayo

Giving AI Access to Evidence Is Not the Same as Giving It Authority to Publish

Temitayo — Fri, 18 Sep 2026 17:39:38 +0000

Giving AI Access to Evidence Is Not the Same as Giving It Authority to Publish

AI can help a team research, compare, summarize, normalize and draft. None of those capabilities automatically create publication authority.

That distinction sounds obvious, but it becomes easy to blur once an AI system has access to internal repositories, operational telemetry, customer records, incident notes or commercial data.

The system can see something. Therefore the system can talk about it.

That is exactly the assumption a governed publication workflow needs to reject.

Access and authority are different controls

An AI system may have access to a source because it needs that source to perform internal work. That does not mean the source is safe for external use.

A private repository may contain architecture details that are appropriate for engineering review but not public disclosure. An incident timeline may contain useful lessons but also customer information, internal hostnames or security-sensitive details. A performance result may be true but still require context before it becomes a defensible public claim.

So the first rule is simple:

Access answers whether the system can read something. Authority answers whether the system is allowed to publish it.

Those controls should not collapse into one another.

A practical publication control plane

At Tayoca, we structure publication governance around separate stages.

1. Discovery

The system gathers candidate source material.

This can include public documentation, repositories, release artefacts, operational evidence, approved product information and internal sources that may later prove useful.

Discovery is intentionally broad. It is not publication.

2. Verification

The next question is whether a proposed claim is actually supported.

A draft can sound technically plausible and still be wrong. A metric can be real and still be misleading if the measurement period is missing. A repository can contain a feature branch that never shipped. A test result can apply to one environment and not another.

Verification is where the system asks:

What exactly supports this statement?
Is the evidence current?
Does it describe production, staging or a prototype?
Is the wording stronger than the evidence?
Is there contradictory evidence elsewhere?

The output should be traceable back to source material.

3. Disclosure classification

Verified evidence is not automatically public evidence.

The source needs a disclosure classification.

A useful model is:

public verified: already public and suitable for reuse
public sensitive internal: potentially publishable, but requires redaction or review
private restricted: not publishable by default
private sensitive: requires explicit handling and should remain fail-closed

This stage prevents a common failure mode: treating truth as sufficient justification for disclosure.

Something can be true and still be inappropriate to publish.

4. Human approval

Material public claims need a human decision.

The approval should cover the actual claim, not merely the topic.

For example, approving an article about Kubernetes production readiness does not automatically approve every internal reliability metric the drafting system can find.

Human approval should answer:

Is the claim proportionate to the evidence?
Is the source safe to disclose?
Is the wording accurate?
Does the asset reveal anything it should not?
Is the call to action appropriate?
Is publication authorized for this specific channel?

This is where accountability stays anchored to a person rather than disappearing into a model workflow.

5. Publication

Only approved material moves into distribution.

At this point the system can adapt format and presentation for the destination, but adaptation should not introduce new facts.

That means a LinkedIn post, DEV article, newsletter summary and short-form caption can differ in structure while sharing the same approved evidence boundary.

Channel adaptation is allowed.

Claim invention is not.

6. Correction

A correction should create history, not erase it.

If evidence changes, a source is superseded or a claim turns out to be overstated, the system should preserve the previous state and record the revision.

That matters for two reasons.

First, it makes the editorial process auditable.

Second, it prevents an AI workflow from silently rewriting the past and making it impossible to understand why a public claim changed.

Why the LLM should not be the final authority

Large language models are useful interpreters. They are poor substitutes for explicit governance.

An LLM can:

summarize multiple sources
detect contradictions
compare versions
propose redactions
draft channel-specific copy
identify missing evidence
flag potentially sensitive language

But it should not be allowed to convert a blocked source into an approved claim simply because the resulting sentence sounds reasonable.

It should also not become the executor of operational or reputational decisions without a separate control boundary.

The distinction is similar to production automation.

A system can generate a remediation recommendation without being allowed to execute it. A system can draft a public claim without being allowed to publish it.

The useful pattern is assistance with bounded authority.

A simple implementation model

You do not need a giant governance platform to start.

A workable implementation can use a ledger with fields such as:

source
fact
evidence
audience
disclosure classification
redaction requirements
approval state
draft eligibility
distribution status
revision
superseded record

Then enforce a few rules:

Restricted sources cannot automatically become public drafts.
Draft approval and distribution approval are separate.
Every material claim retains an evidence reference.
Channel adaptation cannot add unsupported facts.
Corrections create a new revision rather than silently overwriting history.
Publication fails closed when disclosure status is unresolved.

That is enough to move from "AI writes posts" to an actual controlled publication system.

The point is not to slow AI down

Governance is often framed as friction.

In practice, clear boundaries can make an AI workflow more useful because the system knows where it is allowed to move quickly and where it must stop.

Research can be fast.

Comparison can be fast.

Drafting can be fast.

Publication of sensitive or material claims should be deliberate.

The principle is straightforward:

AI can assist with evidence. It does not inherit authority simply because it can access the evidence.

Tayoca's public trust policy describes this operating boundary in more detail:

https://tayoca.com/trust.html

Production Readiness Is Easier to Inspect Than to Debate

Temitayo — Fri, 18 Sep 2026 17:39:35 +0000

Production Readiness Is Easier to Inspect Than to Debate

Teams often describe a Kubernetes environment as "production ready" without agreeing on what that means.

That makes readiness surprisingly difficult to discuss.

One person is thinking about redundancy.

Another is thinking about security.

Another is thinking about observability.

Another is simply thinking, "the application is running in the production cluster."

A checklist is useful because it turns the argument into inspection.

Production ready is not a binary feature

Kubernetes itself does not make a workload production ready.

A cluster can be healthy while an application has no tested restore path.

A Deployment can have multiple replicas while all replicas depend on the same failure domain.

A service can have dashboards while nobody knows which alert requires action.

A GitOps controller can report synchronization while the rollback process remains unclear.

So production readiness is better treated as a set of operating conditions than as a label.

Start with failure

One of the fastest ways to test readiness is to stop asking how the happy path works.

Ask what happens when something fails.

For example:

What happens when a node disappears?
What happens when a zone becomes unavailable?
What happens when DNS is unhealthy?
What happens when the database cannot be reached?
What happens when a deployment introduces a bad configuration?
What happens when credentials expire?
What happens when a persistent volume cannot attach?
What happens when an operator is unavailable during an incident?

The point is not to predict every possible failure.

The point is to make important failure behavior explicit before production pressure arrives.

A useful inspection model

A production-readiness review can be grouped into several control areas.

Workload resilience

Check whether the workload has meaningful redundancy.

Questions include:

Are replica counts intentional?
Are PodDisruptionBudgets appropriate?
Do topology constraints prevent all replicas from landing in one failure domain?
Are probes testing meaningful application behavior?
Does the application tolerate dependency failure?
Are termination and shutdown behaviors safe?

A three-replica Deployment is not automatically resilient if all three replicas share the same failure path.

Resource behavior

CPU and memory configuration should be deliberate.

Inspect:

requests
limits
observed utilization
throttling
OOM events
autoscaling behavior
burst requirements

Poorly selected requests can waste capacity.

Poorly selected limits can create instability.

The goal is not to maximize utilization. It is to make resource behavior predictable enough to operate safely.

Deployment safety

A production deployment process should answer:

How is a change promoted?
What evidence is required?
Can the change be rolled back?
How quickly can rollback happen?
Are database migrations compatible with rollback?
Can deployment drift be detected?
Who owns a failed release?

GitOps can make state traceable, but it does not replace these operating decisions.

Observability

A system is difficult to operate if the team cannot distinguish symptoms from causes.

Readiness includes:

application metrics
platform metrics
logs
traces where appropriate
alert routing
useful dashboards
service ownership
dependency visibility

The question is not "Do we have Prometheus?"

The question is "Can an operator use the available evidence to make a correct decision during an incident?"

Recovery

Backup configuration is not the same as recovery capability.

Inspect:

backup frequency
restore testing
recovery point objective
recovery time objective
storage dependencies
database replication
secret recovery
external service dependencies
documented failover behavior

A backup that has never been restored is an assumption.

Security and access

Readiness also includes the controls that limit blast radius.

Examples:

RBAC
workload identity
secret management
network policy
image provenance
admission controls
Pod Security settings
privileged workload review
auditability

The exact controls depend on the environment, but the principle is consistent: production access should be intentional and reviewable.

Ownership and operations

Many production failures are not caused by Kubernetes configuration.

They are caused by ambiguity.

A readiness review should identify:

service owner
escalation path
runbook location
dependency owner
deployment owner
recovery decision-maker
maintenance expectations
after-hours responsibility

Technology can automate many operations.

It cannot compensate for unclear ownership.

Make the result scoreable, but do not worship the score

A scored checklist can be useful because it makes gaps visible and allows teams to track progress.

But a score should not become a substitute for engineering judgment.

Some controls are more important than others.

A missing label is not equivalent to an untested database restore.

A useful readiness system therefore combines:

control status
evidence
severity
ownership
remediation state

The value is not the number itself.

The value is that the team can see what is missing and why it matters.

Readiness should be repeatable

A one-time production review ages quickly.

Clusters change.

Dependencies change.

Applications change.

Teams change.

A stronger model treats readiness as a repeatable inspection that can be revisited before major releases, after architecture changes and periodically for critical services.

That is where automation helps.

Controls that can be checked mechanically should be automated.

Controls that require judgment should remain explicit human review points.

The deeper lesson

Production readiness is easier to inspect than to debate.

Turn the claim into observable conditions.

Collect evidence.

Record gaps.

Assign ownership.

Retest after remediation.

Tayoca's Kubernetes Production Readiness package was built around this discipline, with a 150-control dataset, scored tracker and supporting release artefacts.

The goal is not to turn engineering into paperwork.

The goal is to make operational confidence traceable.

Technology Value Starts With an Explicit Operating Problem

Temitayo — Fri, 18 Sep 2026 17:39:33 +0000

Technology Value Starts With an Explicit Operating Problem

Technology is not valuable because it is complicated.

It is valuable when the operating problem, evidence and expected outcome are explicit.

That sounds simple, but many technology programmes still begin in the opposite direction.

"We need Kubernetes."

"We need an AI agent."

"We need FinOps."

"We need a new platform."

Those statements describe possible implementation choices. They do not yet describe the operating problem.

Start with the condition that needs to change

A useful engineering engagement should answer four questions early:

What problem is expensive, risky or operationally limiting?
What evidence proves that the problem exists?
What is the smallest useful intervention?
How will we know whether the intervention worked?

This changes the order of operations.

Instead of starting with a product category, the team starts with an observable condition.

Instead of assuming that a larger architecture is more mature, the team defines acceptance criteria.

Instead of treating measurement as a reporting task at the end, measurement becomes part of the implementation.

Example: FinOps

"Cloud costs are high" is not specific enough to drive a safe optimization programme.

Useful questions include:

Which workloads account for the increase?
Is the cost growth expected or anomalous?
Are CPU and memory requests materially above observed usage?
Are idle workloads or unattached resources present?
Is storage growth justified by retention requirements?
Are managed services expensive because of utilization, topology or pricing model?
Which recommendations can be applied safely?
Which changes require explicit approval?

Now the intervention can be evidence-based.

The team might discover that one workload is over-requested, a development environment runs continuously, or storage classes are poorly matched to workload behavior.

The goal is not "do FinOps."

The goal is to change a specific cost condition without introducing unacceptable reliability risk.

Example: platform reliability

"We need Kubernetes" is also not a reliability objective.

A useful reliability problem might be:

releases are difficult to roll back
workloads have no tested recovery path
deployment ownership is unclear
incidents take too long to diagnose
environment drift is common
secrets are handled inconsistently
application teams cannot see platform health
recovery objectives are undocumented

Kubernetes may be part of the solution.

It may also add complexity if the operating model is not ready for it.

The engineering question is therefore not "Should we use Kubernetes?"

It is:

What reliability condition are we trying to improve, and what platform capability is required to improve it?

That framing leads naturally to acceptance criteria.

For example:

deployment rollback completes within an agreed process
backups are tested rather than merely configured
service ownership is explicit
alerts map to actionable conditions
production dependencies are observable
configuration drift is detectable

Now the platform has a job to do.

Example: governed automation

"We need an AI agent" is one of the most common modern versions of tool-first thinking.

A better starting point is to identify the decision or workflow bottleneck.

Perhaps operators spend hours gathering evidence before a routine change.

Perhaps a support team repeatedly classifies the same type of request.

Perhaps an SRE has to inspect five systems before deciding whether an alert is real.

The useful questions become:

What input evidence is required?
Which decisions are deterministic?
Which decisions need human judgment?
What actions are reversible?
What actions are high impact?
What must be logged?
What should fail closed?
What is the acceptance criterion for automation?

An AI system can then be given bounded authority.

For example, it may collect evidence, propose a remediation and prepare an approval packet without being allowed to execute the remediation.

That is a much more precise system than "build an autonomous agent."

The smallest useful intervention

There is a strong temptation to solve a real problem with the largest architecture that can be justified.

A better principle is:

Implement the smallest intervention that can produce the required operating change.

That might mean:

changing one deployment policy instead of replacing the delivery platform
adding recovery testing instead of buying another backup product
introducing a rightsizing review instead of building a full cost platform
automating evidence collection instead of automating the final decision
fixing an ownership boundary instead of adding another dashboard

Small interventions are easier to verify.

They also make failure easier to understand because fewer variables change at once.

Evidence belongs inside the implementation

The acceptance criteria should not live only in a proposal document.

If the objective is lower recovery time, measure recovery behavior.

If the objective is lower cost, establish the baseline and measurement method before the change.

If the objective is safer automation, record which actions require approval and verify that the system cannot bypass them.

If the objective is production readiness, make the readiness controls inspectable.

Evidence is not paperwork after delivery.

It is part of the engineering system.

A reusable operating model

The pattern can be summarized as:

Diagnose. Establish evidence. Bound the intervention. Implement. Verify.

Each step protects against a different failure mode.

Diagnose

Prevents the team from solving the wrong problem.

Establish evidence

Prevents vague assumptions from becoming architecture.

Bound the intervention

Prevents unnecessary complexity.

Implement

Changes the operating condition.

Verify

Prevents completion from being confused with outcome.

That model works across platform engineering, reliability, FinOps and governed automation because it is not tied to a specific technology.

Technology should earn its complexity

Complex systems are sometimes necessary.

But complexity should be justified by the problem being solved.

The goal is not to make technology look sophisticated.

The goal is to make an operating problem measurably better.

Tayoca's assessment framework is built around this model:

https://tayoca.com/assessments.html