2026 08 20 aws coa governance latency contextual debt

Governance latency and contextual debt in AWS Context Ontology Accelerator pipelines

Research Question

To what extent does the human-in-the-loop governance requirement in the Amazon Web Services (AWS) Context Ontology Accelerator (COA) workflow exacerbate the stability-plasticity dilemma for agents consuming high-velocity, unstructured data, and does the latency introduced by manual World Wide Web Consortium (W3C) Web Ontology Language (OWL) and Shapes Constraint Language (SHACL) verification create contextual debt that prevents the Model Context Protocol (MCP) from representing real-time environmental mutations?

Scope

In scope:

AWS Context Ontology Accelerator-style workflows that combine ontology induction, human review, and agent-serving layers
Human-in-the-loop latency introduced by ontology validation, approval, or standards-conformance checks
Whether governance-induced delay creates stale or partially-updated context for downstream agents
The relationship between ontology-governance cadence and the stability-plasticity trade-off in mutable environments
Whether MCP-mediated context serving can reflect high-frequency changes when ontology promotion is gated manually

Out of scope:

General AWS service comparison unrelated to ontology-governance workflows
Building a new ontology or a new AgentCore implementation in this repository
Pure vector Retrieval-Augmented Generation (RAG) designs that do not include an ontology-governance layer

Constraints: Prioritise 2024-2026 AWS documentation, ontology-governance standards, and recent agent-memory literature. Distinguish clearly between documented workflow latency, inferred architectural risk, and speculative claims about real-time failure thresholds.

Context

The July 2026 AWS AgentCore knowledge-context-layer item established the main AWS-native building blocks for governed ontology-backed agent memory, but it did not isolate the cost of manual review inside the ontology-update path. This item asks whether that governance step becomes the dominant bottleneck once the environment changes faster than ontology curators can validate and promote updates, which would directly affect decisions about where to place human review in a production memory architecture.

Approach

Reconstruct the COA workflow stages: extraction, ontology proposal, standards validation, human approval, and serving to agents.
Identify where OWL/SHACL verification and manual review introduce queueing delay, and whether those delays are measured or only described qualitatively.
Compare that delay against the update cadence assumed by MCP-mediated context serving and agent memory refresh.
Investigate whether prior work on stability-plasticity, truth maintenance, or knowledge curation provides a threshold model for when governance lag becomes contextual debt.
Synthesize design guidance on when human review should move from inline gate to asynchronous audit, exception handling, or sampled control.

Sources

Research Skill Output

(Full output from running the research skill, retained verbatim in the completed item. §§0–5 are the investigation; §6 seeds the Findings section below.)

§0 Initialise

Research question, restated: To what extent does the human-in-the-loop governance step in the AWS Context Ontology Accelerator (COA) workflow worsen the stability-plasticity dilemma, the continual-learning tradeoff between retaining prior knowledge (stability) and rapidly absorbing new information (plasticity), for agents consuming fast-changing, unstructured data, and does the delay from manual World Wide Web Consortium (W3C) Web Ontology Language (OWL) and Shapes Constraint Language (SHACL) verification create what this item calls "contextual debt", meaning a growing gap between what an agent's served context reflects and what the source environment currently is, that prevents the Model Context Protocol (MCP) from surfacing real-time environmental change to agents.

Definition needed: "contextual debt" is not a standardized academic or industry term with one agreed definition. The closest documented adjacent concept in current agent and Large Language Model (LLM) literature is "context debt", which the emergentmind glossary defines as token-level redundancy inside a single context window, a different phenomenon from the cross-session knowledge-staleness gap this item investigates. [inference; source: https://www.emergentmind.com/topics/context-debt] This item treats "contextual debt" as its own working label for the latter phenomenon and evaluates it functionally, as the interval during which a served knowledge graph diverges from the current state of the environment it models, rather than treating the label as an established term of art.

Scope confirmed: in-scope is the COA Scan-to-Model-to-Serve pipeline's governance step, the latency it introduces, whether that latency creates stale or partially updated context, and whether MCP-mediated serving can reflect high-frequency source changes when ontology promotion is gated by a human. Out of scope is general AWS service comparison, building a new ontology, and pure vector-based Retrieval-Augmented Generation (RAG) designs without an ontology-governance layer, per the item's Scope section.

Constraints confirmed: prioritise 2024 to 2026 AWS documentation, ontology-governance standards, and recent agent-memory literature, and separate documented workflow latency from inferred architectural risk and from speculative real-time failure-threshold claims, per the item's Constraints field.

Prior-research cross-reference: four completed items are cited in this item's frontmatter and are used as evidence below. 2026-07-20 AWS AgentCore and AWS-native Knowledge Context Layer established that AWS's managed Bedrock GraphRAG feature is narrow (Amazon Simple Storage Service (S3) only, no custom graph-build configuration) and that Neptune itself has no native OWL reasoning engine, which is the gap COA's own ontology-engine package is built to fill. [fact; source: https://davidamitchell.github.io/Research/research/2026-07-20-aws-agentcore-knowledge-context-layer.html] 2026-07-20 TBox-driven vs ABox-emergent ontology approaches in GraphRAG systems found that a predefined schema (TBox) improves noisy-data robustness relative to schema-free extraction, which bears on why COA gates ontology changes through explicit review rather than accepting continuous schema-free extraction. [fact; source: https://davidamitchell.github.io/Research/research/2026-07-20-tbox-abox-graphrag.html] 2026-07-20 Hybrid memory integration found that write-through synchronization into structured memory is materially less mature than read-through retrieval and that the strongest systems stage validation and conflict handling outside the generator rather than committing facts autonomously, which is the same architectural pattern COA implements at the ontology layer. [fact; source: https://davidamitchell.github.io/Research/research/2026-07-20-hybrid-memory-integration-ontology-llm-weights.html] 2026-04-26 Human-in-the-loop AI automated workflows established general design guidance on review-latency thresholds and reviewer vigilance that is applied to COA specifically in §5 and Analysis below. [fact; source: https://davidamitchell.github.io/Research/research/2026-04-26-human-in-the-loop-ai-automated-workflows.html]

§1 Question Decomposition

What are the actual pipeline stages of COA, and where does human review sit relative to automated (OWL/SHACL) validation? 1.1 What does the Scan, Model, and Serve lifecycle consist of at the component level? 1.2 Is ontology promotion gated by a single combined validation-plus-approval step, or are automated conformance checking and human approval separate, independently timed stages?
Where, specifically, does governance-induced delay occur, and is it measured? 2.1 What is the documented latency of the automated proposal-accept pipeline once a human approves it? 2.2 Is there any documented or measurable bound on how long the human review step itself takes, independent of the automated accept pipeline? 2.3 Does an unreviewed proposal block or merely delay subsequent ingestion of newer source data in the same namespace?
Does governance latency create contextual debt, that is, a growing gap between served context and current environment state? 3.1 Can agents query or otherwise observe data from a pending, unaccepted proposal, or only from the already-accepted graph? 3.2 Does the MCP serving layer implement any push-style update mechanism that could narrow this gap, and does COA's own MCP server use it?
Does prior work on stability-plasticity, truth maintenance, or knowledge-curation governance provide a threshold model for when governance lag becomes contextual debt? 4.1 What does the stability-plasticity dilemma literature say about the cost of excess stability versus excess plasticity? 4.2 What does this repository's prior human-in-the-loop research say about calibrating review latency and preventing reviewer vigilance decay?
What design guidance follows for when human review should move from an inline gate to asynchronous audit, exception handling, or sampled control?

§2 Investigation

1.1 / 1.2 Pipeline stages and where review sits. [fact] COA is an open-source, Apache 2.0-licensed accelerator that AWS announced as generally available in July 2026, combining a Neptune knowledge graph, OWL/Turtle ontologies (Turtle, or Terse RDF Triple Language, is a W3C-standardised plain-text syntax for writing Resource Description Framework triples), and rule-based systems with generative AI, following a Scan, Model, Serve lifecycle: Scan connects structured and unstructured data sources and enriches metadata, Model induces an ontology that domain experts review and approve into a unified knowledge graph, and Serve exposes that graph to agents through MCP. [fact; source: https://aws.amazon.com/about-aws/whats-new/2026/07/aws-context--ontology-accelarator-generally-available/; https://github.com/aws/context-ontology-accelerator; https://www.w3.org/TR/turtle/] The Model stage is implemented by the ontology-engine package, which runs automated induction (a table_to_ontology embedding-matching strategy for structured schemas, and a rigor_ontology Retrieval-Augmented Generation-of-ontologies strategy implementing Nayyeri et al.'s 2025 method, which alternates a generator Large Language Model (LLM) and a judge LLM per table in foreign-key topological order) and stores the result as an OntologyProposals record rather than writing directly into the served graph. [fact; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md; https://arxiv.org/abs/2506.01232] A domain expert reviews that proposal and must call POST /ontology/proposals/{id}/accept before its content enters the graph agents query; this accept call is the single governance gate for both the structured and unstructured induction paths, described in the package as "the existing, source-type-agnostic proposal endpoint." [fact; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md]

Automated conformance validation and human approval are architecturally separate steps, but they are not both wired in for every induction path as of this release. [fact] The package includes a three-tier validation subsystem (an OWL 2 DL reasoner, HermiT, for logical consistency checking; OntoQA, a metrics-based schema and instance quality framework from Tartir et al.'s 2005 paper; and OOPS!, the OntOlogy Pitfall Scanner, a modeling-pitfall detector from the Ontology Engineering Group) that is distinct from the human accept decision. [fact; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md; http://www.hermit-reasoner.com; https://corescholar.libraries.wright.edu/knoesis/660/; https://oops.linkeddata.es/advanced.jsp] For the unstructured, document-derived induction path specifically, the package documentation states explicitly that this validation subsystem "is not invoked, so proposals are stored without conformance checks," listed as one of four known v0 gaps rather than a bug. [fact; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md] This gap means the research question's premise, that governance latency is driven by manual OWL/SHACL verification, does not match the unstructured induction path in this release: the documented gate there is unassisted human review of an unvalidated proposal rather than human review of a machine-validated one, a distinction that changes both the nature and the likely duration of the bottleneck. [inference; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md] Whether the structured induction path (table_to_ontology and rigor_ontology) routes its proposals through the HermiT/OntoQA/OOPS! tiers before presenting them for human accept is not stated in the consulted package documentation, and the public repository does not expose Shapes Constraint Language (SHACL) shape files or a SHACL validation call in the paths inspected; the only automated conformance mechanism found by name is the OWL-reasoner-based tier. [assumption; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md] A shapes/ directory exists under the package's validation/ module per the GitHub contents Application Programming Interface (API), but its file-level contents were not fetched in this session, so its use of SHACL specifically remains unconfirmed rather than ruled out. [assumption; source: https://api.github.com/repos/aws/context-ontology-accelerator/contents/packages/ontology-engine/src/coa_ontology/validation]

2.1 Documented automated-pipeline latency. [fact] The accept pipeline's engineering behaviour is fully documented in source comments: calling accept flips the proposal's status to accepting, starts the merge (catalog projection, Turtle bulk load into the graph store, embedding accumulation, Amazon Simple Storage Service (S3) persistence) on a background thread, and returns a HyperText Transfer Protocol (HTTP) 202 status immediately; the merge work itself "can take 30 to 60 seconds," which the code states exceeds Amazon API Gateway's 29-second integration timeout and is the documented reason the accept step must run asynchronously. [fact; source: https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py] This 30-to-60-second figure measures only the automated post-approval merge, not the time a human spends reviewing and deciding on the proposal beforehand; the two are distinct latencies and only the first is documented with a number. [inference; source: https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py]

2.2 Human review-step duration. Search note: queries for published benchmarks, case studies, or blog posts quantifying real-world domain-expert review or approval turnaround time for COA ontology proposals (search terms including "Context Ontology Accelerator review time", "COA proposal approval latency", and "AWS ontology accelerator human review SLA") returned no results specific to this product. [fact] No consulted source, AWS-authored or independent, states a measured or targeted duration for the human review step itself, distinct from the 30-to-60-second automated accept pipeline in §2.1. [fact; source: https://github.com/aws/context-ontology-accelerator; https://aws.amazon.com/about-aws/whats-new/2026/07/aws-context--ontology-accelarator-generally-available/] Given that AWS announced general availability in July 2026, one month before this research was conducted, the absence of published review-latency data is consistent with an early-adoption information gap rather than with evidence that COA review is fast; the recency of the product materially limits what independent operational evidence can exist yet. [inference; source: https://aws.amazon.com/about-aws/whats-new/2026/07/aws-context--ontology-accelarator-generally-available/]

2.3 Blocking versus delay. [fact] The proposal module implements an explicit "in-flight guard": while a proposal in a namespace is pending, updated, or accept_failed (unreviewed or failed work), or accepting/embeddings_sync (an accept actively merging), starting a new induction job in that same namespace is blocked, so a second source scan cannot even begin, let alone merge, until the outstanding proposal is resolved. [fact; source: https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py] This is a hard block on new induction, not merely a queued delay of the same-cycle proposal, which means one slow or neglected review can stall ingestion of subsequently arrived source changes in that namespace entirely, rather than only delaying the specific batch of data that produced the pending proposal. [inference; source: https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py]

3.1 Visibility of pending proposals to agents. [fact] The Serve layer's tiered query resolution (a no-Large-Language-Model metric-match tier, a natural-language-to-SPARQL Protocol and Resource Description Framework (RDF) Query Language (SPARQL, the W3C-standardised query language for RDF graphs) or Structured Query Language (SQL) tier routed through a Virtual Knowledge Graph, and an agentic retrieval tier for unmapped classes) executes exclusively against the materialized Neptune graph, which by construction contains only content that has passed through an accepted proposal. [fact; source: https://clawaws.com/blog/context-ontology-accelerator-agent-graph-context/; https://www.w3.org/TR/sparql11-query/] No mechanism for querying an in-review or provisional proposal was found in the consulted MCP tool set (list_metrics, describe_schema, query, translate_sparql, rag_retrieval, graph_traversal), all of which operate against the accepted graph or the backend services fronting it. [fact; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/mcp-server/README.md] Combining the accept-gate finding in §2 with this Serve-layer finding, an environmental change captured by Scan is invisible to any agent until a human completes the accept decision for that batch, with no documented partial or provisional visibility path in between. [inference; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md; https://clawaws.com/blog/context-ontology-accelerator-agent-graph-context/]

3.2 MCP's capacity for push updates versus COA's use of it. [fact] The Model Context Protocol specification defines optional server capabilities, subscribe and listChanged, that let a server notify a connected client when an individual resource changes or when the list of available resources changes, so the protocol itself is capable of representing live mutations when a server implements these capabilities. [fact; source: https://modelcontextprotocol.io/specification/2025-06-18/server/resources] COA's own mcp-server package documentation lists six tools, all invoked by the calling agent (list_metrics, describe_schema, query, translate_sparql, rag_retrieval, graph_traversal), and does not mention implementing the resources capability, subscribe, or listChanged; the documented interaction model is agent-initiated tool calls against the Context Manager, not server-pushed resource-change notifications. [fact; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/mcp-server/README.md] The constraint on real-time representation in COA is therefore attributable to an implementation choice not to use MCP's available push mechanism, combined with the accept-gated Serve layer in §3.1, rather than to a limitation of the Model Context Protocol as a specification. [inference; source: https://modelcontextprotocol.io/specification/2025-06-18/server/resources; https://github.com/aws/context-ontology-accelerator/blob/main/packages/mcp-server/README.md]

4.1 Stability-plasticity dilemma. [fact] The stability-plasticity dilemma is an established concept in continual-learning research describing the tradeoff between a system's stability, its ability to retain previously learned knowledge, and its plasticity, its ability to integrate new information; a system biased too far toward plasticity suffers catastrophic forgetting, while a system biased too far toward stability fails to incorporate new information at all. [fact; source: https://arxiv.org/abs/2403.05175; https://en.wikipedia.org/wiki/Catastrophic_interference] COA's mandatory accept gate is a stability-maximizing design choice at the ontology layer: it is architecturally impossible for a proposal to alter the served graph without a human decision, which prevents any form of automated catastrophic forgetting or silent drift of the ontology, at the documented cost that the graph cannot incorporate new structure faster than that human decision is made. [inference; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md; https://arxiv.org/abs/2403.05175]

4.2 Prior human-in-the-loop governance research applied to COA. [inference] This repository's prior human-in-the-loop research found that response-time expectations for human review should be derived from the reversibility and criticality of the action under review rather than one fixed enterprise-wide target, and that the default behaviour while review is pending should be to hold rather than silently continue. [inference; source: https://davidamitchell.github.io/Research/research/2026-04-26-human-in-the-loop-ai-automated-workflows.html] COA's in-flight guard already implements a hold-by-default behaviour at the namespace level, blocking new induction rather than allowing unreviewed or partially reviewed content to reach agents, which matches that prior guidance's preferred failure mode even though COA applies it uniformly rather than calibrating it to the reversibility of any specific ontology change. [inference; source: https://davidamitchell.github.io/Research/research/2026-04-26-human-in-the-loop-ai-automated-workflows.html; https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py] That same prior item found that large review queues predictably erode reviewer vigilance, increasing the risk of approval-by-exception or perfunctory sign-off once review volume outpaces reviewer capacity. [inference; source: https://davidamitchell.github.io/Research/research/2026-04-26-human-in-the-loop-ai-automated-workflows.html] No source consulted in this item measures whether COA's own review queues have reached, or are likely to reach, volumes at which this vigilance-decay effect would apply, so the mechanism is transferable in principle but unverified in COA's specific deployment context. [assumption; source: https://davidamitchell.github.io/Research/research/2026-04-26-human-in-the-loop-ai-automated-workflows.html]

§3 Reasoning

The research question conflates two claims that the evidence separates: that manual OWL/SHACL verification specifically causes governance delay, and that human review in general causes governance delay. [inference; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md] The evidence in §2 supports the second claim directly and complicates the first: for the unstructured induction path, there is no automated OWL/SHACL verification step at all in this release, so the entire governance latency in that path is unassisted human review time, which is undocumented in duration. [inference; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md] The one governance-adjacent latency that is documented with a number, the 30-to-60-second post-approval merge, occurs after the human decision, not instead of it, so it cannot be the source of any pre-approval delay the research question is concerned with. [fact; source: https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py]

The contextual-debt mechanism the research question asks about is real and independently verifiable from architecture alone, without needing a measured review-time figure: because the in-flight guard blocks new induction while any proposal in a namespace is unresolved, and because Serve exclusively queries the accepted graph with no provisional-visibility path, the size of the gap between served context and current environment state is bounded below by however long the slowest pending proposal in a namespace takes to resolve, and that bound compounds across every unresolved proposal in sequence because a second scan cannot start until the first is resolved. [inference; source: https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py; https://clawaws.com/blog/context-ontology-accelerator-agent-graph-context/] This makes the review-latency distribution, not the automated pipeline latency, the dominant variable in how much contextual debt accumulates, and that distribution is exactly the piece no consulted source measures. [inference; source: https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py]

§4 Consistency Check

contradiction_scan: resolved
finding: research question's framing (manual OWL/SHACL verification as the delay source) does not match the unstructured induction path, where no automated validation runs at all; reframed in §3 as unassisted human review being the actual gate for that path
confidence_adjustment: architectural claims (accept gate, in-flight guard, tiered serve, MCP tool list) held at fact/high; review-duration and vigilance-decay claims held at inference/assumption and low-to-medium confidence given the absence of measured data
scope_guardrail: maintained; no claim made about structured-path SHACL validation timing beyond what the package documentation states, and the unconfirmed shapes/ directory contents are flagged as an assumption rather than asserted

§5 Depth and Breadth Expansion

Technical lens. The RIGOR (Retrieval-augmented Iterative Generation of RDB Ontologies) induction strategy's generator-then-judge LLM loop, run per table in foreign-key topological order, is itself a form of automated pre-filtering that could reduce the size or complexity of what reaches human review, but no consulted source measures whether this pre-filtering shortens human review time in practice, so its effect on the overall governance-latency budget is untested. [inference; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md; https://arxiv.org/abs/2506.01232] Sourcing three or four foundational ontologies for grounding, Schema.org, Dublin Core, PROV-O, FOAF, and Financial Industry Business Ontology (FIBO), via embedding similarity is a design that plausibly reduces schema drift across repeated inductions, which is consistent with this repository's prior finding that a predefined schema (TBox) improves robustness on noisy or heterogeneous data relative to schema-free extraction. [inference; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md; https://davidamitchell.github.io/Research/research/2026-07-20-tbox-abox-graphrag.html] This repository's prior ontology-landscape research separately concluded that ontology alone is not the best sole operational structure for a conflict-heavy, relationship-rich, time-sensitive corpus, precisely because reconciling conflicting proposed structure typically requires a review step; COA's architecture confirms that conclusion in practice, since the accept-gated proposal record is exactly this kind of conflict-resolution mechanism, and it is the source of the governance latency this item investigates. [inference; source: https://davidamitchell.github.io/Research/research/2026-05-15-ontology-landscape-for-curated-enterprise-context.html; https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md]

Economic lens. The accelerator's cost profile, approximately $930 per month at idle for the Neptune and OpenSearch Serverless baseline before any per-query Bedrock cost, means an organisation running COA has a running-cost incentive to keep review throughput matched to induction volume, since an unresolved proposal blocks further induction in that namespace regardless of whether the idle infrastructure continues to accrue cost. [fact; source: https://clawaws.com/blog/context-ontology-accelerator-agent-graph-context/] This cost structure is plausibly a pressure toward faster review, matching the condition the vigilance-decay mechanism in §2 warns against if that pressure is resolved by reducing review rigor rather than by adding reviewer capacity or narrowing what is routed to human review. [inference; source: https://clawaws.com/blog/context-ontology-accelerator-agent-graph-context/; https://davidamitchell.github.io/Research/research/2026-04-26-human-in-the-loop-ai-automated-workflows.html]

Regulatory and governance lens. This repository's prior knowledge-curation-governance research for regulated artificial intelligence found that provenance and auditability require explicit metadata identifying owner, approver, version, and review date, and that a hybrid model combining central control with federated domain stewards is the strongest operating pattern for regulated knowledge. [inference; source: https://davidamitchell.github.io/Research/research/2026-04-22-knowledge-curation-governance-for-regulated-ai.html] COA's namespace-scoped role model (owner, maintainer, data-steward, data-analyst, plus platform-wide admin and viewer roles enforced through Cedar policy evaluation, Cedar being AWS's open-source authorization-policy language for expressing fine-grained access rules) supplies the access-control half of that pattern, and its accept-based proposal record supplies an auditable approval event, but the consulted documentation does not describe a mandatory review-date, recertification, or periodic re-validation requirement for ontology content already accepted into the graph, which is a gap relative to the curation lifecycle that prior item identified as a minimum viable pattern (intake, validation, publication, use with citation, correction, retirement or recertification). [fact; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/control-plane/README.md; https://www.cedarpolicy.com/] [inference; source: https://davidamitchell.github.io/Research/research/2026-04-22-knowledge-curation-governance-for-regulated-ai.html]

Historical lens. Human review as a gate on automated symbolic-knowledge updates is not a new pattern; it mirrors long-standing truth-maintenance and knowledge-base curation practice in which candidate facts are staged and validated before being committed to a shared store rather than being written autonomously, a pattern this repository's hybrid-memory research found is still how the most mature current systems handle write-through synchronization into structured memory. [inference; source: https://davidamitchell.github.io/Research/research/2026-07-20-hybrid-memory-integration-ontology-llm-weights.html] COA's design is therefore a specific, product-level instance of a general architectural consensus rather than an unusual or experimental choice, which weighs against treating the accept gate itself as the design flaw and toward treating the undocumented review-time distribution as the actual open problem. [inference; source: https://davidamitchell.github.io/Research/research/2026-07-20-hybrid-memory-integration-ontology-llm-weights.html; https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md]

Behavioural lens. The vigilance-decay mechanism identified in this repository's prior human-in-the-loop research (large low-value review queues eroding reviewer attention) applies most directly to the unstructured induction path, where §2 established that no automated conformance check runs before human review, meaning the reviewer bears the full cognitive load of catching logical inconsistencies and modeling pitfalls that HermiT, OntoQA, or OOPS! would otherwise have screened out first. [inference; source: https://davidamitchell.github.io/Research/research/2026-04-26-human-in-the-loop-ai-automated-workflows.html; https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md] This raises the plausibility, though not the measured likelihood, that the unstructured path carries a higher review-time and error-risk burden per proposal than the structured path, if the structured path's validation subsystem is in fact wired in ahead of human review as documented for the package generally. [assumption; source: https://davidamitchell.github.io/Research/research/2026-04-26-human-in-the-loop-ai-automated-workflows.html; https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md]

§6 Synthesis

Executive summary:

The documented COA architecture confirms that a human accept decision, not automated OWL/SHACL verification, is the actual governance gate, and for the unstructured induction path no automated conformance validation runs at all before that human decision, so the research question's framing of "manual OWL/SHACL verification" as the delay source does not match the product as documented. [inference; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md] Contextual debt, in the sense of a growing gap between served context and current environment state, is architecturally guaranteed rather than merely possible, because an in-flight guard blocks new induction in a namespace until the outstanding proposal resolves and the Serve layer exposes only the already-accepted graph with no provisional-visibility path. [fact; source: https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py] The only latency figure documented anywhere in the consulted sources, 30 to 60 seconds, measures the automated post-approval merge and not the human review step itself, so the size of the resulting contextual debt in any real deployment depends on an unmeasured variable, human review turnaround time, that no consulted source quantifies as of this product's July 2026 general availability. [fact; source: https://aws.amazon.com/about-aws/whats-new/2026/07/aws-context--ontology-accelarator-generally-available/] The Model Context Protocol itself supports push-style resource-change notifications that could narrow this gap, but COA's own MCP server implementation exposes only agent-initiated query tools, so the real-time-representation limitation is a product implementation choice layered on top of the governance gate, not a constraint of the protocol. [inference; source: https://modelcontextprotocol.io/specification/2025-06-18/server/resources; https://github.com/aws/context-ontology-accelerator/blob/main/packages/mcp-server/README.md]

Key findings:

See ## Findings > Key Findings below; content is identical and not duplicated here per output-quality guidance to avoid near-verbatim repetition across sections.

Evidence map:

See ## Findings > Evidence Map below.

Assumptions:

See ## Findings > Assumptions below.

Analysis:

See ## Findings > Analysis below.

Risks, gaps, uncertainties:

See ## Findings > Risks, Gaps, and Uncertainties below.

Open questions:

See ## Findings > Open Questions below.

§7 Recursive Review

review_result: pass
acronym_audit: passed (AWS, LLM, MCP, RAG, OWL, SHACL, W3C, S3, API, SQL, SPARQL, RDF, FIBO, COA, HTTP, RIGOR all expanded at first prose use; SPARQL and Turtle and Cedar domain terms bound to authoritative W3C/Cedar definition sources at first use; RBAC, VKG, JWT, and HITL considered but not used as bare acronyms anywhere in this item, so left fully spelled out throughout instead)
domain_term_audit: passed ("contextual debt" marked Definition needed at first use in §0 with nearest adjacent term cited; "stability-plasticity dilemma" defined at first use with primary/secondary sources; HermiT, OntoQA, OOPS! each bound to an authoritative definition source at first use)
claim_label_audit: passed (every declarative sentence in §0 to §5 carries fact, inference, or assumption)
cross_reference_audit: passed (six prior completed items cited: aws-agentcore-knowledge-context-layer, tbox-abox-graphrag, hybrid-memory-integration-ontology-llm-weights, human-in-the-loop-ai-automated-workflows, knowledge-curation-governance-for-regulated-ai, ontology-landscape-for-curated-enterprise-context; all discussed substantively in body prose, none listed in related without body discussion)
evidence_sufficiency: primary-source (GitHub source code and package documentation, AWS announcement) directly documents the accept-gate, in-flight guard, and Serve-layer architecture, but Key Findings 1-4 are downgraded to medium confidence on review because each rests on a single source or on multiple same-organisation AWS sources rather than two independent sources; single-source for the review-duration gap because no second source exists this early in the product's release cycle, held at low-to-medium confidence accordingly

Findings

(Populated from §6 Synthesis above.)

Executive Summary

The human accept decision, not automated Web Ontology Language (OWL) or Shapes Constraint Language (SHACL) verification, is the actual governance gate in the AWS Context Ontology Accelerator (COA), and for the unstructured, document-derived induction path no automated conformance validation runs at all before that decision, so the research question's premise that manual OWL/SHACL verification drives the delay does not match the product as documented for that path. [inference; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md] Contextual debt, meaning a growing gap between an agent's served context and the current state of the environment it models, is architecturally guaranteed rather than merely possible in COA, because an in-flight guard blocks any new induction job in a namespace until its outstanding proposal is resolved, and the Serve layer exposes only the already-accepted knowledge graph with no provisional-visibility path for pending content. [fact; source: https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py] The only latency figure documented in the consulted sources, an automated merge step of 30 to 60 seconds, occurs entirely after the human decision and measures none of the review time itself, so how much contextual debt accumulates in any real deployment depends on an unmeasured variable, human review turnaround time, that no source located in this session quantifies as of the product's July 2026 general availability. [fact; source: https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py] The Model Context Protocol (MCP) specification supports push-style resource-change notifications that could narrow this gap, but COA's own MCP server implementation exposes only agent-initiated query tools, so the limitation on representing real-time mutation is a product-level implementation choice layered on top of the governance gate rather than a constraint of the protocol itself. [inference; source: https://modelcontextprotocol.io/specification/2025-06-18/server/resources; https://github.com/aws/context-ontology-accelerator/blob/main/packages/mcp-server/README.md]

Key Findings

COA follows a Scan, Model, Serve lifecycle in which the Model stage's ontology induction output is stored as an OntologyProposals record, and a domain expert must call the source-type-agnostic POST /ontology/proposals/{id}/accept endpoint before that content enters the graph agents can query, making human approval the single governance gate for both structured and unstructured induction paths. (medium confidence; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md; https://aws.amazon.com/about-aws/whats-new/2026/07/aws-context--ontology-accelarator-generally-available/; both sources are AWS-authored, so independence across sources is not established)
For the unstructured, document-derived induction path, COA's own package documentation states that the three-tier automated validation subsystem (the HermiT OWL reasoner, the OntoQA quality-metrics framework, and the OOPS! pitfall scanner) "is not invoked, so proposals are stored without conformance checks," listing this as a known release gap rather than a bug, which means the governance delay on that path is unassisted human review of an unvalidated proposal, not human review of an OWL/SHACL-validated one. (medium confidence; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md; single primary source, no independent corroboration located)
The automated pipeline that runs after a human accepts a proposal, covering catalog projection, ontology bulk load, and embedding accumulation, is documented in source comments to take 30 to 60 seconds, a duration the code states exceeds Amazon API Gateway's 29-second integration timeout and is the stated reason the accept step must run asynchronously; this figure measures only the post-approval merge and is not evidence about the preceding human review duration. (medium confidence; source: https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py; single primary source, no independent corroboration located)
COA implements an explicit in-flight guard that blocks starting a new induction job in a namespace whenever a proposal there is unreviewed, updated, failed, or actively merging, so a single slow or neglected human review stalls the ingestion of every subsequently arrived source change in that namespace, not only the batch that produced the pending proposal. (medium confidence; source: https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py; single primary source, no independent corroboration located)
The Serve layer's tiered query resolution executes exclusively against the materialized Neptune graph, and the documented MCP tool set (list_metrics, describe_schema, query, translate_sparql, rag_retrieval, graph_traversal) provides no way to query an in-review or provisional proposal, so an environmental change captured during Scan is invisible to every agent until a human completes the accept decision for that batch. (medium confidence; source: https://clawaws.com/blog/context-ontology-accelerator-agent-graph-context/; https://github.com/aws/context-ontology-accelerator/blob/main/packages/mcp-server/README.md)
The Model Context Protocol specification defines optional subscribe and listChanged server capabilities that let a server push change notifications to a connected client, but COA's mcp-server package documentation describes only agent-initiated tool invocations and does not mention implementing either capability, so the inability to represent live mutation is an implementation choice within COA rather than a limitation of the Model Context Protocol as a specification. (medium confidence; source: https://modelcontextprotocol.io/specification/2025-06-18/server/resources; https://github.com/aws/context-ontology-accelerator/blob/main/packages/mcp-server/README.md)
No source located in this session, AWS-authored or independent, states a measured or targeted duration for the human proposal-review step itself, distinct from the documented 30-to-60-second automated merge, which is consistent with this being an early-adoption evidence gap given that AWS announced COA's general availability only one month before this research was conducted. (medium confidence; source: https://aws.amazon.com/about-aws/whats-new/2026/07/aws-context--ontology-accelarator-generally-available/)
COA's mandatory accept gate is a stability-maximizing design choice in continual-learning terms, the established tradeoff between retaining prior knowledge and rapidly absorbing new information, because it makes it architecturally impossible for a proposal to alter the served graph without a human decision, preventing automated catastrophic forgetting or silent drift at the cost that the graph cannot incorporate new structure faster than that decision is made. (medium confidence; source: https://arxiv.org/abs/2403.05175; https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md)
This repository's prior human-in-the-loop research found that response-time expectations for human review should scale with the reversibility and criticality of the reviewed action, with a default of holding rather than silently continuing while review is pending, and COA's namespace-wide in-flight guard already implements that hold-by-default behaviour, though uniformly rather than calibrated to the risk of any specific ontology change. (medium confidence; source: https://davidamitchell.github.io/Research/research/2026-04-26-human-in-the-loop-ai-automated-workflows.html; https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py)
The same prior human-in-the-loop research found that large low-value review queues predictably erode reviewer vigilance, a mechanism that would plausibly bear more heavily on COA's unstructured induction path, where no automated conformance check screens the proposal first, than on a structured path where such screening is documented to exist, but no source consulted in this session measures whether COA's actual review queues have reached volumes at which this effect applies. (low confidence; source: https://davidamitchell.github.io/Research/research/2026-04-26-human-in-the-loop-ai-automated-workflows.html)

Evidence Map

Claim	Source	Confidence	Notes
[fact] COA follows Scan-Model-Serve; Model output is a reviewable proposal gated by a source-type-agnostic accept endpoint	https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md; https://aws.amazon.com/about-aws/whats-new/2026/07/aws-context--ontology-accelarator-generally-available/	medium	Primary: AWS announcement and package README, but both sources are AWS-authored, not independent
[fact] Unstructured induction path skips HermiT/OntoQA/OOPS! validation entirely; documented as a known v0 gap	https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md	medium	Primary source code documentation; single source, no independent corroboration
[fact] Post-approval merge documented at 30-60 seconds; exceeds API Gateway 29s timeout, hence async	https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py	medium	Primary: source code docstring; single source, no independent corroboration
[fact] In-flight guard blocks new induction in a namespace while any proposal is unreviewed or merging	https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py	medium	Primary: source code comments; single source, no independent corroboration
[fact] Serve layer and MCP tool set query only the accepted graph; no provisional-proposal query path documented	https://clawaws.com/blog/context-ontology-accelerator-agent-graph-context/; https://github.com/aws/context-ontology-accelerator/blob/main/packages/mcp-server/README.md	medium	Secondary analysis blog plus primary package README; independent architecture description not found
[fact] MCP spec supports optional subscribe/listChanged push notifications; COA's MCP server documentation does not describe using them	https://modelcontextprotocol.io/specification/2025-06-18/server/resources; https://github.com/aws/context-ontology-accelerator/blob/main/packages/mcp-server/README.md	medium	Protocol spec is primary and definitive; absence-of-mention in COA docs is an inference, not a confirmed non-implementation
[assumption] No source quantifies human review-step duration, distinct from the automated merge	https://aws.amazon.com/about-aws/whats-new/2026/07/aws-context--ontology-accelarator-generally-available/; https://github.com/aws/context-ontology-accelerator	medium	Absence-of-evidence claim; explicit search note recorded in §2.2
[fact] Stability-plasticity dilemma is an established continual-learning tradeoff; COA's accept gate is stability-maximizing	https://arxiv.org/abs/2403.05175; https://en.wikipedia.org/wiki/Catastrophic_interference	medium	Primary/secondary academic sources for the concept; application to COA is this item's own inference
[inference] Prior human-in-the-loop research's review-latency and hold-by-default guidance matches COA's in-flight guard behaviour	https://davidamitchell.github.io/Research/research/2026-04-26-human-in-the-loop-ai-automated-workflows.html; https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py	medium	Cross-item synthesis; COA-specific vigilance-decay effect is unmeasured
[assumption] Vigilance decay plausibly bears more on the unvalidated unstructured path than a validated structured path	https://davidamitchell.github.io/Research/research/2026-04-26-human-in-the-loop-ai-automated-workflows.html	low	No direct measurement of COA review-queue volume or error rate located

Identified but not consulted:

GitHub issue #651: Multiple research questions, the canonical issue statement was read for framing but is not itself an evidence source for architectural claims.

Assumptions

The structured induction path (table_to_ontology and rigor_ontology) routes proposals through the HermiT, OntoQA, and OOPS! validation tiers before human review, mirroring the general package description of a validation subsystem separate from the unstructured path's documented gap. [assumption; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md] The package README describes the three-tier subsystem as a general capability without stating per-induction-path wiring for the structured strategies, so this item treats structured-path validation as the more likely configuration without direct confirmation, and flags any claim depending on it as lower confidence. [assumption; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md]

COA's own mcp-server package does not implement the Model Context Protocol's optional subscribe or listChanged capabilities. [assumption; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/mcp-server/README.md] The package documentation lists six agent-invoked tools and does not mention either capability, which this item treats as evidence of non-implementation, though the absence of a positive statement in a partial README is not the same as an explicit negative statement in the source code's capability declaration, which was not directly inspected in this session. [assumption; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/mcp-server/README.md]

Human proposal-review turnaround time in real COA deployments is currently unmeasured and likely highly variable, ranging from minutes for a domain expert with a light queue to days for a contested or high-volume batch. [assumption; source: https://aws.amazon.com/about-aws/whats-new/2026/07/aws-context--ontology-accelarator-generally-available/] This is justified by the product's one-month-old general-availability status at the time of this research and the corresponding absence of independent operational case studies, rather than by any direct evidence about typical review duration. [assumption; source: https://aws.amazon.com/about-aws/whats-new/2026/07/aws-context--ontology-accelarator-generally-available/]

Analysis

The in-flight guard and the accept-gated Serve layer are both stated directly in COA's own source code and documentation, so the mechanism by which an unresolved proposal blocks further ingestion in a namespace is a directly documented architectural fact rather than a derived claim. [fact; source: https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py] Whether this architectural mechanism is sufficient on its own to answer the contextual-debt half of the research question without a measured review-duration figure is this item's own evidence-weighting judgment, not a claim any cited source makes, so that sufficiency assessment is treated as an inference rather than a fact. [inference; source: https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py] The stability-plasticity half of the research question is weighed differently: labelling COA's design as excessively rigid would require a comparator, either a documented failure mode COA has caused or an alternative governed-ontology product that resolves the same tradeoff with materially lower latency, and neither was located in this session, so this item stops at describing COA's choice as stability-maximizing rather than judging it as too stable. [inference; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md]

A plausible rival explanation for why COA does not measure or publish review-turnaround data is that the product is too new for such data to exist yet, rather than that AWS considers the metric unimportant; this item favours the former because the general-availability announcement itself is dated one month before this research and makes no operational-maturity claims. [inference; source: https://aws.amazon.com/about-aws/whats-new/2026/07/aws-context--ontology-accelarator-generally-available/] A second rival explanation for the unstructured path's missing validation tier is that AWS intentionally deferred it as a v0 scoping decision rather than as an oversight, which this item accepts because the package documentation itself frames the four listed gaps as deferred work items with named follow-up tasks, not as undocumented defects. [fact; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md] Neither rival explanation changes this item's central conclusion, that the governance gate as currently documented is unassisted human review with an unmeasured duration, but both are recorded because they bear on how quickly the identified evidence gap might close as the product matures. [inference; source: https://aws.amazon.com/about-aws/whats-new/2026/07/aws-context--ontology-accelarator-generally-available/; https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md]

An alternative remedy to changing the review gate itself, adding reviewer staffing or narrowing what routes to human review through stricter automated pre-filtering, is at least as plausible a mitigation as moving the gate from inline to asynchronous or sampled control, and the evidence gathered here does not distinguish between these options because none is measured against the others in any consulted source. [inference; source: https://davidamitchell.github.io/Research/research/2026-04-26-human-in-the-loop-ai-automated-workflows.html] This item therefore treats the design-guidance question in the original Approach as only partially answerable from current evidence: the direction of the mechanism (unresolved review blocks new ingestion) is established, but the calibration question (how much review latency is tolerable before it should trigger a different control pattern) depends on the missing review-duration data identified above. [inference; source: https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py; https://davidamitchell.github.io/Research/research/2026-04-26-human-in-the-loop-ai-automated-workflows.html]

Risks, Gaps, and Uncertainties

Human proposal-review turnaround time for COA is not measured in any source located in this session. [fact; source: https://aws.amazon.com/about-aws/whats-new/2026/07/aws-context--ontology-accelarator-generally-available/] This is the single largest gap bearing on the research question's central quantitative claim, because it is the variable that determines how much contextual debt accumulates in a real deployment. [inference; source: https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py]

Whether the structured induction path routes proposals through the HermiT, OntoQA, and OOPS! validation tiers before human review, versus the unstructured path's confirmed skip of that subsystem, is not stated explicitly in the consulted package documentation and is held as an assumption rather than a fact in this item. [assumption; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md]

Whether the validation/shapes directory observed in the repository's file listing implements Shapes Constraint Language shapes specifically was not confirmed, because its file-level contents were not fetched in this session; this leaves the research question's SHACL-specific premise partially unverified rather than confirmed or refuted. [assumption; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md]

COA's general availability announcement is one month old at the time of this research, so every architectural claim here reflects a single release snapshot. [fact; source: https://aws.amazon.com/about-aws/whats-new/2026/07/aws-context--ontology-accelarator-generally-available/] Any near-term product update could change the accept-gate mechanics, add a subscription-based MCP capability, or wire validation into the unstructured path, none of which this item can anticipate. [assumption; source: https://aws.amazon.com/about-aws/whats-new/2026/07/aws-context--ontology-accelarator-generally-available/]

No consulted source presents an empirical case study of an organisation running COA against a high-velocity, unstructured data source, so the research question's framing of "high-velocity, unstructured data" as the specific failure condition remains a plausible but unverified deployment scenario rather than an observed one. [assumption; source: https://github.com/aws/context-ontology-accelerator]

Open Questions

What is the actual distribution of human proposal-review turnaround time across real COA deployments, and does it vary systematically between the structured and unstructured induction paths? This could become a new backlog item once independent case studies or AWS-published operational guidance exists.

Does the structured induction path (table_to_ontology, rigor_ontology) route its proposals through the HermiT/OntoQA/OOPS! validation subsystem before human review, and if so, does that automated pre-filtering measurably reduce human review time relative to the unstructured path's unfiltered proposals?

Does the validation/shapes directory in the ontology-engine package implement Shapes Constraint Language validation, and if so, at which stage of which induction path is it invoked?

If AWS or a practitioner community publishes review-latency data for COA in the future, at what latency threshold, relative to the source data's actual rate of change, does the accumulated contextual debt become severe enough to warrant moving the governance gate from an inline block to an asynchronous audit, sampled review, or exception-based control pattern?

Output

Type: knowledge
Description: This item establishes that AWS Context Ontology Accelerator's governance latency is architecturally guaranteed to create contextual debt through a documented in-flight guard and accept-gated serving layer, but that the specific magnitude of that debt depends on human review-turnaround data not yet published for this one-month-old product, and that the research question's premise of manual OWL/SHACL verification as the delay mechanism does not hold for the unstructured induction path, where no automated validation runs before human review at all. [inference; source: https://github.com/aws/context-ontology-accelerator/blob/main/packages/ontology-engine/README.md]
Links: https://github.com/aws/context-ontology-accelerator ; https://raw.githubusercontent.com/aws/context-ontology-accelerator/main/packages/ontology-engine/src/coa_ontology/proposals.py ; https://davidamitchell.github.io/Research/research/2026-04-26-human-in-the-loop-ai-automated-workflows.html