“Does that logo mean the connector works?”
Read product maturity without turning a polished demo or roadmap logo into an implementation claim.
Learn from the procurement surprise →Choose your starting point
What happened that brought you here?
You may be answering a board question, investigating a failed change, reducing review fatigue, preparing for an audit, or simply trying to discover where AI is already working. The same evidence looks different depending on the decision you need to make.
“Where is AI actually working?”
Build a defensible starting inventory without pretending content classifiers can identify every AI contribution.
Learn from the repository inventory scenario →“How do we give a tool access without sharing a password?”
Separate accountable machine access from a person’s browser session—and from the later decision to install instrumentation.
Learn from the copied-token scenario →“We have metrics. What needs us now?”
Turn a crowded dashboard into one evidence-backed next move with a named owner and visible limitations.
Learn from the quarterly operating review →“Are we getting value—or just more output?”
Separate activity, delivery evidence, review evidence, and causal claims before reporting AI ROI.
Learn from the board-value question →“Can we safely review less?”
Use exact change boundaries and represented evidence before making a narrow review decision.
Learn from the mixed-change scenario →“Which exact change needs attention?”
Move from a reassuring aggregate to the failed, unknown, or weakly correlated evidence underneath it.
Learn from the hidden-failure scenario →“What did we actually approve?”
Record scope, owner, expected effect, safety boundary, and evidence identity without claiming enforcement happened.
Learn from the ambiguous approval scenario →“What changed after our decision?”
Compare expected and observed evidence without turning correlation into savings or incidents prevented.
Learn from the forgotten-policy decision →“Can we answer the auditor from evidence?”
Prepare a gap-first report and verifiable handoff without turning readiness into certification.
Learn from the screenshot-folder scenario →“Can we share one package—not the workspace?”
Give a named reviewer focused, expiring access while retaining an honest handoff history.
Learn from the external-auditor scenario →“Could we find this evidence nine months later?”
Distinguish a policy statement from an observed, bounded retrieval result.
Learn from the expired-links scenario →“Who can see which evidence?”
Give each person an explicit Harnexis role and repository boundary instead of sharing one dashboard credential.
Learn from the external-review scenario →No lesson matches that combination yet.
Try a broader role or a simpler problem phrase. This does not mean Harnexis supports the topic.
Read a product maturity claim before depending on it.
A recognizable provider logo can describe a working connector, an early pilot, or only a future direction. Those are materially different buying decisions.
A situation you may recognize
The procurement surprise
A platform team sees GitHub, PagerDuty, Vault, and ServiceNow in a demonstration. The evaluator assumes the four systems can be connected during the pilot. Procurement later learns that GitHub is working and the other three are roadmap. Trust falls even though the future architecture was credible.
The underlying problem
Product vision, mock data, connector availability, and proof of a customer outcome answer different questions. Without a stable vocabulary, every meeting creates another interpretation and the buyer has to reconstruct the truth from qualifiers.
Concept
Available now is deployed inside a stated boundary. Early access is deployed with an intentional operating limitation. Design-partner preview is bounded to an accepted partner engagement. Planned is direction, not usable product. “Illustrative” only says the displayed data is fake.
How to evaluate the claim
- Read the badge adjacent to the capability or integration name.
- Open Scope and boundary before depending on the outcome.
- Check whether the action says use, request access, discuss a preview, or shape a design.
- Put every included capability and any planned work into the statement of work by stable maturity entry.
Current Harnexis example
Working evidence and next proof gaps
The data on the walkthrough is illustrative; these badges describe product maturity.
Loading current capability boundaries.
Example: release proof without release overclaim
Harnexis labels the single observed GitHub Actions-to-Fly founder-staging reference path Early access because accepted main retained it and the product read it back. Its offline-verifiable Release Assurance Package is also Early access for that exact boundary after the accepted CLI verified the unchanged package and rejected appended bytes. The public data remains illustrative, other provider paths do not inherit either label, and a working UI, provider logo, test fixture, or deployment success alone cannot promote a boundary.
Interpretation boundary
Maturity describes whether product behavior is available. It does not prove that your workspace has complete evidence, that a framework applies, or that a customer outcome occurred.
Know where AI is working before trying to govern it.
A company cannot decide what to improve, restrict, or prove when its starting inventory comes from licence counts and developer surveys.
A situation you may recognize
The three-answer meeting
Procurement says 180 people have AI coding licences. A developer survey says 240 people use AI. GitHub shows ordinary human and automation identities merging changes across twelve repositories. The CTO asks, “How much AI-assisted engineering work reached our codebase last month?” Every team gives a different answer because each is measuring a different thing.
The underlying problem
Licences show access. Surveys show reported behavior. Source history shows recorded changes. None of those alone identifies every AI contribution, and code content cannot reliably reveal which model helped write it. A defensible inventory begins with observed evidence and explicit attribution, then preserves what remains unknown.
Concept
Observed AI work is activity connected to represented source evidence such as an enrolled identity, runtime marker, or explicit provenance. Ownership is a separate human confirmation of who is accountable for a defined scope. One must not be silently inferred from the other.
How Harnexis helps today
- Connect selected GitHub repositories through the Harnexis GitHub App.
- Observe merged pull-request history and subsequent merged-PR events.
- Compare repositories and inspect exact AI-work lifecycle evidence.
- Confirm a responsible owner and team for a defined observed scope.
- Keep unknown identity, missing checks, and correlation gaps visible.
Evidence boundary
This is selected GitHub pull-request evidence. It does not represent every AI interaction, autocomplete use, local prompt, hidden subagent, non-GitHub workflow, or organization-wide AI adoption. Harnexis does not claim content-based authorship detection.
Turn evidence into a next move—not another dashboard.
A metric can describe the past and still leave everyone unsure who should act on Monday morning.
A situation you may recognize
Twelve panels, no owner
A VP Engineering enters a quarterly AI review with charts for licences, pull requests, check results, review speed, and spend. The meeting ends with “we should look into ownership.” No person, repository scope, expected effect, or follow-up date is recorded.
The underlying problem
More measures do not automatically produce a decision. A useful operating brief needs to identify one current evidence gap or opportunity, explain why it matters, name who should own the next step, and retain the limitations that could change the conclusion.
Concept
An operating brief is a prioritized, evidence-bounded next-action summary. It is not a composite score and it does not hide missing evidence behind a confident recommendation.
How Harnexis helps today
- Builds Home from the selected repository scope and current canonical projections.
- Shows one next move, why it matters, the expected change, and accountable owner state.
- Places supporting measures and exact evidence behind the conclusion.
- Shows earlier measured follow-through separately from the current recommendation.
Evidence boundary
The brief can prioritize only evidence Harnexis currently represents. It does not infer organization-wide AI usage, assign authority, invent an owner, or translate missing evidence into a clean result.
Separate AI activity from engineering value.
A rising pull-request count and a rising AI bill can occur together without proving that AI caused faster or better delivery.
A situation you may recognize
The board asks the second question
The first slide says AI-assisted pull requests increased. The next says median merge time fell. A board member asks, “Did AI cause that?” The evidence does not control for team changes, release mix, staffing, or process improvements, but the presentation has already implied a return.
The underlying problem
Organizations collapse four different questions: how much activity occurred, what delivery timing was observed, what quality evidence exists, and whether AI caused the result. Honest AI operations keeps those measures separate until the evidence supports a stronger statement.
Concept
Observed impact reports bounded differences and coverage from represented evidence. It is not a productivity score. Causation requires a stronger design than two metrics moving at the same time.
How Harnexis helps today
- Shows observed delivery volume and timing for the selected evidence scope.
- Discloses comparison windows and timing coverage.
- Keeps CI, review, ownership, and correlation gaps visible beside delivery measures.
- Routes the reader to exact changes in Quality & Risk before a broad conclusion.
Evidence boundary
Engineering Impact does not rank developers, calculate hidden productivity, infer unobserved work, value review labor, or claim AI caused a delivery change.
Make review lighter for a precise class—not a vague label.
Review fatigue is real. So is the migration file hidden inside a pull request called “documentation update.”
A situation you may recognize
The ninety-second approval
Senior engineers approve most dependency updates in under two minutes. A platform leader proposes auto-merging “routine maintenance.” During sampling, one change updates a dependency and modifies a production migration. The title looked routine; the actual file surface was not.
The underlying problem
A review decision must be made over a precise, testable scope. Titles, labels, and repository names are insufficient when included paths, excluded paths, mixed changes, final-head approval, checks, ownership, and safeguards determine the real exposure.
Concept
A verified change class is a human-defined inclusion and exclusion boundary previewed against exact observed changes. It is evidence for a later review decision—not permission to change protection automatically.
How Harnexis helps today
- Builds a conservative Review Efficiency brief from represented review, final-head, CI, ownership, and correlation evidence.
- Separates matched, mixed, excluded, and unverifiable changes.
- Lets an authorized user preview a documentation-only starting definition against real observed changes.
- Saves the definition as a draft for later human review.
Control boundary
Harnexis does not modify GitHub rulesets, enable auto-merge, remove required review, or grant agent authority in this workflow. A human must separately review safeguards, measurement, rollback, and enforcement.
Investigate the exact change behind the percentage.
“Ninety-eight percent passed” sounds reassuring until the remaining two percent includes the change you are about to trust.
A situation you may recognize
The green tile and the red commit
A monthly dashboard shows almost every represented check passed. One merged pull request is bound to an exact commit with a represented failing check. Another has no check evidence. A single percentage makes the failed and unknown cases look like the same small remainder.
The underlying problem
Failed, unknown, stale, and weakly correlated evidence require different actions. A useful risk view must preserve each state and let the reader reach the exact change, commit, check, and source reference behind the summary.
Concept
Exact-change evidence binds a source result to the represented repository, pull request, and commit identity. Unknown evidence stays unknown; it cannot be counted as passing or failing.
How Harnexis helps today
- Separates represented passing, failing, unknown, and correlation-needs-review states.
- Prioritizes one exact finding rather than creating an opaque risk score.
- Links the finding to the AI-work lifecycle and canonical evidence filters.
- Routes a response into the existing Decisions & Controls journey.
Evidence boundary
Historical GitHub check evidence does not establish current release readiness, runtime health, production safety, or absence of an incident. A missing response is never interpreted as a clean result.
Record exactly what was decided—and what was not.
“Approved” is dangerous when one person means “review the proposal” and another means “the agent may now act.”
A situation you may recognize
The instruction says “ask first”
An agent debugging a test environment can reach a database using a credential capable of destructive actions. Its instruction file says not to delete data without confirmation. The team treats that prose as a control. After a near miss, nobody can show the actual credential boundary, the action class under discussion, who accepted the exposure, or whether an enforcement point changed.
The underlying problem
Instructions describe expected behavior; credentials define possible behavior. A trustworthy decision needs a named owner, exact scope, proposed effect, safety boundary, measurement window, and stable evidence identity. Recording that decision still does not make an external system enforce it.
Concept
A bounded decision records a human disposition over an evidence-identified proposal. Enforcement is a separate change at the system that controls the action. Conflating them creates false assurance.
How Harnexis helps today
- Presents one evidence-readiness action with owner, reason, expected effect, measurement, and safety boundary.
- Previews an evidence-backed oversight recommendation without applying it.
- Records a formal human acceptance or rejection with rationale and current evidence identity.
- Marks an accepted result “pending enforcement” because no external control change is represented.
Available-now boundary
Harnexis currently records and measures bounded decisions. It does not guarantee runtime prevention of destructive commands, change database credentials, apply GitHub rules, or grant authority. Those outcomes must never be inferred from an accepted review.
Keep the promise and the later evidence side by side.
A decision without a follow-through window becomes organizational folklore: everyone remembers success differently.
A situation you may recognize
The policy change nobody revisited
In June, a team reduces review for a narrow documentation cohort. The expected effect is fewer review decisions without worse represented outcomes. In August, the steering committee remembers that the change “worked,” but cannot reconstruct the original boundary, subsequent cohort, caught failures, or unobserved production impact.
The underlying problem
Expected effects are intentions. Observed effects are later evidence. Both need stable scope and time boundaries. Even when the observed direction is favorable, it may be correlation rather than causation and may omit important outcomes.
Concept
Measured follow-through compares a recorded expectation with later represented evidence while retaining scope, timing, coverage, and limitations. It does not rewrite the original decision.
How Harnexis helps today
- Records the expected effect and measurement window before follow-through.
- Projects subsequent represented changes and evidence movement.
- Shows expected and observed values separately.
- Retains caught failures, missing evidence, and claim boundaries with the result.
Claim boundary
Exposure reduction is not reported as an incident prevented. Approval timing is not review labor saved. A later difference is not automatically caused by the recorded decision.
Answer an auditor from evidence—not a screenshot folder.
The most expensive part of an assurance request is often reconstructing scope, ownership, decisions, gaps, and source references after the fact.
A situation you may recognize
The shared-folder audit
An auditor asks who oversaw AI-assisted changes, which outcomes were represented, what decisions followed, and whether earlier evidence can be retrieved. Engineering, security, and compliance each upload screenshots to a shared folder. The images use different dates and repository scopes, and the final PDF no longer points back to exact records.
The underlying problem
Audit readiness is not a green badge. It is the ability to answer a bounded question, identify the evidence used, show what is missing, preserve the source and version, and hand off the same result without silently changing it.
Concept
An evidence-readiness pack maps maintained questions to shared evidence states: available, partial, missing, not assessed, or customer confirmation required. A verifiable package lets a recipient check the exact signed bytes; it does not decide whether the evidence is legally sufficient.
How Harnexis helps today
- Choose among six maintained engineering-evidence packs and an exact repository scope.
- Inspect question-level status, sources, gaps, and canonical evidence references.
- Download deterministic JSON, standalone HTML, or human-readable PDF.
- Create a signed package containing the canonical HTML, JSON, manifest, and signature.
- Verify a downloaded package as unchanged, changed or incomplete, signer unavailable, or outside current access.
Assurance boundary
Readiness packs do not certify compliance, determine framework applicability, provide legal advice, or replace an auditor. A valid signature proves only that the named signer signed the enclosed bytes and those bytes have not changed.
Share one frozen package—not a changing workspace.
A broad dashboard account exposes too much. An emailed ZIP cannot be revoked and says nothing about whether the recipient used it.
A situation you may recognize
The two-week customer audit
A customer auditor asks for Q3 AI-assisted engineering evidence for one repository. Security can either create an account that sees a live workspace or email a ZIP that may be forwarded, renamed, or opened months later. The review should last two weeks, and the auditor needs a simple way to inspect the report and check its integrity.
The underlying problem
Evidence handoff is an authorization problem as well as a file problem. A useful disclosure should identify the person, exact frozen artifact, repository, purpose, and time window; explain what is excluded; and retain factual access activity without claiming the review is complete.
Concept
An Auditor Review Room is a focused, time-bounded view of one named signed package. Expiry or revocation ends future Harnexis access while preserving the handoff history and original package.
How Harnexis helps today
- An administrator first provisions a named Auditor with an exact repository boundary.
- Evidence & Audit previews the recipient, repository, signed package, disclosed gaps, purpose, expiry, included access, and excluded access.
- The auditor signs in to a focused room and can inspect the frozen report, download the signed package, and verify integrity.
- The administrator sees observed first open, report inspection, download, and verification and can revoke future access.
Sharing boundary
A Review Room does not send email, create public links, expose live evidence, retain evidence under legal hold, record an auditor’s opinion, complete an audit, certify compliance, or establish legal sufficiency. The public walkthrough shows this customer value without publishing Harnexis authorization or anti-bypass mechanics.
Test whether earlier evidence can actually be found.
“We retain evidence for a year” is a policy claim. It is not the same as finding the exact evidence an auditor requests.
A situation you may recognize
Nine months later, every link is stale
Compliance asks for the evidence behind an earlier oversight decision. The policy says twelve months. The original ticket links to a dashboard view that has changed, one source record is unavailable, and nobody recorded the exact date and repository boundary used at the time.
The underlying problem
Retention includes at least two different questions: what period and storage control the customer approved, and what a bounded retrieval check actually returned. Combining them creates a stronger claim than the evidence supports.
Concept
A retrieval manifest records the exact repository and time range checked, represented subjects and references, gaps, and a deterministic digest. It is evidence about that check—not a guarantee about the future.
How Harnexis helps today
- An administrator confirms one provisioned retention option and describes the customer-approved storage control.
- Authorized users inspect current evidence coverage.
- A reviewer, administrator, or auditor runs a bounded date-range retrieval check.
- Harnexis retains the append-only policy history and retrieval manifest.
Legal boundary
A successful retrieval does not prove legal hold, backup restoration, source-system retention, deletion compliance, maximum residency, future availability, or that the selected period is legally sufficient. Legal hold is not available today.
Connect a CLI without copying a browser password or permanent token.
A useful command line needs accountable access, but “paste this shared token into every laptop” creates an invisible credential estate.
A situation you may recognize
The token in three shell-history files
A platform lead shares one long-lived API token so three engineers can try a new tool. Six months later nobody knows which laptops still hold it, which person made a request, or whether removing one employee actually ended access.
The underlying problem
Human authentication and machine access have different lifecycles. A browser can confirm the current person and workspace; each CLI needs its own expiring credential, a visible device label, current authorization boundaries, and independent revocation. That still does not authorize the CLI to modify Git hooks, coding tools, repositories, or CI.
Concept
Enrollment connects one named device to a current product identity. Instrumentation is the separate act of configuring a supported tool or workflow to emit provenance. Treating them as distinct steps makes consent and evidence coverage easier to understand.
How Harnexis helps today
- The authenticated workspace presents platform-matched builds and exact SHA-256 digests.
- The CLI asks the signed-in browser to approve one disclosed device.
- The resulting credential is separate, expiring, follows current Harnexis role and repository access, and can be revoked from the product.
- Offline evidence verification remains usable without signing in.
- Harnexis continues to say “instrumentation not installed” until a supported tool path is configured and observed.
What exact change proof adds
A supported path can make a narrower claim than “AI wrote this code.” It can bind represented tool activity to exact Git commit object identifiers and let an independent verifier classify each commit:
- Verified means trusted signed evidence and independently recomputed commit object identifiers match.
- Modified means the represented contribution remains visible but later represented changes followed.
- Invalid means a required trust, signature, identity, or subject check failed.
- Unknown means the supported path supplied no conclusion. It never means human-only.
Access boundary
The current channel does not claim package-manager delivery, automatic updates, platform notarization, Authenticode, Sigstore, or SLSA provenance. CLI enrollment does not prove AI use, commit authorship, hook installation, or successful evidence collection. Public learning explains the evidence result without exposing hook commands, signing fields, trust construction, or defensive fixtures.
Give each person the evidence they need—not a shared password.
An auditor needs to inspect evidence. A contributor needs to work with it. An administrator needs to manage access. Those are not the same authority.
A situation you may recognize
One login, three responsibilities
An external auditor needs read-only access to one repository. A platform engineer works across three. The CTO wants an all-repository view. The staging dashboard has one shared credential, so every person receives the same access and the activity cannot be attributed to a managed member.
The underlying problem
Evidence access needs an explicit person, role, workspace, and repository boundary. Product authorization should also remain separate from source-system permissions and from agent authority.
Concept
A workspace principal is Harnexis’s current person, role, workspace, repository grants, and entitlements. It is re-resolved on each request so revocation and scope changes take effect without trusting stale browser state.
How Harnexis helps today
- An administrator creates a single-use invitation for a managed member.
- The administrator assigns administrator, contributor, reviewer, or read-only auditor and exact repository grants.
- Role and repository authorization are enforced on the server.
- Successful invitation, access change, and revocation events enter append-only access history.
Access boundary
Harnexis roles control Harnexis only. They do not change GitHub membership, source-system permissions, policy, agent credentials, or agent authority. Public signup, password reset, account recovery, SSO, and SCIM are not available today.
Truth before breadth
What this Learning Center does not present as available today
These areas may matter to customers, but current code does not provide them as complete product workflows. They are intentionally excluded from setup instructions and product claims:
- Guaranteed runtime prevention of destructive commands
- Applied policy or GitHub ruleset enforcement
- Legal hold
- SSO, SAML, OIDC, or SCIM
- GRC delivery integrations
- Public signup and self-service billing
- Password reset or account recovery
- Compliance certification or legal advice