Back to the workspaceOUR APPROACH

Useful AI.
Reviewable work.

Civic Topography is built around a practical principle: people should be able to inspect the work their agents help produce.

01

Clear roles and human authority

Meridian helps carry out work. Advisor provides a distinct quality perspective. Scout helps route questions. Resolving a discrepancy from an approved source is different from making a new budget, scope or policy decision. The latter stays with the authorized person.

02

A record behind the result

The working record connects source references and versions, applied checks, material corrections and approvals to the deliverable. It documents observable evidence and decisions; it does not claim to expose a model’s private internal reasoning.

03

Standards-informed design

Our design library includes ISO/IEC/IEEE 29148:2018 for requirements engineering and IEEE 1012-2024 for verification and validation. Their applicable principles inform our work; specific conformance claims require verified mappings and implementation evidence. References do not imply certification, endorsement or guaranteed regulatory compliance.

04

Committee and organizational separation

The product design requires scoped access to each committee’s records and agent context, with explicit authority for sharing. Verification must cover both allowed and denied access across files, search, saved sessions, background work and connected tools.

05

Security assurance

Our security planning uses NIST Cybersecurity Framework 2.0, OWASP ASVS 5.0 and NIST secure-development guidance as references. We are evaluating independent assurance for enterprise use. No SOC 2 report or ISO/IEC 27001 certification is claimed.

06

Models tested for their work

Our model-selection approach evaluates representative tasks, quality criteria and available capacity. Budgeting includes hardware, electricity, service and any cloud use.

07

Optional frontier-model review

The workflow offers an optional cloud-hosted frontier-model review before approval. An authorized person chooses whether to run it, what package may be sent and the permitted spend. Review findings and corrections stay with the work; an unrun review remains unrun. A separate model provides another assessment, not a guarantee of correctness or an independent certification. Our evaluation criteria cover errors caught and missed, regressions, cost and human-review effort against a baseline without this extra review.

Related research: Minions: collaboration between on-device and cloud language models studies cost and task-performance tradeoffs. It motivates investigation of hybrid systems; it does not validate CT’s review process or establish IV&V independence. Our own evaluation reports will need to demonstrate those product-specific outcomes.

08

Improvement with review

Corrections and useful interactions can become candidate training examples under appropriate access and use permissions. Vantage prepares eligible examples for the specialized adapters used by CT, with staged evaluation, approval and deployment. Compatible hardware can support background work in approved idle or scheduled windows while active work takes priority. Private records are not automatically shared across organizations. More collected data does not by itself prove an improvement.

09

Public adaptation evaluation reports

Our publication policy covers LoRA and other adaptation evaluation reports after testing, including the model and adaptation versions, task definitions, data provenance summaries, held-out evaluation methods, baseline comparisons, gains, regressions and limitations. Results should include tests that show no improvement. Public reports will describe the evidence without exposing private organizational records. No measured adaptation gains are claimed here.

10

Examples that explain the work

The workspace illustrations and fictional working record explain the product experience. They are examples, not customer results.

11

On-device capability. Selective cloud review.

On-device inference processes a request on your organization’s hardware. It avoids a cloud-model provider’s per-request inference charge for that work. Cloud inference uses a provider’s servers and can offer additional capacity and model capabilities. CT combines on-device agents with an optional, authorized frontier-model review; connected services and that review may send permitted information outside the device.

The economics depend on workload and equipment: hardware, energy, maintenance, CT service and any selected cloud use remain real costs. Hardware capacity also limits model size, concurrency and speed. More hardware does not by itself establish better answers.

Apple’s guide to language models on Apple silicon explains MLX and inference on M-series hardware. Its Mac Studio overview describes workstation AI capabilities. Google DeepMind’s Gemma overview introduces its open-model family, while the Gemma 4 model card details model sizes, capabilities and limitations. These sources describe the underlying technology; they are not evaluations or endorsements of CT.

For the broader architecture, Google’s Why your startup needs open models alongside frontier APIs explains pairing compact open models with frontier services. Read the Gemma 4 model card for capabilities and limitations, and Apple’s Mac Studio specifications for hardware options. Specifications are not CT performance benchmarks or a requirement to buy the latest model.

Project-management practices from the PMBOK® Guide also inform the design. PMBOK is a registered mark of Project Management Institute, Inc. No endorsement is implied.

Read the detailed product brief for people and their agents or site guide for agents. Use the brief to share the product explanation with your assistant.

Discuss your organization’s work