Skip to main content
Jira progress: loading…

ZHTRA

ZARATHUSTRA — Agent-Assisted Semantic Forge Architecture

1. Purpose​

ZARATHUSTRA defines the architecture for the ZAYAZ Semantic Forge Layer.

Its purpose is to transform complex ESG, ISO, carbon, LCA, and sustainability framework requirements into structured, governed, machine-executable artifacts for the ZAYAZ platform.

ZARATHUSTRA is not a replacement for ZAYAZ.

It is the upstream semantic authoring and preparation layer that feeds:

  • zar.table_registry
  • zar.signal_registry
  • zar.signal_csi_binding
  • zar.signal_uso_type_binding
  • zar.uso_type_registry
  • FOGE form generation
  • TrustGate validation and assurance logic
  • ZARA review and intelligence workflows

2. Core Principle​

ZARATHUSTRA defines meaning. ZAYAZ executes meaning. ZARA validates meaning. TrustGate audits meaning.

This separation ensures that ZAYAZ does not invent semantic meaning at runtime. Instead, ESG and sustainability meaning is deliberately authored, validated, reviewed, and then published into canonical registries.

3. Why ZARATHUSTRA Is Needed​

The ZARATHUSTRA model can use local, expert-operated authoring workflows.

These are powerful, but they become difficult to scale as ZAYAZ expands across:

  • ESRS / CSRD
  • EU Taxonomy
  • GRI
  • ISO standards
  • PEF / OEF
  • IPCC / GHG Protocol
  • sector-specific ESG requirements
  • product-level sustainability models
  • supply-chain traceability frameworks

ZARATHUSTRA has an agent-assisted architecture that allows workflows to become more scalable, repeatable, and auditable.

4. Local vs AWS Runtime Model​

LayerLocal ModelAWS Model
Semantic authoringLocal Mac + Codex-assisted toolingLocal tooling + managed semantic agents
Source materialPDFs, Excel, MDX, manual extractsControlled source repositories and knowledge bases
OutputExcel / CSV / JSON draftsProposal tables and structured registry artifacts
ReviewManual expert reviewHuman review + deterministic validation
PublicationManual / API-drivenGoverned ZAYAZ Admin API
RuntimeLocal workstationOptional AWS-managed runtime

5. Architecture Overview​

6. ZARATHUSTRA as Semantic Authority​

ZARATHUSTRA remains the authoritative semantic layer regardless of tooling.

A local script, a Codex workflow, a Bedrock Managed Agent, or a future ontology editor may all act as execution environments.

However, the authority remains the ZARATHUSTRA governance model:

7. Managed Agent Runtime Option​

AWS Bedrock Agents are relevant because they support agents that can combine instructions, knowledge bases, and action groups to complete multi-step tasks. Action groups can expose API operations through OpenAPI schemas or function definitions, which fits the ZAYAZ model of controlled proposal-generation endpoints. AWS documentation describes action groups as the mechanism for defining operations an agent can invoke. (AWS Bedrock Action Groups) [https://docs.aws.amazon.com/bedrock/latest/userguide/agents-action-add.html]

Amazon Bedrock Knowledge Bases can connect proprietary data sources to retrieval-augmented generation workflows, allowing agents to retrieve relevant source material before producing an answer or structured output. (AWS Bedrock Knowledge Bases) [https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html]

AWS also announced Amazon Bedrock Managed Agents powered by OpenAI in limited preview in April 2026, describing them as a way to deploy production-ready OpenAI-powered agents on AWS for long-running tasks. (AWS Announcement) [https://aws.amazon.com/about-aws/whats-new/2026/04/bedrock-openai-models-codex-managed-agents/]

Bedrock Managed Agents should be treated as a possible managed runtime for ZARATHUSTRA.

They should not be treated as the semantic authority.

Correct model:

ZARATHUSTRA = Semantic authority
Bedrock Managed Agent = Optional execution runtime
ZAYAZ = Governance and publication layer

Incorrect model:

Bedrock Agent = Source of truth

9. Proposed ZARATHUSTRA Agent Roles​

ZARATHUSTRA may use several specialized semantic agents.

9.1. Framework Extraction Agent​

Purpose:

Extract framework requirements from source material.

Inputs:

  • ESRS standards
  • ISO clauses
  • GHG Protocol guidance
  • PEF/OEF method documents
  • EU Taxonomy criteria

Outputs:

  • requirement candidates
  • disclosure obligations
  • data point candidates
  • evidence requirements
  • form population hints

9.2. Registry Proposal Agent​

Purpose:

Convert extracted requirements into ZAYAZ registry proposals.

Outputs:

  • table registry proposals
  • signal registry proposals
  • CSI proposals
  • USO Type proposals
  • CMI proposal hints

9.3. FOGE Schema Agent​

Purpose:

Convert framework and signal requirements into form-generation structures.

Outputs:

  • form sections
  • fields
  • field dependencies
  • validation requirements
  • evidence upload requirements
  • conditional display rules

9.4. Ontology Mapping Agent​

Purpose:

Map external framework language to ZAYAZ semantic systems.

Outputs:

  • ESRS → signal mappings
  • ISO clause → evidence fields
  • GHG category → USO Type
  • PEF impact category → calculation input model

9.5. Review Queue Agent​

Purpose:

Prepare unresolved or low-confidence items for human review.

Outputs:

  • review reasons
  • confidence scores
  • missing context explanations
  • proposed follow-up questions
  • suggested controlled-vocabulary extensions

10. Governance Boundary​

Agents may propose.

Agents must not directly publish canonical records.

Allowed writes:

zar.table_registry_proposal_results
zar.signal_proposal_results
zar.csi_proposal_results
zar.cmi_proposal_results
future: zar.uso_type_proposal_results
future: zar.foge_form_proposal_results
future: zar.framework_requirement_proposal_results

Restricted writes:

zar.table_registry
zar.signal_registry
zar.signal_csi_binding
zar.signal_uso_type_binding
zar.uso_type_registry
zar.cmi_registry

Canonical publication must go through:

  • deterministic validation
  • controlled vocabularies
  • review status
  • approval workflow
  • audit logging

11. Proposed Action Groups​

A Bedrock-based ZARATHUSTRA agent could use action groups for controlled ZAYAZ API calls.

Example action groups:

extract_framework_requirements
generate_table_registry_proposals
generate_signal_registry_proposals
generate_csi_proposals
generate_uso_type_proposals
generate_foge_form_schema_proposals
validate_against_existing_registries
submit_review_queue_item
ingest_trustgate_telemetry

Each action group should call API endpoints that write to proposal tables only.

12. Proposed API Surface​

Existing / Near-Term Endpoints

POST /admin/table-registry/proposals/generate
POST /admin/signal-registry/proposals/generate
POST /admin/csi/proposals/generate-missing
POST /admin/cmi/proposals/generate
POST /admin/trustgate/telemetry/ingest

Future Endpoints

POST /admin/framework-requirements/proposals/generate
POST /admin/uso-types/proposals/generate
POST /admin/foge-form-schema/proposals/generate
POST /admin/ontology-mappings/proposals/generate
POST /admin/review-queue/items/create

13. Knowledge Base Design​

A managed ZARATHUSTRA runtime should use curated knowledge bases.

Recommended knowledge bases:

Knowledge BaseContent
Framework KBESRS, ISO, GHG, PEF/OEF, EU Taxonomy source material
ZAYAZ Registry KBCurrent table/signal/CSI/USO/CMI registry exports
ZAYAZ Manual KBDocusaurus technical documentation
Governance KBNaming rules, controlled vocabularies, review policies
Examples KBApproved historical proposals and canonical mappings

Knowledge bases should be scoped by workflow and access level.

14. Agent Workflow Example — ISO Clause to FOGE Form Schema​

15. Agent Workflow Example — ESRS Datapoint to Signal Proposal​

16. Validation Model​

All agent outputs must pass deterministic validation before they can be promoted.

Validation categories:

ValidationPurpose
Controlled vocabulary validationPrevent free-form registry pollution
Schema validationEnsure payload format correctness
Collision validationPrevent duplicate identifiers
Near-collision validationDetect confusingly similar names
Framework traceability validationEnsure source requirement reference exists
Confidence threshold validationRoute uncertain results to review
Human review validationRequire approval before canonical publication

17. Security Model​

ZARATHUSTRA source material and semantic outputs may contain high-value IP.

Security requirements:

  • least-privilege IAM roles
  • no direct production registry write access
  • proposal-only API credentials for agents
  • encrypted source storage
  • source document access controls
  • audit logs for all agent actions
  • separation between dev/staging/production
  • review gate before canonical publication
  • no unrestricted developer access to raw semantic source material

18. Deployment Phases​

Phase 1 — Local ZARATHUSTRA remains primary

Use local Mac/Codex workflows for:

  • high-value framework modeling
  • experimental ontology work
  • first-pass semantic design

Phase 2 — Bedrock proof of concept

Test one contained workflow:

ISO 14001 clause → requirement proposal → FOGE form schema proposal

or:

ESRS datapoint → signal proposal → USO Type proposal

Phase 3 — Managed agent review queue population

Allow agents to populate proposal tables and review queues.

Phase 4 — Full managed semantic forge runtime

Use managed agents for repeatable framework ingestion, while keeping publication inside ZAYAZ.

The first POC should be:

ISO 14001 requirement → FOGE form schema proposal

Why:

  • contained scope
  • clear source-to-field transformation
  • low risk
  • immediately useful
  • validates the full ZARATHUSTRA v2 pattern

Expected outputs:

  • requirement summary
  • evidence requirement
  • suggested form field(s)
  • validation rules
  • review rationale
  • confidence score
  • source reference

20. Final Architecture Principle​

ZARATHUSTRA is not just tooling.

It is the epistemic foundation of ZAYAZ.

ZARATHUSTRA may use agents, but agents are not the authority.

Agents accelerate interpretation.
ZARATHUSTRA governs meaning.
ZAYAZ publishes truth.

Final principle:

Meaning may be AI-assisted, but canonical meaning must be governed.

Thus spoke Zarathustra — and ZAYAZ executes.



GitHub RepoRequest for Change (RFC)