Operational Ontology Framework runtime report

Type: agentic-system-analyses/types/agentic-system-runtime-report.md

Runtime account

The frozen artifact prescribes an operational loop; it does not ship an agent invocation. The boundary is doc-grounded and covers a complete public artifact but only a partial operational loop. This account inspected both READMEs, all five docs/ files, contribution and security policies, CODEOWNERS and the publication workflow under SRC-1. No target, example, CI or experiment was executed. All operational activation and benefit remain unobserved.

It does not publish the implementation used by FSTech or its clients. --- README.md

The consequential work is organizational review with explicit data, governing rules, action authority, evidence and write-back. The shipped entry paths are reading the public reference and its non-executable weekly client-review example. The external Lite/Starter Kit is a link, not a supplied executable entry point (SRC-1, README.md, docs/conceptual-example.md).

Ordinary prescribed invocation

RT-RTE-weekly-review follows the example end to end. A recurring client review is the trigger; a human-supervised organizational process is the principal, but the initiating actor and invocation interface are unspecified. Its input identities are active clients, commitments, deadlines, last confirmed status and a named source of truth. No session IDs, credentials, provider identity or correlation format are defined. The AI prepares a draft using explicit ordering and uncertainty rules; the human reviewer owns accuracy judgments, corrections and permission to proceed. The authorized organization-side process owns write-back. The terminal products are reviewed status, remaining blockers and a short handoff identifying the next review point (SRC-1, docs/conceptual-example.md).

  • overdue commitments appear before future commitments;
  • missing status is labeled for verification rather than inferred;
  • no item is marked complete without recorded confirmation;
  • sensitive or disputed items are escalated to a human. --- docs/conceptual-example.md

These are natural-language decision policies interpreted by the AI and reviewer, not executable selectors. Context packaging, model calls, tool exposure, scheduling and state transfer are unspecified. The four named state artifacts supply intended roles, not published schemas or actual files. This report leaves their revision and read-back mechanisms to the memory analysis. The example only prescribes durable recording and a next-review handoff; it does not demonstrate a later consumer receiving either (SRC-1, README.md, docs/conceptual-example.md).

Authority and forcing cases

The load-bearing human-authority claim is RT-CLM-human-authority; its proposed behavioral channel is RT-BAP-action-authority. Its owner is the organization/human reviewer. The enforcement point in the example is human review before approved write-back, not a middleware guard. Guarantee strength: policy. Covered path: the conceptual weekly-review workflow. Required external contract: authoritative sources, a responsible reviewer, scoped permissions and an authorized writer. Policy conclusion status: claimed. Implementation conclusion status: uninspected. Operation conclusion status: uninspected. No deployed isolation envelope or actual grant set is supplied.

Three source-supported forcing cases bound this conclusion:

  1. Draft-only AI versus later write-back. The AI is explicitly barred from client contact and source updates in this example, yet approved status is later recorded. Thus the document does not forbid all workflow writes; it separates the draft producer from the authorized write-back responsibility. The physical writer and interface are unspecified, so neither an AI write bypass nor enforced technical separation is demonstrated (SRC-1, docs/conceptual-example.md).
  2. Approval versus external execution. The general Action layer includes system calls, internal updates, escalation and blocking, while the example stays draft-only. These broader capabilities are a conceptual surface, not current grants. A direct model call, provider-native tool, host callback, shell, extension, subprocess, remote worker or manual graph override cannot be traced here: no such runtime or supported caller is supplied. Their coverage by authorization checks is unresolved, not universally excluded (SRC-1, docs/dla-model.md, README.md).
  3. Stable internal rules versus revoked authority. Pin-like stability is not supreme authority: the governance text explicitly subordinates internal artifacts to law, security and revoked authorization. RT-RTE-rule-amendment prescribes deliberate human-owned amendment, but no execution-time revalidation, veto API or rollback mechanism is published (SRC-1, docs/governance-principles.md).

The AI prepares a prioritized draft for human review. It does not contact clients or update the source system. --- docs/conceptual-example.md

The approved status and remaining blockers are recorded in the organization's authorized source. A short handoff preserves the next review point. --- docs/conceptual-example.md

These controls are not implemented by Markdown artifacts. If an action can affect a person, system, account, payment or external channel, the public reference alone is insufficient. --- docs/governance-principles.md

Reliability requirements are likewise prescriptions: observable results before completion, escalation on disputed data, and additional idempotency, retry, rollback, audit and emergency-stop controls for implementation. There is no supplied retry loop, recovery state machine or failure trace (SRC-1, docs/governance-principles.md, docs/anti-patterns.md).

Change and the publication side path

Operational knowledge/status admission is part of RT-RTE-weekly-review, with content-specific human confirmation rather than workflow initiation counted as approval. Rule admission is RT-RTE-rule-amendment. Capability or production-machinery change mechanisms are not published; improvement, autonomous rule revision and model training cannot be inferred from write-back. The AI role's model fixity is unresolved in RT-CMP-ai.

The only executable path inspected is RT-RTE-public-surface, repository-publication CI. This corrects an overbroad reading of “no executable agent” as “no executable material.” CI checks reference-file names, file modes, content markers and canonical URL reachability. It neither runs an agent nor evaluates operational-state truth. CODEOWNERS identifies a review owner, but no branch-protection configuration establishes that CI or owner approval blocks merging. A workflow that checks its own tracked contents also does not establish an immutable publication boundary (SRC-1, .github/workflows/public-surface.yml, .github/CODEOWNERS).

Shared records

Components

RT-CMP-ai

Label: AI draft producer

The source-native AI role prepares the weekly draft. Representational form: model internals and exact numerical encoding uninspected; model-assisted natural-language output is prescribed. Storage substrate: provider, weights and runtime memory unspecified. No concrete distributed-parametric component or version is identified. Parameters changing during operation: uninspected; exact version pinning: uninspected; whether a mutable endpoint can resolve to another model: uninspected. These are access limits, not findings of fixed weights or absent learning (SRC-1, README.md, docs/conceptual-example.md).

The AI prepares a prioritized draft for human review. It does not contact clients or update the source system. --- docs/conceptual-example.md

Operative objects

none declared in this member

Routes

RT-RTE-weekly-review

Label: Weekly client review

Endpoints and progression: organizational data and rules → AI draft → human confirmation/correction → authorized source record and short handoff. Owner: organization and human reviewer; physical writer unspecified. Context/state/action effects: prioritized review output, approved status and blockers intended for durable recording; no AI client contact or AI source update in the example. The policy consumes source-native Data/Logic/Action rather than executable rules (SRC-1, docs/conceptual-example.md).

  • Immediate return: Prioritized draft for human review; after approval, updated organizational status and a next-review handoff are prescribed.
  • Later read-back: A handoff is intended to preserve the next review point; actual reload, selection and later use are uninspected because implementation and traces are not supplied.
  • Delegated visibility: The reviewer receives the draft; no sub-agent or worker delegation is described in this example.
  • Selection predicate: Active clients and open commitments; overdue items precede future items; missing status is flagged, and sensitive/disputed items go to a human. Input acquisition is unspecified.
  • Invalidation or expiry: uninspected — no implemented freshness, replacement or expiry mechanism is published for this route.
  • Activation or effect: Human-confirmed status and remaining blockers are prescribed for recording; actual effect and persistence are not demonstrated.
  • Evidence limits: Non-executable example; no model prompt, adapter, storage driver, actual reviewer decision or later session trace.
  • design conclusion status: claimed
  • implementation conclusion status: uninspected
  • operation conclusion status: uninspected

Admission: the AI proposes a draft; the reviewer decides what is accurate, requires correction or may proceed. This gives the reviewer a content-level withholding/correction role, not evidence of a software veto. Operating mode: small recurring human-supervised routine, not a benchmark or bounded curriculum. Improvement trigger: unresolved status, disputed items and review corrections can change the proposed work product; no capacity-improvement loop is specified. Answer oracle: recorded confirmation and source-of-truth information are intended human-review references, but no supplied expected-answer dataset or automated oracle exists in this example. Guidance: the four explicit Logic rules quoted in the runtime account. What persists: approved status, blockers and handoff by prescription. Recovery: correction and escalation are prescribed; rollback, retries and the writing principal remain unspecified. No formulated-theory revision is established by reviewing client status.

The reviewer confirms which items are accurate, which require correction and which may proceed. --- docs/conceptual-example.md

RT-RTE-rule-amendment

Label: Stable rule amendment

Endpoints: existing stable rules → deliberate owner-controlled amendment → future governing rules. Progression and implementation are unspecified beyond ownership and deliberateness. Owner: rule owner, not concretely identified. Context/state/action effect: proposed revisions to rules that should govern later decisions. This is a prescribed instruction-change path, not an implemented self-modification loop (SRC-1, docs/governance-principles.md).

  • Immediate return: uninspected — amendment artifact and approval output are not defined.
  • Later read-back: Revised stable rules are intended to govern subsequent operations; no delivery or reload mechanism is supplied.
  • Delegated visibility: uninspected — no amendment delegation or propagation protocol is defined.
  • Selection predicate: Stable rules requiring deliberate change; proposal trigger and candidate-selection procedure unspecified.
  • Invalidation or expiry: Law, security controls and revoked authorization supersede internal artifacts as policy; mechanical invalidation is unspecified.
  • Activation or effect: Intended change to governing rules; no exercised amendment or resulting behavioral change supplied.
  • Evidence limits: One normative governance rule, without amendment format, decision log, enforcement code or execution trace.
  • design conclusion status: claimed
  • implementation conclusion status: uninspected
  • operation conclusion status: uninspected

Admission: rule ownership and deliberate amendment are required, but proposer, deciding procedure and concrete veto holder are not specified. Human authority is the declared overarching policy; no computational amendment role is established. Operating mode: organizational governance, not a demonstrated optimization process. Answer oracle: uninspected — no reference outcome for deciding amendments is supplied. Trigger and proposed change: amendment of a stable rule, with no specific event or candidate. Rejection and rollback/recovery: uninspected. Guidance shaping proposals: internal rules cannot override law, security or revoked authorization. What persists: stable rule content is intended to persist; revised content and storage are not supplied. This record establishes no formulated theory, criticism or iterative theory-building process.

Stable rules need ownership and a deliberate amendment path. No internal artifact overrides law, security controls or revoked authorization. --- docs/governance-principles.md

RT-RTE-public-surface

Label: Public surface validation

Endpoints and progression: manual dispatch, main-branch push or main-targeted pull request → GitHub-hosted checkout → exact tracked-file/mode checks → content scan → canonical-page requests → CI result. Owner/executor: GitHub Actions job, under repository-maintainer configuration. Representational form: symbolic YAML, Bash and Python predicates on the Git worktree, with network HTTP checks. Context/state/action effects: reads tracked files, writes temporary file lists, emits failures and makes external GET requests; does not update operational state. Runtime permission request: contents: read (SRC-1, .github/workflows/public-surface.yml).

  • Immediate return: Job success/failure and diagnostic output; no supplied result demonstrates a successful run.
  • Later read-back: inapplicable — no agent-consumed durable state update is implemented by this workflow.
  • Delegated visibility: Checkout action and hosted job receive repository contents; remote pages receive HTTP requests, not agent state.
  • Selection predicate: Fixed 14-path allowlist; all tracked files scanned for credential markers; implementation regex applies only to Markdown; three fixed canonical URLs requested.
  • Invalidation or expiry: Each trigger evaluates its checkout; no cached agent state or operational expiry mechanism.
  • Activation or effect: Failing checks exit nonzero; a successful job would only establish those checks, not reference correctness or safety.
  • Evidence limits: Workflow implementation inspected, not executed; branch protections, successful checks, external-page contents and maintainer merge decisions are not supplied.
  • implementation conclusion status: wired
  • operation conclusion status: uninspected

Change admission: maintainers can consider public factual, accessibility and broken-link corrections; unsolicited implementation pull requests are disallowed by contribution policy. Invited contributions require explicit licensing. The workflow provides automated check results, not demonstrated mandatory merge rejection. Proposal source is human contribution; no AI proposal mechanism is supplied. Operating mode: publication validation. Answer oracle: hardcoded path list, mode 100644, credential markers, implementation-like regex and HTTP success responses; none evaluates agent behavior. Trigger: reference changes or explicit dispatch. Guidance: controlled public-reference policy. Persisted result: accepted Git content if maintainers admit it; the workflow itself does not merge. Veto and rollback: maintainer rejection is policy-level; required reviews, rollback and merge protections uninspected. CI guarantee strength: invariant within this inspected script's fixed predicates, not a deployment guarantee. Owner/enforcement: job steps exit on mismatches. Alternate path: Markdown regex does not scan non-Markdown for implementation syntax, though path/mode/credential checks still cover tracked files; untracked files are not publication inputs. A changed workflow or out-of-band publication is outside this script's enforcement, not a demonstrated exploit.

Unsolicited implementation pull requests are not accepted. Any invited contribution requires explicit licensing terms before inclusion. --- CONTRIBUTING.md

      diff -u /tmp/expected-public-files /tmp/tracked-public-files

--- .github/workflows/public-surface.yml

          if path.suffix == ".md" and implementation.search(text):
              errors.append(f"implementation-like content: {path_text}")

--- .github/workflows/public-surface.yml

Claims

RT-CLM-human-authority

Label: Human-controlled action

Claimed operation: drafting, proposing, approving and executing remain distinct, with explicit human authority for high-impact actions. Source: SRC-1, docs/governance-principles.md; the weekly example instantiates the intent with a draft-only AI and reviewer. This is policy, not proof that all possible model/tool paths are mediated. The public artifact does not establish an operational grant set or isolation envelope.

The system must distinguish drafting, proposing, approving and executing. High-impact actions remain under explicit human authority. --- docs/governance-principles.md

Evidenced absences

RT-ABS-agent-entry

Label: Published agent entry

  • conclusion status: absent

Searched boundary: SRC-1 at 3df5d896da2a1e488e1eb325feddf190ad77990d, complete tracked-file listing (git ls-tree -r --name-only HEAD) checked against the boundary's 14-file coverage and publication allowlist; direct inspection of the READMEs, all docs/ files and the workflow. Query: whether any tracked path supplies a target agent entry, provider client or operational-state consumer. The only executable material found is publication CI. The repository explicitly declares no production executable agent and identifies the example as non-executable. Supported conclusion: no shipped agent invocation in this frozen public artifact. Prevented conclusion: how the unpublished implementation invokes models, enforces permissions, persists state or recovers. This absence does not extend to external kits, private delivery or production operation (SRC-1, README.md, docs/conceptual-example.md, .github/workflows/public-surface.yml).

This example is intentionally non-executable. It illustrates the D+L+A separation without defining a production implementation. --- docs/conceptual-example.md

Behavioral-authority paths

RT-BAP-action-authority

Label: Action authority policy

Consumer: intended AI operator and organizational human reviewer. Channel: natural-language Action and governance rules, conceptually reflected in review and authorized write-back. Force: normative policy; no published prompt delivery, authorization middleware or provider enforcement. Horizon: decisions in a routine and intended continuity into the next session through authorized state. Actual behavior depending on the policy is unobserved. SRC-1, docs/dla-model.md, docs/governance-principles.md, docs/conceptual-example.md.

Action authority must be narrower than conversational capability. A model being able to describe an action does not mean it may execute it. --- docs/dla-model.md

Annotations

none