Technical / Q&As / Build / Runtime / Governance
Q&A · By Lifecycle Phase

Q&As — Build / Runtime / Governance

Direct answers to questions engineers ask, organized by lifecycle phase. Build covers SDLC, CI/CD, and build-time integrations. Runtime covers state, variables, DB access, middleware, observability. Governance covers accessibility, auditability, and evidence packaging.

Build

B1 How does Essence fit into our existing SDLC?
Short Answer Essence slots into the generator position of an existing SDLC, producing source or compiled artifacts that flow through normal repos, CI/CD, scanning, and deploy systems. No pipeline rewrite required for adoption.

What Stays

  • Version control, branching, and code review practices
  • CI orchestration — Jenkins, GitHub Actions, GitLab CI
  • Artifact repositories — Nexus, Artifactory, container registries
  • Scanning tools — SAST, DAST, dependency, license
  • Deployment targets — cloud, on-prem, edge

What Gets Added

  • Intent-driven specification as a source-of-truth input
  • Optional certification bundles attached to releases
  • Optional governed runtime for selected workloads
B2 What CI/CD tooling is supported out of the box?
Short Answer Essence supports the dominant CI/CD and DevSecOps toolchains natively. See the full compatibility matrix for details.
  • Git, GitHub, GitLab, Bitbucket
  • Jenkins, GitHub Actions, GitLab CI, Azure DevOps
  • Maven, Gradle, CMake, Ninja, Bazel
  • Docker, BuildKit, GHCR, ECR, GCR, ACR
  • SAST / DAST / dependency / license / SBOM tooling
  • Sigstore / cosign / SLSA / in-toto provenance

See CI/CD & DevSecOps for the complete compatibility matrix.

B3 How do we handle versions, branches, and forks?
Short Answer Wantware source materials version and branch like any other source tree. Lineage is tracked across forks and merges, and InfoSigns reference versioned assets unambiguously.
  • Source control: Wantware intent files live in the repo alongside conventional source
  • Branching: standard branch / merge workflows apply
  • Lineage: InfoSigns carry version and fork history for referenced assets
  • Reproducibility: the same inputs produce verifiable outputs via signed build attestations
B4 Can we generate SBOMs and provenance data?
Short Answer Yes — SBOMs (CycloneDX or SPDX), signed artifacts (cosign / Sigstore), and build provenance attestations (in-toto / SLSA) are native outputs of the build pipeline.
  • SBOM formats: CycloneDX and SPDX
  • Signing: cosign, Sigstore
  • Provenance: in-toto, SLSA-level attestations
  • Bundling: all of the above package into certification bundles per release

Runtime

R1 How is state and variable handling managed?
Short Answer State lives where it naturally belongs — in DBs, caches, object stores, message queues — with runtime behavior bound to intent rather than to hand-coded state machines. Variables map to Meaning Coordinates with declared type, range, and precision requirements.

State Management

  • Persistent state in existing storage systems (RDBMS, KV stores, object storage)
  • Transient state handled by runtime with lifecycle bounded by declared purpose
  • Event-sourced workflows supported where state needs replay semantics

Variable Handling

  • Value ranges, precision, and type constraints declared in meaning, not guessed by compiler
  • Runtime enforces declared bounds (e.g., financial values carry rounding and concurrency rules)
  • See Meaning Coordinates for the encoding model
R2 How does database integration work?
Short Answer Essence integrates with existing DB systems via standard drivers and connection patterns. Schema, ORM, and query semantics stay under team control; runtime provides intent-level access with policy-bounded behavior.
  • RDBMS: PostgreSQL, MySQL, SQL Server, Oracle via standard drivers
  • NoSQL: MongoDB, DynamoDB, Cassandra, Redis
  • Analytics: Snowflake, BigQuery, Redshift, Databricks
  • Graph: Neo4j and compatible graph stores
  • Access to regulated data can be scoped by declared purpose (e.g., "analytics, read-only, no PII export")
R3 How are middleware and integration patterns handled?
Short Answer Standard middleware patterns — message queues, service buses, API gateways, load balancers — integrate normally. Intent can express routing, retries, and compensation behavior declaratively.
  • Message queues: Kafka, RabbitMQ, Pulsar, SQS, Service Bus
  • API gateways: Kong, Apigee, AWS API Gateway, Azure API Management
  • Service mesh: Istio, Linkerd, Consul Connect
  • Load balancers: HAProxy, Nginx, cloud LBs
R4 How does observability work at runtime?
Short Answer Observability works through existing tools — OpenTelemetry, Prometheus, Datadog, Splunk, Elastic — with Essence adding policy-tied and purpose-tied fields to standard audit events.
  • Traces: OpenTelemetry trace IDs flow end-to-end
  • Metrics: Prometheus and OTLP metrics feed the usual dashboards
  • Logs: structured JSON events flow to SIEM and log stores
  • Audit events: policy-linked records with declared-purpose and authority context

See Audit Telemetry for the event schema.

R5 How are scaling and autoscaling handled?
Short Answer Scaling uses the orchestrators and autoscalers already in place (Kubernetes HPA/VPA, cloud autoscaling, serverless). In governed-runtime workloads, scale decisions can respect policy-declared bounds.
  • Kubernetes HPA, VPA, cluster autoscaler
  • Cloud autoscaling (AWS, GCP, Azure, OCI)
  • Serverless execution targets (Lambda, Functions, Cloud Run)
  • Policy can bound scale behavior — e.g., "never cross regions", "cap compute spend"
R6 What happens when a runtime policy denies an action?
Short Answer A denied action emits a policy-linked audit event with actor, action, artifact, policy, reason, and trace ID. Response behavior (alert, block, halt, remediate, rollback) is defined by the policy, not by the workload.

See the Audit Telemetry page for the event schema and example records, and Policy & Purpose for the enforcement model.

Governance

G1 Does the platform support WCAG and Section 508 accessibility?
Short Answer Generated UI outputs can target WCAG 2.1 / 2.2 AA and Section 508 requirements when intent specifies accessibility outcomes. The platform produces standard HTML / ARIA / semantic markup that existing accessibility scanners validate.
  • Standard ARIA and semantic HTML in generated outputs
  • Compatible with axe-core, WAVE, Lighthouse accessibility audits
  • Accessibility requirements expressible as part of intent rather than bolt-on
G2 How are evidence bundles generated and delivered?
Short Answer Bundles generate per release (Stage 2+), can be scheduled for compliance windows (Stage 4), or packaged on demand for incident response. Delivery formats are ZIP, OCI-compatible packages, or signed URLs to artifact repositories.
  • Contents: SBOM, scan reports, signed artifacts, policy snapshots, integrity manifest, bundle signature
  • Formats: ZIP, OCI
  • Delivery: artifact repository, SFTP, customer portal, audit handoff
  • Verification: external verifiers check signatures and hashes without live access
G3 How are access controls and authorization audited?
Short Answer Every authorization decision — allow, deny, conditional — emits an audit event tied to the policy that decided it, the actor, the action, and the artifact. Events stream to SIEM alongside identity events from existing IdP systems.
  • Policy decisions logged with rule version and decision reason
  • Identity events correlate with existing IdP audit (Okta, Entra, Ping, Auth0)
  • Access review reports derived from event stream rather than ad-hoc queries
G4 How do we handle regulatory reviews and auditor requests?
Short Answer Provide the bundle. Most auditor questions about change control, integrity, monitoring, and access can be answered from a time-bounded bundle — signed, verifiable, and reproducible — without auditors needing live system access.

See Regulatory Alignment for how bundles map to specific frameworks, and Trust Certification for bundle composition.

G5 What's the story for incident response?
Short Answer Execution lineage, policy-linked audit events, and per-version certification bundles mean forensic material already exists before an incident — the first hour isn't spent reconstructing events, it's spent acting on them.
  • Event streams with policy and purpose context for the affected window
  • Per-version bundles describing what was running and how it was built
  • Correlation traces that bind build, deploy, and runtime together
  • Optional incident-scoped bundle delivery for partners and regulators
Related Sections
← Docs Home Q&As by Role Audit Telemetry Policy & Purpose SIEM & Evidence Export